Linux vs. Android: LINUX BE POSSIBLY INSTALLED ON ANDROID DEVICES?
Possible Methods of Android-Linux Dual Booting: CHROOT vs. LXC vs. VM
[Q] I download setup (an ISO) of Windows or Ubuntu from internet and install it on my laptop. The same ISO is booted and installed on my office PC and on my friend's PC. Then why can't I download Windows or iOS or Linux for mobile and install it on my mobile phone and my brother's?
[Q] Why I can't install the Android OS designed for my phone on my friend's phone? Both have same architecture (ARM) and same SoC vendor (Qualcomm) and same hardware vendor / OEM (say Samsung).
[Q] Why I have to download a firmware/ROM specific for my device?
[Q] Why a generic/regular Android OS installer is not available for all Android devices?
Let me try to understand it and explain it.
For an OS to work on a hardware, two conditions must be met:
- Software (OS) developers and hardware vendors/manufacturers willing to work with each other.
This is something purely related to business.
- Software (OS) and hardware willing to work with each other (compatibility).
This can be due to first point i.e. commercial constraints or due to technical limitations of one for other. We can classify this incompatibility in further classes:
- Difference of architecture
- Difference of hardware other than CPU and hence of drivers required
- Difference of booting process. It's also hardware related
Machines are to facilitate human beings. To interact with devices (digital machines), we need to talk to them in their machine language; the language of yes and no (0 and 1). They don't understand English. We (the laymen) don't understand zero's and one's. Operating systems solve this communication barrier by going through multiple layers of translating, interpreting , (de)compiling and (dis)assembling different languages between us and metal/silicon hardware. Human language is translated to some high-level language like C++, easily understood by human. Then it's translated to some low-level language like Assembly, easily understood by machine.
But as all humans don't understand same language, machines don't either. That's what define architecture. Since receiving and forwarding instructions is the responsibility of CPU, architecture is associated with CPU. Different CPU's understand different set of instructions like x86, arm, powerpc etc. Also there's difference how many number of instructions a CPU can process at a time i.e. 32-bit, 64-bit etc. While translating (compiling) a program from high level language to low level language, architecture is the primary concern. A program/binary/library compiled for one arch can't run on other and thus every OS (which is a set of programs/binaries/libraries) is not able to work with every arch. CPU architecture and the instruction set it uses form an ABI which decides the format of executable binaries, such as programs and shared libraries.
Broadly speaking, there are three flavors of OS's available to this day:
Most commonly used on home and office PC's and is proprietary i.e. we can't use it on any device according to our will unless the lord; Microsoft designs Windows for our device. They have very close ties with hardware vendors for better integration and compatibility with software.
Even hardware is proprietary and we can't use it on any device unless Apple does or permits to do so.
They both charge you a handsome amount for their software and/or hardware products providing a relatively stable solution but with very less flexibility for any further addition/subtraction. They don't want you know what's going on at back end, just enjoy what user interface offers and you may ask them if any support required. That's why they keep their source code (which is the translation between machine and human) closed because they invest in it. But to simplify our daily life tasks, we have a vast range of commercialized applications, software and utilities, available at a cost (or pirated; the other way ) that run on these proprietary platforms, Microsoft being on the leading edge due to it's easy availability and compatibility with large range of hardware. Thus, from a common user's perspective who doesn't want to indulge in technicalities, both of these are good options.
- Linux (most common of the Unix-like OS's) maintained by GNU and FSF
Open-source and free and anyone can mold it to use in any device; a baby toy, a video game console, a music player, a monitor, a small network router, a TV or a server hosting a full website and even more.
Another thing we need to understand is,
PC (and Laptops etc.) vs MOBILE (and tablets etc.)
1. PC STANDARDIZATION
There is no concept of standardization for hardware in mobile world. And no one wants either. Every vendor devises it's own way to initialize the hardware, unique and signed bootloader, non-persistent methods to enumerate devices (often hardcoded and provided by a Device Tree Blob), and devices grouped / linked in ungraspable combinations etc.
PC's are standard (so far; thanks to efforts made by IBM in past). You can buy a motherboard and compatible CPU, graphics card, sound card, network card and hard drive, all from different manufacturers and make a PC yourself (though the concept is becoming obsolete and out of the box approach is preferred). Linux and Windows will run on that PC. However, Mac won't. It's because both parties (software and hardware) GNU or Microsoft and hardware manufacturers (Intel, Dell, HP whatever) follow those standard PC specifications. Mac doesn't follow because Apple wants just to run MacOS on hardware supplied by themselves (thought there's Hackintosh now). That's why Mac means a complete unit (OS and hardware), not just an OS on DVD like Windows. There is no "Windows Book" like "Mac Book". There's Surface Pro but Windows is easily available for PC's.
This is different in mobile phone scenario. There is "Windows Phone" like "iPhone". Both are tied to hardware. Due to the closed source nature of iOS and Windows Mobile, you can't even think of using them on a device other than provided by Apple or Microsoft. There are technical restrictions you can't cross and then legal aspects. They themselves own hardware and OS both but situation is slightly different in case of Android.
2. ANDROID ISN'T OPEN SOURCE
Android, like Linux, being open source can be used on any device but only if you can make them work on your device. In fact Android isn't open-source, AOSP is. If you go through the process of baking (or making) a new OS (i.e. ROM) for your device, you will come across device specific DTB, kernel and proprietary blobs / HAL's (hardware specific files). AOSP doesn't provide hardware drivers, those are OEM's intellectual property and are specific to the device hardware and AOSP version as well. So, Android for ABC device can't run on XYZ device. Project Treble is a recent attempt by Google to address this issue. Though it's primary goal is to enable hardware vendors to release more frequent AOSP updates for old devices without touching their hardware specific code but this project will enable ROM developers to easily port ROM's from one device to other since the HAL's / drivers won't be necessarily modified.
Google develops a "look but don't touch" type of open-source core OS "AOSP" (not considering hardware aspects) and hands over to device OEM's. They earn indirectly by binding OEM's in "Open Handset Alliance". By signing licenses with OEM's on strict terms and conditions for Google Play Services and apps, users are made captive of Google Services; the biggest app store, search engine, cloud storage, maps, YouTube etc. and selling ads through them. Any vendor trying to replace Google's closed-source products with their own alternates is rejected in Compatibility Test, hence unable to use Google's ecosystem i.e. no more Play Store. What a user will do of such a phone with apps store? You will be seeing gradual replacement of open-source AOSP Browser, Email, Gallery with closed-source Chrome, Gmail, Google Photos. List is long with Google Dialer, Contacts, Calendar, Keyboard, Messenger, Play Music and so on. May be one day AOSP will be fully closed-source. Na?
But for the time being, once the OEM's have AOSP source code, they mold AOSP to their needs not following any hardware standards (as in PC's) and feed it to their hardware (with closed source drivers). So here OS (AOSP) isn't proprietary but drivers are. Both components become essential for each other. Hardware can't run others' software and software can't run on other's hardware. You are left with no option other than using their "product". OEM's i.e. device manufacturers make changes to OS i.e. kernel and onward: DTB, initramfs, hardware interfaces, drivers for audio, RIL, GPS, Wi-Fi, bluetooth, camera, graphics and subsequently UI and apps. Some OEM's release kernel sources sooner or later as they are bound to due to GPL, but mostly (white-labelers) don't.
Prior to kernel in booting process, there are SoC vendors who embed their own peripherals on SoC's as well as from third parties to make things complicated. At very core low level, BootROM / IBL / PBL (bootloaders) which are hard-coded on SoC/CPU are signed to load only signed SBL (secondary bootloader) which loads only signed aboot (application bootloader) which loads only signed kernel (if not unlocked). Where this chain of trust protects users' privacy, it protects SOC vendor's benefits as well. You can't replace bootloader to adapt the boot process for some other OS. All the bootloaders and multiple partitions to assist bootloaders contain proprietary contents, leaving you with least chance of customization.
"Replicant", an FSF project (the same group behind free Linux), is trying to replace proprietry parts of Android with free open-source drivers. But it's very hard to reverse engineer proprietary components and maintain Replicant OS for every device.
3. TECHNICAL LIMITS
Coming back to the technical aspects, PC's have a standard BIOS/UEFI on motherboard which can configure boot options and can boot from many bootable devices like USB or CD/DVD. So we can start installation of OS with a bare BIOS on PC which happily interacts with bootloader, whether of Windows or of Linux. OS have hardware support i.e. drivers from all possible manufacturers included in OS which are loaded and installed accordingly during installation process. Mobile devices are designed with lesser hardware resources and limited functionality. To make a mobile device multi OS supported, there come storage space and device compactness constraints and connectivity options thus installation media issues. There's no BIOS in mobile phones. You can't simply boot from a USB or optical drive and hence there's no installation of OS possible. Installation is somewhat irrelevant term for mobiles devices. Here, partitions are "flashed" i.e. ready-made material is extracted to them.
There have been successful attempts booting Android from USB / UART ports and before that using engineering SPL's when chain of trust inside SoC wasn't that tighter and it was possible to load IBL without integrity check. But it's impossible for most of Android and other phones due to electronically signed bootloaders. Read ANDROID BOOT PROCESS for further explanation.
PC's have hard drives which can be partitioned and re-partitioned. If something goes wrong, BIOS is there to handle booting part. You can put inside an old HDD living in your scrap box to boot your PC. PC OS's are bundled with utilities to handle this "partitioning" part automatically. And in most cases OS is installed on a single or two partitions. Mobile phones have eMMC's (flash media soldered to boards) which may have up to 50 partitions on it. And you can't think of playing with these partitions unless you are willing to buy a new phone which is the case when something goes wrong with partitions due to eMMC's completed number of read/write cycles after a year or two. You can hardly re-partition it. Addresses of partitions are hard-coded in SoC from where to load what. With a damaged bootloader partition, phone doesn't know what to do when you press its power button. There's a high probability that you will lose access to even Emergency Download Mode, which is the last resort. The same goes true when other parts are malfunctioning. Considering the cost of repair and replacement (if possible and available), you would definitely opt to replace whole phone.
In this scenario of so much hardware ambiguity and diversity, with "M" number of mobile phone models released today and with "O" number of operating systems available to till date, who and why will make "M x O" numbers of ports everyday so that users can enjoy the flexibility of desired hardware and software like on PC's?
What Linus Torvalds has to say about this scenario when comparing the silicon valley king of PC world; Intel (x86) and the major SoC vendor of Android phones; Qualcomm (ARM):
"I've been personally pretty disappointed in ARM. Not as an instruction set, although I've had my issues there, but as a hardware platform it's still not very pleasant to deal with... It doesn't have the same kind of unified models around the instruction set that we have in the PC space."
Second simple reason is, it's business. In mobile phones everything is proprietary; hardware and software, whether it's Windows or iOS or Android. If there's no commercialization and proprietorship, who will invest and bring improvements at such a high rate? If you use my software, why not my hardware? And vice versa. Making money by providing services and products isn't an ignore-able option in this materialistic world rather than running a sponsors' funded Free Software Foundation.
. . . continued . . .