Database Info

[Q] How Android Works - OS and Versions

I know this is an incredibly newbish question, but I'd flipped through various forums and articles and googled it and still don't quite seem to understand it.
My question is why is android dependent upon manufacturer's release?
Take for example, a desktop computer.
OS
This is the core of the device and the UI between the user and the hardware.
Applications talk to the OS to instruct the hardware to do stuff.
Microsoft and Apple makes the OS.
ex. Windows 7, Mac OS, Linux.
Hardware
Asus, Nvidia, Realtek, marvell make the hardware.
ex. video, LAN, sound etc.
Hardware Bundler
Dell, Alienware, Gateway, Acer
They take commercial hardware and some OEM hardware and assemble it in a way that many consumers will buy their bundle.
For 99.9% of us, not counting Synapse, this is the only way the hardware is packaged together.
Device Standards
Collectively, the manufactures work together to determine certain industry standards ex. ATX, PCI-E, SATA 3, USB 3.0 etc...
Drivers
The manufacturers also make drivers so the OS can make use of their hardware.
Compatibility Is Determined by Driver Support
If the driver exists to talk to a given OS, then the hardware will work.
Not all hardware manufacturers will code for every OS out there.
ex. USB works on all OS because it's more established, but not every sound card will work on a Linux system.
Bringing it home...
So if Microsoft releases Windows 8, and as long as Nvidia releases a driver that works with that OS, then the video card will work.
Can you help me understand how the android phone architecture is so different that it's no longer
OS <-> Driver <-> Hardware?
Sorry for not getting it.

Culverin said:
Can you help me understand how the android phone architecture is so different that it's no longer
OS <-> Driver <-> Hardware?
Click to expand...
Click to collapse
It isn't different, it's exactly as you written. But manufacturers usually don't release sources of drivers, neither binaries for newer versions of OS. Also many manufacturers add protection against installing your own software into "their" device.
Android is open, but many manufacturers of Android devices - aren't.

Many devices just like????

You say manufacturers, are you referring to components such as the modem (???), video encoding/decoding chip (tegra), sound chip (wolfson)? NFC chip?
Aren't these drivers publicly available?
How else would small companies be able to develop low volume items such as these?
http://www.bigboxstore.com/computers/android-tablet-pcs
http://cheapandroidtablet.org/
When a company, samsung for example, makes a phone.
They start tying all the components together and making them talk to each other.
How "custom" are the "motherboard bios"?
Is that what you are saying by the manufacturers add protection?
Like at the "bios" level?
As for things like this...
http://www.engadget.com/2011/01/27/sony-announces-playstation-suite/
Does that mean Sony is banking on Google making it more standardized?

Culverin said:
You say manufacturers, are you referring to components such as the modem (???), video encoding/decoding chip (tegra), sound chip (wolfson)? NFC chip?
Click to expand...
Click to collapse
I mean both components manufacturers and phone manufacturers.
Usually there are problems with Wifi, GPS, GPU support, camera, etc. Many alpha-stage ports have problems with these things.
Culverin said:
Aren't these drivers publicly available?
Click to expand...
Click to collapse
Do you mean sources? Manufacturers rarely release sources of drivers, even on a PC. This is the reason, why there are problems with some devices on linux systems.
Culverin said:
How else would small companies be able to develop low volume items such as these?
Click to expand...
Click to collapse
I'm not sure, but they have to buy a license to use these components in their devices anyway, so I guess they get sources of drivers too, but they can't release them.
Culverin said:
How "custom" are the "motherboard bios"?
Is that what you are saying by the manufacturers add protection?
Like at the "bios" level?
Click to expand...
Click to collapse
"BIOS" or just "boot phase software" is usually 100% custom - there are no standard solutions I know of.
Let's imagine you have bought a new PC with some preinstalled OS. You don't have administrator rights on it, you can't boot from other device than HDD and if you want to update your system, you have to use special software, which has administrator rights, but it checks whether updates were created by device manufacturer. This is more or less how most of phones work.
Culverin said:
Does that mean Sony is banking on Google making it more standardized?
Click to expand...
Click to collapse
I'm not sure what do you mean?

