[TheAceOfHearts]

Something I've wondered about: why does Android require you flash a ROM to update the system?

When you buy a windows laptop you'll usually get a bunch of vendor-specific crap, but after doing a clean install you can just pick up the drivers on their website and it'll all work fine. Why isn't this an option with Android?

[dispose13432]

ARM's SoC lack of standards.

In reality, we were really spoiled with IBM's massive mistake in standardizing the PC (the BIOS), so while Linux may not pick up your monitor, your monitor is made to work to a basic standard (VGA), so you can at least boot up, read the hard-drive, and have basic "keyboard" IO.

This was really important before Win95 made the PC practically MS owned, as you could (and were expected to) install whatever OS you wanted, so they had to have a standard Boot Sector, etc.

ARM SoC are meant to be built by a manufacturer to their specs (their CPU doesn't have to be compatible with anything because nothing is user-serviceable anyways). In other words, PCs were meant to be an Open Standard, while SoC are like old consoles/"dumb" phones.

Unfortunately, due to MS dominance in the PC world, and the collapse of independent computer manufacturers (I remember the days when buying a cheap computer meant not going to Dell but going to the mom-and-pop shop down the block, but you had to know how to fix things if anything went bust), the PC is moving slowly but surely to the appliance world.

[jimmies]

As I have been involved with OpenWRT/LEDE and how they make builds to different devices recently, I realized that making unified builds are actually possible. OpenWRT has the same kernel and root image for many different devices that use the same SoC. So once you have OpenWRT flashed on, the content of every OpenWRT update (for every device of the same SOC) is by and large the same. The only check in place is the artificial model check to make sure you don't unintentionally flash the wrong image.

Android can technically do like OpenWRT does, but there is much more stuff involved in the Android world so making a universal build is harder. However, I personally can't think of a hard, technical barrier. New ideas for unifying devices and separating blobs such as device tree or separate vendor partition is getting traction and makers such as Sony are embracing it. Many Sony devices boot the same kernel, and that's why you consistently seeing Sony devices getting support and builds very early on from projects like CM.

BTW, I have been trying to write an answer to you by saying a slightly different version of what dispose54312 said, but then realized it didn't make sense. I came to the conclusion (for myself) this is mostly "how it is done currently for Android." So I hope my unpopular answer is not crazily misguided, and please take my perspective with a grain of salt.

[em3rgent0rdr]

Thanks for your work on OpenWRT...I'm a happy user! I would hope for any expertise on unified builds could be transferred over to android. I'm wondering if android could run on top of OpenWRT, then could use the same system to update the android layer without having to update the lower levels.

Would think one of the whole points of having the many layers in the android software stack is that one layer can be modified without having to reload everything in the lower levels.

[josteink]

> Something I've wondered about: why does Android require you flash a ROM to update the system?

Let me answer that by picking the question apart:

1. To update the system, you need access to write actual system-files. You need system-level access.

2. Android is built entirely up on a "user-space" model where permissions are granted to apps, and almost no apps have system-level access.

3. On rooted phones you can allow system-level access to specific apps, which in theory could install the latest OS version and binaries. In theory that sounds like 1 app which you can use to update the OS, everywhere, right?

4. Except you would need a different installation-strategy for unrooted phones anyway for the installation anyway.

5. To compound the problem the ARM platform has no standardized BIOS/UEFI layer to handle generic booting, so the kernel being booted must be device-specific in order to gain access to the rest of the phone: It can't rely on generic "BIOS"-drivers to load modules on demand from flash storage. And the boot-partition is almost always too small to have a kernel with enough drivers for "everyone" embedded.

6. So you cant make a standard phone-agnostic flashing-app, nor install medium. You do have to build a custom phone-specific initial flash-package for every model you want to support as a bare minimum.

And when you've already put in all that effort, what do you gain by creating an "app" which does this inside a pretty GUI, instead of just rebooting back to recovery to (auto) flash the latest image? Practically nothing.

"Flashing" may sound scary, but in reality it just means installing. There's no technical difference between that and just copying files to a usually write-protected partition.

AFAIK: Apple officially does exactly the same, they just don't call it by that name.

[codedokode]

There is a "fastboot" [1] tool from Google that interacts with phone bootloaders that support it and can be used to flash the ROM.

> There's no technical difference between that and just copying files to a usually write-protected partition.

"Flashing" usually means "uploading" a filesystem image onto a partition, not copying single files.

[1] https://source.android.com/source/running.html#booting-into-...

[josteink]

Fastboot is a interface/protocol to talk to the bootloader, in order to flash images to select partitions. On select phones. And it requires an external device to run the process. So it can't be self-hosted.

All that technical whizbang doesn't change or even address the underlying problem: What you boot still needs to be 100% device specific.

There's no UEFI/BIOS on ARM to help bootstrap the boot process.

Also: When you flash custom roms on Android, you format and then unzip a file onto the system partition. Not that I see how that's technically any different from flashing a FS-image, but if it matters to you, now you know.

In conclusion: none of my claims have been near disproven, but a few straw men has been presented to be stricken down ;)