Nevertheless I do not want to stop this topic here because I guess the problem is just postponed (hopefully for quite some time). But what I don’t get is, why isn’t there a rudimentary open source OS, which you can install on nearly any smartphone? I mean it is the same way linux works on PCs.
No, for two reasons:
- Linux has a common codebase for all (most) devices, while Android is adapted to the specific chipset of a device.
- The FP1 has a Mediatek chipset (MT6589) and unfortunately Mediatek chipsets are especially hard for developers to work on. Fairphone didn’t consider this when they wanted to incorporate conflict-free tin and tantalum in a phone.
3 Likes
Thanks Stefan for the answer, but could you explain reason1 in more details?
You mean this, right?
Since Android is very fragmented you cannot simply install the Android on every phone. You cannot even take the same Android build that other devices with the same chipset use because of the peripherals (camera etc.) and their drivers.
I think that the reason for the fragmentation lies in the roots of Android. It was created by Google as a competitor to the successful iOS and they found that they could only compete if they open-source their OS (interesting classic read with current relevance). Unfortunately they didn’t have higher goals and there is no incentive for phone vendors to contribute their code back and work on a common codebase.
Does this clarify things or do you have a specific question? 
PS.: Splitting this discussion off because it is going off-topic.
2 Likes
Thank you so much @Stefan. This clarifies the situation
1 Like
It is not just about Android. This is about how phones are developed in general, and some fortunate events in the history of computers that didn’t happen for phones.
On computers it has historically been possible to install the OS yourself, re-install it or upgrade it and there is to a certain extent compatibility between different computers. This started with the IBM PC: IBM allowed other companies to produce parts for this computer, or even create clones of it.
As IBM PCs and their successors were expandable, operating systems needed to know which parts were built in, and standards were designed to allow the OS to detect this automatically. And if a driver were missing, most hardware had the possibility to fall back to one of the old standards designed by IBM and contemporaries, which provide basic functionality good enough to install the driver in question. Examples are the VESA standard for graphics, which modern GPUs still support, or the PS/2 protocol for mice, which modern laptop touchpads still support.
For phones, there has never been any question of expansion until FP went modular and put an expansion port on the back. For a phone OS, it’s always been enough to have all parts of the hardware hard-coded, instead of having a way to detect what parts are present.
This means that for any Android build, you need a configuration file to specify the hardware in the phone, and you need to pre-install every driver or the hardware will not work at all. There are no fall-backs to old basic standards in phone hardware. I guess, that Fairphone will have had to do some work of their own to allow Android to detect the type of camera!
(A notable exception are USB OTG devices; those can be detected automatically of course as USB was designed by PC engineers, instead of their smartphone colleagues. Here, the Linux kernel does offer the same functionality as on a computer.)
To add to this point: PCI(-express) and USB have been designed such that you can ask the device to identify itself. These mechanisms allow you to plug in e.g. a wifi card into your desktop computer and have it Just Work™ in Linux. Other components on your motherboard are described in the ACPI configuration of your motherboard. In contrast, most hardware inside a “system-on-chip” (SoC) and even peripherals connected to this central component do not have the means to identify themselves, simply because - historically at least - there has been no point in wasting power and transistors on such a feature when in practice the configuration never changes.
Another point to keep in mind is that a Linux desktop installation carries pretty much the drivers for any component your computer could possibly contain. As you can imagine, this takes up quite a lot of storage. Of course, as a phone manufacturer you know that for instance your Qualcomm SoC will never have to communicate with a Broadcom sound component, hence you can decide to simply get rid of the device drivers for the latter. By building the Android operating for one specific phone and only shipping a minimal set of device drivers, you get an easy way to save yourself a lot of storage space otherwise wasted on unused device drivers (we’re talking hundreds of mebibytes easily), space that can then be used for other purposes like apps and photos.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.