Culverin said:
I know this is an incredibly newbish question, but I'd flipped through various forums and articles and googled it and still don't quite seem to understand it.
My question is why is android dependent upon manufacturer's release?
Click to expand...
Click to collapse
Because individual makers add their own hardware.
Can you help me understand how the android phone architecture is so different that it's no longer
OS <-> Driver <-> Hardware?
Sorry for not getting it.
Click to expand...
Click to collapse
It still is. Android OS is JUST THE BIOS, in your example. The VXDs/drivers are made by different manufacturers (hardware level drivers) and loaded at system time.
You can load a plain Android OS, but it won't be able to talk to the phone's hardware except in a very general sense. You can touch screen, launch apps, but no phone, and only generic camera without special resolution support and such. It won't be able to do data or phone at all. That requires special VXDs (or their linux equivalent, I'm a Windows guy). Not all phones have the same buttons, or the same screen rez, or the same keyboard, and so on.
That's why there are various experimental Gingerbread ROMs out there already, but they don't work that well, because nobody had debugged the "drivers" for the hardware yet.
And if nobody release the source of the drivers (even for the earlier versions) nobody can use that to figure out if they are compatible with the next OS rev. Binary hacking is way too difficult.

[Q] Port Android Questions

Ok, I know much of what I'm about to ask has generally been answered or discussed in other posts, but I could really use some more direct/specific answers to my own questions.
My first question is about hardware drivers. To my understanding, a great many, if not most, of the more common wifi drivers are incorporated into the latest linux kernels. If this is the case, will more or less any Android system run on a device so long as the appropriate kernel is provided?
To be a little more clear on that, I'm actually trying to learn Android development (both for apps and building roms) on a cheap Chinese tablet that I picked up. Naturally it already has a version of Android 2.2 pre-installed. However, I have not been able to extract the contents of the boot.img or the system.img, I keep getting an error, whereas I can unpack the SDK img's no problem. So I was hoping that I can get away without compiling a custom kernel, use the already existing one, and go ahead with tweaking the system.img from either the AOSP or SDK sources. Getting the source code from the manufacturer may be impossible since I can't even seem to find out who the manufacturer is or get their contact info.
I'm actually looking to port CM7 to my wife's LG Shine Plus eventually, but I don't want to pull a Tim Allen on her phone so I want to get some experience and feel for working with Android's internals on my tablet.
So my next question is still about drivers, but what I want to know is how are things like the LCD, touchscreen input, audio output, wifi and the cell radio handled on a typical Android device? Is it mostly handled by the hardware itself with the Android framework or kernel just passing universal APIs or do the drivers for each individual piece of hardware need to be compiled into the kernel? As in the gkisystem for radios, is this handled by the kernel or the framework? Which kinda brings me back to my first question, if it is built into the kernel itself, can I not use, for example, the already existing kernel on the LG Shine Plus (it's running 2.1) to port CM7?
Any and ALL help is honestly and truly appreciated. I've been looking for detailed answers for these questions EVERYWHERE.

** just bumping this post so that it can get seen**

any help or advice at all?

[Q] How to communicate with custom made hw board?

Hi Xda developers,
I might get involved in project during internship, where they want me to find way how to connect android device to custom made proprietary radio transmitter-receiver board without bluetooth or wifi, so it has to be direct wired connection.
This radio transmitter-receiver board has its own microchips and firmware so all low level work and functions will be done in this board alone.
Does anyone has idea how this could be done? is it possible to write some drivers (probably C) to communicate with this board over micro usb port present in all android devices? And than how could be data received over radio used in basic java-android application installed on device? (could this be done with use of a binary/text file as a link between these two programs?)
Thanks in advance

If nobody knows or has time to answer my questions, please give me some tips where to start searching for answers (websites, books, magazines .... )
Is it essential to learn Linux architecture properly before modifying anything in android?

[Q] a smartphone with open source drivers

Which smartphone has the source for the drivers availbale at the moment?
To know what to choose in case i want to port tizen to it...

frullewulle said:
Which smartphone has the source for the drivers availbale at the moment?
To know what to choose in case i want to port tizen to it...
Click to expand...
Click to collapse
I just wanted to post a new thread with the same question.
Also, which are the phones with the best reverse-engineered drivers? And is there much difference between this and open drivers?
If you have open drivers you should pretty easily be able to port every system to it that supports the same specs as screen resolution, etc, right?

Unrelashade said:
I just wanted to post a new thread with the same question.
Also, which are the phones with the best reverse-engineered drivers? And is there much difference between this and open drivers?
If you have open drivers you should pretty easily be able to port every system to it that supports the same specs as screen resolution, etc, right?
Click to expand...
Click to collapse
Although it would be reasonable for you to think so, you would also be incorrect. The reason why this isn't the case is because hardware manufacturers each have their own different firmware that they use, which causes a lot of the bifurcation of the Android ecosystem. Just because you have two phones that are identical in every hardware fashion doesn't mean that their firmware is the same, so there is no guarantee that one set of drivers would work on different devices.

syung said:
Although it would be reasonable for you to think so, you would also be incorrect. The reason why this isn't the case is because hardware manufacturers each have their own different firmware that they use, which causes a lot of the bifurcation of the Android ecosystem. Just because you have two phones that are identical in every hardware fashion doesn't mean that their firmware is the same, so there is no guarantee that one set of drivers would work on different devices.
Click to expand...
Click to collapse
Ooohh, so underneath android and its Linux kernel lies a firmware that handles communication between the kernel/ Android and the drivers/ hardware? So I'd need open drivers and open firmware to be able to port anything with ease to this device (at least theoretically)?

Unrelashade said:
Ooohh, so underneath android and its Linux kernel lies a firmware that handles communication between the kernel/ Android and the drivers/ hardware? So I'd need open drivers and open firmware to be able to port anything with ease to this device (at least theoretically)?
Click to expand...
Click to collapse
Yes, but practically this is impossible as firmware comes straight from the manufacturer, so even if you could develop some sort of open firmware (basically you would be making an open BIOS), you would have no way to install it onto the actual device, since they are hard coded into the chip. You would need specialized tools in order modify on that level.

syung said:
Yes, but practically this is impossible as firmware comes straight from the manufacturer, so even if you could develop some sort of open firmware (basically you would be making an open BIOS), you would have no way to install it onto the actual device, since they are hard coded into the chip. You would need specialized tools in order modify on that level.
Click to expand...
Click to collapse
Awesome, I'm finally learning what I want to know!
So if there was a manufacturer who gave this firmware/ BIOS code away (because it's an old model or they have been convinced by the community or it's a dedicated device for developers or whatever) then it would be finally easy to port every system to it (that supports the hardware)?
And how come it is possible to port e.g. Linux to Android devices without having the sourcecode of the firmware/ BIOS? Because they reverse engineered it? And if you have a device with closed drivers you have to reverse engineer the drivers *and* the firmware/ BIOS? How come no manufacturer tried to build a developer device with open firmware/ BIOS since it would give them a lot of support from developers?

Theoretically yes, but then you would still face the issue of how you are going to interface with the hardware, as the chips were not designed to be interfaced with via usb devices. They tend to be programmed at production then never altered again.
Android is linux-based, so it would stand to reason that you could port a stripped-down version of linux onto the device. Using other tools, you can create a VM on the Android device to have a fully functioning version of linux, but this is all software-level, not physical level. And the reason why they don't make open BIOS is for the same reason textbook manufacturers keep making new versions of textbook that are almost exactly the same.

[ROM] Android Gingerbread on Zedboard not reacting to Touch/Mouse input

Hi,
I know that Android Gingerbread is quite old so probably most people would not bother to port it any more, but I need it for a university project where the hardware resources are very limited.
After a lot of work, I managed to build Android Gingerbread for the Digilent Zedboard, but it is not reacting to any touches on my USB touchscreen or to movements/clicks with a USB mouse.
getevent provides the expected events and I tracked them in InputReader.cpp and they seem to be dispached fine, but the UI does not react to the input. I can see that the events are enqueued, but cannot find where Android actually picks up those events and works through that queue. Does anybody have an idea?
I followed a tutorial on elinux.org (I am not allowed to post links yet. It's elinux.org [slash] Zedboard_Android)
with small modifications (enabled USB touchscreens in the kernel config, switched to a different android repo since the one in the article is offline)
Any help is much appreciated.
Thank you!

Android Gingerbread is no longer supported, and cannot use Google Play Services.
Why are you trying to run Gingerbread?
Please read THIS BEFORE responding.

Thanks for the answer!
x13 said:
Android Gingerbread is no longer supported, and cannot use Google Play Services.
Click to expand...
Click to collapse
I do not need Google Play Services.
x13 said:
Why are you trying to run Gingerbread?
Click to expand...
Click to collapse
We are trying to show dynamic partial reconfiguration with Android. For that purpose, we selected the Xilinx Zynq processing system. It consists of a dual-core ARM processor and an FPGA. The point is to reconfigure parts of the FPGA from Android during runtime.
Unfortunately, we were unable to find hardware designs for the upper-level Zynq chips and do not have enough resources to build one ourselves. Therefore we are stuck with the smaller chips and went for a ZedBoard.
At a point in history (I am not sure when) there was even official android support for the ZedBoard by iveia. They used android gingerbread, thats the first reason why we chose to use it.
The second reason is that the ZedBoard has very little resources (slow processor, little RAM, no GPU), which disallow more current Android versions to run. Some people got more recent version booting (google noritsuna android zedboard), but they reported it being slow since there is no gpu and low ram (they used linux swap since the built in ram is not enough for android - but linux swap from an SD card is terribly slow). Also, we were unable to replicate their build. All build processes go through but it does not boot. No debug output is available - not even kernel messages over UART. I suspect the u-boot setup is wrong but am no expert and cannot fix it.
Gingerbread is working fine (except for the touch issue), so we decided to stick with it.