I’m sorry if this sounds like a stupid question but why won’t android just straight up run like Linux distros that almost run on any computer? Why does each model under each manufacturers require separate maintainors seperately? Aren’t they running like almost similar hardware like processors from Qualcomm, mediatek, Exynos, etc? Why hasn’t there been a single android os that is compatible with all the device?
Because of lack of standardised firmware on smartphone. PCs uses UEFI + ACPI to give information about devices to OS, on smartphone world different chip manufacturer have different bootloader and they load linux kernel and pass DT(device tree) which explains what devices are present and also smartphone were used to be less powerful, contains less storage (in past) so what they do is to compile linux with only the drivers which are actually present on that particular devices to save space. Thats why a smartphone rom is not a generics image which will run on all phone. But android/linux can be compiled like a generics image, look androidx86 project for example.
Also due to the windows, windows OS is closed source so device manufacture can’t simply modified it for their devices. They have to pass compatibility test which includes UEFI + ACPI compliant firmware to be present to be actually windows compatible (to get that sticker on their devices) without that microsoft will not provide windows licence to you i guess
PC architecture is very standardized. ARM is like the wild West where nothing is standard. Everything needs specialized drivers that need to be compiled along with the operating system in order to even work.
RISC-V may only be better in the sense that it’s an open, transparent framework. But I would expect a lot of “Embrace, Extend, Extinguish” behavior from any larger manufacturers in the market.
Hardware specifications are still mostly secret, and the lowest level code that interacts with the hardware is still mostly distributed as an unreadable binary file.
As long as our hardware is full of secrets, running our own software on it will be like exploring a cave without a light.
The hardware is generally not open source, and it’s technically illegal in a lot of jurisdictions to redistribute the binary blobs that make it work without permission from the manufacturer (basically never has happened). Because there is minimal focus on forward and backward compatibility, different chips from the same product line are very often incompatible with each other, let alone from different manufacturers.
So phone ROM maintainers have the job of stripping out those binary bits from a recovery image for a given phone or something and then getting them working with an open source build of android. All the while taking a (albeit kinda low) legal risk. Take a look at most of the long running open source Android projects and you’ll see they have had to structure their projects to mitigate legal exposure.
In Linux most of the hardware support is just straight up open source, the bits that aren’t (typically GPU or specialist hardware drivers) are manufactured by people that want you to use their hardware on Linux, so they release prepackaged drivers for you to use.
Phone manufacturers are motivated to try and ensure everyone uses their stock ROM because ultimately they have to support the device if a user breaks something, and that’s easier for them when they eliminate as many variables as they can. Even if they can charge the user out of warranty, it’s still tying up support resources from their perspective.
ROM because ultimately they have to support the device
They also make deals with companies as to what their preload has, what the preload forbids from being uninstalled, and what subscription services for into their platform.
x86 and its descendant 64 bit architecture get hardware initialization and discovery through BIOS, whereas in the ARM world (which is what phones are built in) hardware needs to be described in device trees (DTS) where hardware adresses, chips and drivers are matched
There are 2-3 major roadblocks. Like others mentioned we simply lack drivers. But in my opinion the biggest issue is the lack of a BIOS equivalent for ARM systems.
Most PCs use x86 processors while most phones use ARM processors. And most x86 systems come with a BIOS (nowadays UEFI). That is a very simple operating system that runs when the computer starts and it gives a standard way for other operating systems like Windows and Linux to start up. That way the same x86 operating system can start on just about every x86 computer.
ARM lacks this standardisation. Although there do exist some projects to fix this they are not in use on most phones. So you actually have to make a custom way to just start up for each and every phone.
On top of that and the general lack of drivers many manufacturers lock their phones down so that only their own operating system may start.
Mainly two reasons, one about architecture, and one about vendors
In the PC world, the entire ecosystem is designed to be modular, and people expect to be able to put windows/Linux on any pc and have it work despite the manufacturer. The kernel just wakes up on one of the cores, figures out the CPU, wakes the rest of the cores, and from there it figures out the rest of the computer. By contrast arm systems are tightly integrated, each SoC is unique and there’s no way to figure out the rest of the system, the kernel wakes up on one of the cores, reads out what SoC this is, and mostly has to already know the chip and any additional hardware connected to it.
But, sure, there are only so many SoCs (kinda), and displays, cameras, and touchscreens are mostly similar, you are bound to find a way to tell the kernel what hardware is running on and have it work, right? Except a lot of phone hardware is proprietary (duh) and requires bespoke proprietary drivers, google pretends to encourage vendors to submit their drivers upstream, but this doesn’t really happen. Now, if you are familiar with running external drivers on Linux, you probably know how picky the kernel is in what to load, but android’s kernel is specifically modified to be less picky, to allow vendors more slack. Mind you, the API is not more stable, the kernel is just less picky.
Bonus: running Linux on arm laptops is indeed proving kind of a challenge (nothing impossible, but resources are limited), that’s because they are built like a mobile phone.
Android is an operating system, not hardware. Android uses the Linux kernel, but differs greatly from desktop-oriented Linux distributions. Most phones are designed for Android, a bit like most PCs are designed with Windows in mind.
Desktop-oriented Linux distributions have a semi-standardized software stack with Linux, GNU libraries and utilities, a shell, X11 or Wayland, some sort of window manager or desktop environment, etc…
Other comments have explained how the hardware makes it difficult to have generic operating systems that install easily on any phone like we do for PCs, but they do exist. Ubuntu Touch and PostmarketOS are examples of desktop-like Linux distributions for phone hardware. It’s possible to install and use these on certain phones, but there’s usually a feature or two without a working hardware driver. Desktop Linux on laptop computers used to be that way too, but far fewer laptops have missing drivers now than a decade or two ago.
I have PostmarketOS installed on an older phone. I don’t think the user experience is quite ready for most people to use as their primary phone, even for me, and I’ve been running Linux on laptops for most of my adult life.
Android uses the Linux kernel so, all android hardware has Linux kernel drivers.
Also android is kinda open source. The hardware layer source mostly isn’t released by the vendors. Its mostly illegal, but they get away with it anyway.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: [email protected]
DROID DOES
Welcome to the Android community on Lemmy. Here you can participate in amazing discussions and events relating to all things Android.
5. Engage respectfully: Harassment, flamebaiting, bad faith engagement, or agenda posting will result in your posts being removed. Excessive violations will result in temporary or permanent ban, depending on severity.
6. Memes are not allowed to be posts, but are allowed in the comments.
7. Posts from clickbait sources are heavily discouraged. Please de-clickbait titles if it needs to be submitted.
8. Submission statements of any length composed of your own thoughts inside the post text field are mandatory for any microblog posts, and are optional but recommended for article/image/video posts.
Because of lack of standardised firmware on smartphone. PCs uses UEFI + ACPI to give information about devices to OS, on smartphone world different chip manufacturer have different bootloader and they load linux kernel and pass DT(device tree) which explains what devices are present and also smartphone were used to be less powerful, contains less storage (in past) so what they do is to compile linux with only the drivers which are actually present on that particular devices to save space. Thats why a smartphone rom is not a generics image which will run on all phone. But android/linux can be compiled like a generics image, look androidx86 project for example.
Also due to the windows, windows OS is closed source so device manufacture can’t simply modified it for their devices. They have to pass compatibility test which includes UEFI + ACPI compliant firmware to be present to be actually windows compatible (to get that sticker on their devices) without that microsoft will not provide windows licence to you i guess
PC architecture is very standardized. ARM is like the wild West where nothing is standard. Everything needs specialized drivers that need to be compiled along with the operating system in order to even work.
Out of curiosity, is this something that RISC-V does better, or are they going down the same path as ARM?
RISC-V may only be better in the sense that it’s an open, transparent framework. But I would expect a lot of “Embrace, Extend, Extinguish” behavior from any larger manufacturers in the market.
Most RISCV boards don’t support BIOS/UEFI AFAIK
I’m not as familiar with RISC, but my gut tells me that’s it’s a similar situation to ARM. Take that as you will.
Long answer short:
CPU Architecture.
With ARM the drivers need to be compiled with the entire OS, they can’t just be installed later.
We have plenty of open software.
What we need next is open hardware.
Hardware specifications are still mostly secret, and the lowest level code that interacts with the hardware is still mostly distributed as an unreadable binary file.
As long as our hardware is full of secrets, running our own software on it will be like exploring a cave without a light.
This is why I own a pinephone
Ready for daily use?
Have you gotten android apps (specifically Signal) working on it?
Edit. Spelling mistake.
Nice. I am hoping/planning that my next phone with be either a FairPhone or a PinePhone.
There’s also Volla Phone (with Ubuntu Touch or dual boot Android/Ubuntu Touch).
Perfect analogy.
Thanks!
The tl;dr is: Control. Vendors want it, making it easy to run open software would make that control harder to keep.
The hardware is generally not open source, and it’s technically illegal in a lot of jurisdictions to redistribute the binary blobs that make it work without permission from the manufacturer (basically never has happened). Because there is minimal focus on forward and backward compatibility, different chips from the same product line are very often incompatible with each other, let alone from different manufacturers.
So phone ROM maintainers have the job of stripping out those binary bits from a recovery image for a given phone or something and then getting them working with an open source build of android. All the while taking a (albeit kinda low) legal risk. Take a look at most of the long running open source Android projects and you’ll see they have had to structure their projects to mitigate legal exposure.
In Linux most of the hardware support is just straight up open source, the bits that aren’t (typically GPU or specialist hardware drivers) are manufactured by people that want you to use their hardware on Linux, so they release prepackaged drivers for you to use.
Phone manufacturers are motivated to try and ensure everyone uses their stock ROM because ultimately they have to support the device if a user breaks something, and that’s easier for them when they eliminate as many variables as they can. Even if they can charge the user out of warranty, it’s still tying up support resources from their perspective.
They also make deals with companies as to what their preload has, what the preload forbids from being uninstalled, and what subscription services for into their platform.
Hardware incompatibility between phones. The PC world is much better standardized.
x86 and its descendant 64 bit architecture get hardware initialization and discovery through BIOS, whereas in the ARM world (which is what phones are built in) hardware needs to be described in device trees (DTS) where hardware adresses, chips and drivers are matched
that’s the simplified, short answer
Does that mean that it is basically impossible to replace the hardware in an ARM Computer because of the mismatches?
There are 2-3 major roadblocks. Like others mentioned we simply lack drivers. But in my opinion the biggest issue is the lack of a BIOS equivalent for ARM systems.
Most PCs use x86 processors while most phones use ARM processors. And most x86 systems come with a BIOS (nowadays UEFI). That is a very simple operating system that runs when the computer starts and it gives a standard way for other operating systems like Windows and Linux to start up. That way the same x86 operating system can start on just about every x86 computer.
ARM lacks this standardisation. Although there do exist some projects to fix this they are not in use on most phones. So you actually have to make a custom way to just start up for each and every phone.
On top of that and the general lack of drivers many manufacturers lock their phones down so that only their own operating system may start.
Mainly two reasons, one about architecture, and one about vendors
In the PC world, the entire ecosystem is designed to be modular, and people expect to be able to put windows/Linux on any pc and have it work despite the manufacturer. The kernel just wakes up on one of the cores, figures out the CPU, wakes the rest of the cores, and from there it figures out the rest of the computer. By contrast arm systems are tightly integrated, each SoC is unique and there’s no way to figure out the rest of the system, the kernel wakes up on one of the cores, reads out what SoC this is, and mostly has to already know the chip and any additional hardware connected to it.
But, sure, there are only so many SoCs (kinda), and displays, cameras, and touchscreens are mostly similar, you are bound to find a way to tell the kernel what hardware is running on and have it work, right? Except a lot of phone hardware is proprietary (duh) and requires bespoke proprietary drivers, google pretends to encourage vendors to submit their drivers upstream, but this doesn’t really happen. Now, if you are familiar with running external drivers on Linux, you probably know how picky the kernel is in what to load, but android’s kernel is specifically modified to be less picky, to allow vendors more slack. Mind you, the API is not more stable, the kernel is just less picky.
Bonus: running Linux on arm laptops is indeed proving kind of a challenge (nothing impossible, but resources are limited), that’s because they are built like a mobile phone.
Let’s clarify some terminology.
Android is an operating system, not hardware. Android uses the Linux kernel, but differs greatly from desktop-oriented Linux distributions. Most phones are designed for Android, a bit like most PCs are designed with Windows in mind.
Desktop-oriented Linux distributions have a semi-standardized software stack with Linux, GNU libraries and utilities, a shell, X11 or Wayland, some sort of window manager or desktop environment, etc…
Other comments have explained how the hardware makes it difficult to have generic operating systems that install easily on any phone like we do for PCs, but they do exist. Ubuntu Touch and PostmarketOS are examples of desktop-like Linux distributions for phone hardware. It’s possible to install and use these on certain phones, but there’s usually a feature or two without a working hardware driver. Desktop Linux on laptop computers used to be that way too, but far fewer laptops have missing drivers now than a decade or two ago.
I have PostmarketOS installed on an older phone. I don’t think the user experience is quite ready for most people to use as their primary phone, even for me, and I’ve been running Linux on laptops for most of my adult life.
Phones have very different hardware
Touch screen
Accelerometers
Compas
Gps
Various antennas etc
So theres a lot of stuff needed that i dont think is part of … the linux kernel.
That said, isnt android open source?
Just fork it, strip out the stuff you dont want, add the stuff you do want
Android uses the Linux kernel so, all android hardware has Linux kernel drivers.
Also android is kinda open source. The hardware layer source mostly isn’t released by the vendors. Its mostly illegal, but they get away with it anyway.
Because a PC tells the OS what hardware is present. Phones do not, that’s why there is no hardware detection.
Nobody forces phone makers to support the standard that would just do that: https://www.arm.com/architecture/system-architectures/systemready-compliance-program
LineageOS?
Stock Android pretty much does, but it isn’t what you think it is..
What did Google say that you didn’t understand?