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] android versions

i know much fuss is always made about devices getting or not getting updates to newer versions of android. but i don't understand why it's as big of a (technical) issue as it is.
android is based on linux, correct? anyone with a linux-based desktop regularly updates the kernel and various system packages without thinking twice. and the devices continue to work fine. i can run any version of ubuntu i want on my laptop, and they all work fine.
the problem with building the android osp for an arbitrary device is drivers, correct? is it because manufacturers don't release the source code for drivers? i can understand it isn't possible to reverse engineer or transfer a binary blob from one system to another.
but, manufacturers have these drivers (of course); why is it so difficult to package their drivers with newer versions of android? the kernel can't change so much that drivers need to be re-written with every version, or it would have died a long time ago.
this isn't meant to inspire flaming, i'm just curious what it really takes to build android for a device (and have it 100% working). if a device existed with 100% open source drivers, would it be trivial to build android for that device? how many proprietary drivers does an average device have? are they standardized at all beyond the ARM ISA?

[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.

Why don't phones exist with standard hardware, that you can install any OS on?

I have wondered this for a very long time
Why isn't there any phone hardware which exists (that I'm aware of) where you can simply install any OS you like without jumping through hoops?
I'm referring to something similar to a PC. When you build a PC, it is all standard hardware and you can load any os you want on it, endless flavors of linux, current or old versions of windows, etc. It is simple. Both windows and linux can generally detect all your hardware and install drivers, it is simple.
With phones however it seems you are always limited. You have to find ways to root them, usually requiring exploiting some vulnerability. Hope the bootloader is unlocked. Assuming you aren't a talented developer (like most typical people), you then must search for roms for the phone, usually made by various people on forums sites or similar. It is a big mess. Or if you don't customize it, your stuck with some bloated os that the manufacturer will fail to update.
I don't understand why phones are such a mess like this, and why you can't just buy an OS-less phone, and simply install vanilla android, or any other standardized open source os on it, similar to how things work on a PC?

There aren't any unified standard in the embedded devices in general and in phones in particular. The reason that you can install compatible OS on the PC is because IBM PC is a standard, which specifies how the PC should boot, where to search for the bootloader, what kind of partition table should be on the HDD, how the devices should be connected, how to probe for the hardware, how software should use hardware, and lots of other things.
In embedded word, there aren't such standard. Until recently, every System-on-Chip used its own boot specifications and bootloaders incompatible with each other. Only in the last 2 years something started to change in a better way.

[Firefly] [ROCKCHIP] [ITX-3588J] ITX-3588J ARM Android/Linux Dual "Deskphone" Progress

