12

I am used to install and remove various operating systems in my PCs, even having several at a time.

Usually, to install a new OS means:

  1. Burn the ISO to a CD/DVD/USB.

  2. Insert it.

  3. Boot. (Maybe you have to tweak a bit the BIOS first).

The only difference between PCs is its CPU architecture: x86, x86_64, arm, etc. Depending on that, you have to download one ISO or another. But I never have to worry about which graphic card, mouse, keyboard, screen, network card, etc. it has. The install wizard automatically detects that and installs the corresponding drivers. Sometimes, if they are not bundled, the installer also downloads them. Anyway, the key point here is that the ISO is always the same.

Now, many mobile OS come out: Ubuntu, Tizen, Firefox OS, the omnipresent Android, and why not any Linux ARM distro out there!. Sadly I have a random chinese mobile, that surely will never get official support in any platform, and I will never be able to test them.

But... Are not today's phones just tiny ARM PCs? Why is installation that different? Why do I always need to have a precompiled monolithic ROM specific for my phone model? Why not just a single "ISO" per OS for any phone that detects and installs automatically the needed drivers, just like always has been in the PC market?

Note: I understand the problem with privative drivers, but I remember Debian asking me for those when there were no libre alternatives at installation, and I could install them then or later. I suppose that workaround could be used in those cases too. Correct me if I'm wrong.

11

In short, it's because of the different ways that Android and MS Windows are distributed. MS Windows is a retail product, sold directly to PC owners. Therefore, Microsoft is responsible for making it run on PCs. PCs are standardized, and (nowadays) have a hardware-discovery mechanism, so Microsoft can design the Windows installer so that it can run on any PC-compatible machine. It's in their interest to make drivers for old Windows versions compatible with newer versions, so that they can keep selling new Windows versions to users.

There's also a technical dimension to this. Phones aren't just "tiny ARM PCs" as you suggest. The distinguishing thing about a PC is that it satisfies the PC specification, originated by IBM but now specified by an industry consortium. There are several more standards for how components of a PC interact, and they're what allows automatic driver configuration such as you find on a desktop PC. Graphics cards offer a VESA interface, which allows graphics to be displayed before a GPU driver has been configured.

All PC hardware nowadays offers Plug N Play, which allows the OS to discover hardware and configure the memory map at boot. Before Plug N Play, you had to change physical jumpers on each PCI card, and then tell the software what memory range, IRQ, etc. you'd set on the jumpers. And in the days before DirectX and its ilk, you had to do that separately for every game that wanted to use that hardware. Plug N Play came about mostly so that sound card (and other discrete component) vendors could make easier-to-install hardware.

In contrast, Android isn't a product that's sold to users: it's "sold" to device manufacturers. Phones (also tablets, STBs, media players, etc.) don't have anything like the PC specification, so it's not possible for Google to make an "Android installer" that can run on any device. Even displaying the battery animation when the phone is off requires it to load the Linux kernel with a framebuffer driver and a battery driver. It's the device manufacturer's responsibility to modify the Android source code so that it can run on their device, and the resulting Android firmware image belongs to the manufacturer: they don't (have to) give those changes to Google or anyone else.

The phone world doesn't have these kinds of standards, because there's no demand for it. There's no one trying to sell phone components that you put together yourself. No one in the phone industry is interested in making an OS that you can install on any phone - only the likes of Ubuntu and Mozilla, who are outsiders with no contribution to hardware standards.

5

The first problem is space. Most phone until recently have too little storage space to contain the entire generic kernel and android framework. A compounding issue is that phone hardware is generally more variant and less standardized than PC hardware, which can be unavoidable due to the limited space.

The other problem is that there no single standard for flashing method among stock boot loaders. With PC, you have the standard booting from CD and booting from USB drive method; in the standard external drive booting method the PC is the USB Host, but Android generally acts as USB Client. This is also reflected in the choice of cables, the Android side of the USB cable is usually a USB micro and most external drives also use USB mini, this means the physical connection requires you to get a USB micro to USB micro cable, which is relatively uncommon.

Finally, the last problem is political. Manufacturers and carriers have no incentives to change the status quo, only a very small minority of users are going to flash their device, which will usually void warranty. They have no incentive to encourage people to install a boot loader that makes it easy to void warranty and which often cause support nightmare.

5

Besides the points mentioned in Lie Ryan's answer, there is one big issue people tend to underestimate: Drivers.

Remember Windows 95? Most people remember it as a bad and unstable OS. Why was it unstable? Because the drivers came in the beginning not from Microsoft but from the hardware manufacturers and some (most?) of them where of poor quality, crashing the whole system. Of course the user in front of the PC blamed the OS, because that was what appeared to be crashing, and not the driver.

Writing hardware drivers is not an easy task: You have to know the OS API, you have to know the hardware, you have to know the computer architecture and if you just make little mistake the most OS (these without good isolation) will crash.

Let's have a look at the other open source operating systems, most of them comes with a superior architecture and use more hardware features then Linux. Then why doesn't everybody use them? I'd say it's because they lack drivers. Why should I choose a OS that doesn't support my WiFi hardware?

Now, let's have a look at the target platform about you are wondering why there is no install medium available. Android devices are highly specialized and use hardware that

  1. is not available to the masses (e.g. you can't usually but the sound chip used in a typical Android device)
  2. need driver that are proprietary (i.e. only the hardware manufacturer has access to the source of the driver)
  3. is manifold

that makes is hard to compose an install medium that works for every, or even most, devices.

The usually approach to install GNU/Linux on an Android device is to use the available environment (Bootloader, Kernel (incl. Drivers), libc). This avoids all the issues mentioned in the answers.

  • The current Android driver source available on the web probably covers a large part of the hardware. The problem this answer doesn't mention is the lack of hardware discoverability. Even if you shipped a generic Android that had all the drivers in the world, the reason it wouldn't work isn't that it would be too big, but that the kernel wouldn't know what drivers to use without a device tree. – jiggunjer Feb 13 '17 at 8:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.