First off, I wanted to say I posted a few threads about this thing here asking questions about stuff I needed to get it working in the way I'd like and I'd want to thank you because I have made a lot of progress in getting it to be what I'd like it to be. I also don't know if this is the best forum to post this report because it's neither a question nor necessarily a tutorial but rather a summary and description of work already done so far, and especially because this device, while it sure runs Android (very well!) does not fit into any of the categories on this site neatly.
The story so far
This post concerns my experience working with the ITX-3588J, a board released just a few months ago by the Chinese manufacturer Firefly (or T-Chip Intelligent Technology Co. Ltd, based in Zhongshan) that is in the coveted mini-ITX form factor which means it can actually fit into a small-size desktop computer case and indeed has enough compute power to theoretically - and perhaps not so theoretically! - function as an honest desktop system with an ARM processor: namely the - also very new - Rockchip RK3588 system-on-a-chip.
About two months ago, I was looking into acquiring a new kind of computer to replace my somewhat longer on the tooth x86 machine that would be compact, low-power, and easy to transport while also being a fully capable desktop. And I certainly didn't want Apple. I had seen some very small form x86 desktops before, but I also knew there were many boards - like Raspberry Pi - that featured the ARM processor. Not content with the Pi, which is still very weak for this application at least when compared against modern software, I wanted to see if there was something else by now in a similar vein, and when I saw this board I thought it was an amazing option, esp. given I have not yet found a peer. Many ARM single-board devices exist but this is the only one I've found so far that looks to be in a proper desktop form factor and sporting a processor powerful enough to work at that level.
So I got the board, a case, and - noting it had SATA ports - a cheap 250 GB SSD, and put it all together ... and fired it up! And to my surprise, it booted up Android! Which was a real shocker because I generally thought this'd be like another PC board, not having had much experience with this ecosystem beyond phones, so that it would just give the usual "OS not found" stuff. Nope - pre-loaded on the board. Very minimal, very bare-bones though, not even the Google Play and similar essentials required for a usable Android experience. Yet with the little bit I had, I couldn't help but notice it was extremely fluid, responsive, and snappy, moreso than my aging 2018 era x86 box. Moreover, it was very, very interesting (and exciting!) to see Android booted onto a full-size monitor screen like Linux or Microsoft Windows - and actually and surprisingly, to see that it didn't look and feel all that bad!
However, of course, I wanted more. First, I wanted a fully-featured installation of Android. Second, I wanted to run Linux on it - especially given that, a short while later, I found that the board manufacturers were offering a stock Ubuntu 20.04 to be installable to it. Although, in the early stages, I didn't know how to do this at all, and then soon after learned how to reflash the embedded MMC chip to change the OS. And I did so, trying the Ubuntu and finding it also very performant, but not liking either that it was not quite the newest version but also more that it was mutually exclusive with Android - so far.
And that would begin a long - and at many times frustrating, especially given how much information out there is not at all tuned to a device like this being pressed into this application - learning journey toward exploring topics as diverse as how ARM processors and SoCs work under the hood, U-Boot, kernel features, the Firefly-Rockchip developer kit - and having to essentially single-handedly discover many of that kit's ins and outs given there was pretty much no documentation - and more, ultimately leading to where I've got it to now.
What it can do at this point
And that is, right now, I have it sitting here, loaded up with the stock Android 12 and Ubuntu 20.04 - with the former on the eMMC and the latter on the SSD hard drive. On the Android side, Google Play is now loaded and functional, though Google Chrome is not (it crashes with a "Telephony is null" exception for some reason, which seems to suggest for some reason it's trying to act like it's on a phone but isn't). Zoom - an app that I really, really wanted to have (and why I wanted to keep Android around on it) - works and works smoother and cleaner than my 2018 x86 Linux clunker. On the Ubuntu side, though, things are not yet coming - mostly because of seeming inability to use U-Boot to boot from the SSD. I managed to install GRUB, and given that Firefly's generous board SDK provides the full U-Boot source code was able to recompile it with the necessary "bootefi" command enabled which is not present in stock, but nonetheless alas this U-Boot seems to have its SATA support bugged or incomplete, because it would crash immediately upon trying to initialize that subsystem.
Where I'd like to go with it
Obviously, full dual boot of Android and Ubuntu, so getting U-Boot to boot the GRUB resident on the hard drive, is the biggest issue so far, and that means investigating whatever is the problem (or not?) in its SATA subsystem. Getting Google Chrome working on Android is another important step. Moreover - though it would cost extra money that I do not have right now - there's the very interesting possibility, owing to the fact that it has a built in M.2 slot on the board, and alluded to in the title - that the device could be made to act as a cell phone. And finally, the possibility of upgrading to a newer version of Ubuntu (ideally 22.04) - however from what I know so far, it looks like this will have to wait because the stock Linux kernels do not currently support the RK3588 fully - though I'd suggest the Linux kernel developers really should take a look at the SDK that came with this thing because it has lots of code in it including for the kernel, all under GPL.
Final note
One of the most interesting things I've learned from this project, and mentioned earlier, is just how well Android seems to work as a desktop OS. While there have apparently been some attempts to port it to x86, this is perhaps one of the first devices that is desktop-workable and which runs it natively. And one of the things I find that's nice about it is that ironically, because all the apps are designed for small screens, when they are run on a very big screen (and this monitor is not "very big" even by today's monitor standards, being a used and earlier LCD type), they are extremely easy on the eyes and have minimal UI clutter when compared to a typical desktop app on most Linux WMs and on MS Windows.
If you want to know more about the details, or anything else, feel free to ask any questions you might have!

UPDATE:
I believe I may have found an easier way to dual-boot Linux with Android, and that consists of configuring a custom ROM that will put both kernels, and GRUB, on the board's eMMC, while the rootfs for both OSes is placed on the hard disk. Will be seeing how it works.

UPDATE:
I have almost completed the custom ROM! I have now both Android and at least the base system for Ubuntu 20.04 (Kernel 5.10.66) bootable with Android now storing user data on the hard drive; though I'm still running into some hardware initialization issues in the latter that are keeping me from actually installing the desktop system. With regard to the Ubuntu system, there is some interesting issue in that for some reason the provided SDK kernel, which I had to rebuild, seems to build more Android-like because it wants to look in "/vendor" for some things related seemingly to the networking facilities, and it is possible this is preventing me from bringing up wifi, which I need in order to download the rest of the system.
But lots of progress overall - it seems that a full-fledged ARM desktop running simultaneously Android and Ubuntu is within reach to be wrung from this board!

Ignore my request for an update in another post. Seems you like you moving along. I don't need dual boot, just a working Android 12 with GPlay and Chrome. Did you get Chrome to work?

mebalzer said:
Ignore my request for an update in another post. Seems you like you moving along. I don't need dual boot, just a working Android 12 with GPlay and Chrome. Did you get Chrome to work?
Click to expand...
Click to collapse
Thanks. Yeah, I want to say that I have pretty successfully gotten Android 12 working on it for sure, but Ubuntu is proving much more difficult due to graphics support issues, and I'm not sure if it will be possible until RK3588 is supported in the mainline Linux kernel tree which is still something under development. And yes! I got Chrome to work Everything works, actually - it's great as an Android system, though obviously Android is kinda funny to use as a desktop OS. I am wondering if I can't get a "pseudo" Linux using something like Linux Deploy in lieu of running it natively, at least until the kernel development catches up with this new processor.
(FWIW, I'm posting this post from that machine while it is running A12. )
Good to see someone else is interested in it, though. What are you planning on using yours for?

Insofar as getting Android 12 to work w/GApps - it depends on if you want to do it purely on the eMMC or you want to also put user data on an attached hard drive like I did. In either case, the best option, I feel, is to create a custom ROM - I could provide custom ROMs for it for download, but don't know because of Google's licensing conditions around the GApps and have heard of people getting in trouble with Google for distributing custom ROMs for phones that have GApps in them. You basically need to unpack the stock Android image, unpack the "super.img", then load the apps from a package like NikGApps into the "product" partition (NOT "oem" - that was a big mistake), then repack everything and flash to the eMMC again. You will need the board SDK from Firefly for all this as it has the custom ROM-packing and flashing tools.
Alternatively, it is possible to manually install the NikGApps GApps using the Android console - as it's a fully unlocked system, obtaining root access is trivial: just put it into Developer mode and you will find the root access in the "Developer options..." menu under "System".

Shimmy99 said:
Insofar as getting Android 12 to work w/GApps - it depends on if you want to do it purely on the eMMC or you want to also put user data on an attached hard drive like I did. In either case, the best option, I feel, is to create a custom ROM - I could provide custom ROMs for it for download, but don't know because of Google's licensing conditions around the GApps and have heard of people getting in trouble with Google for distributing custom ROMs for phones that have GApps in them. You basically need to unpack the stock Android image, unpack the "super.img", then load the apps from a package like NikGApps into the "product" partition (NOT "oem" - that was a big mistake), then repack everything and flash to the eMMC again. You will need the board SDK from Firefly for all this as it has the custom ROM-packing and flashing tools.
Alternatively, it is possible to manually install the NikGApps GApps using the Android console - as it's a fully unlocked system, obtaining root access is trivial: just put it into Developer mode and you will find the root access in the "Developer options..." menu under "System".
Click to expand...
Click to collapse
Thanks I will keep this in mind. See my reply to you other reply on another post as well.

I would to run gplay as well please send me instruction the nikapps github doesnt say nothing