One of the major major major issues is the hardware itself.
Let's jump back to the late 90s. You want to try Linux. You might partition your disk, or build a different machine and get a KVM or use an old laptop or add a second hard drive. In all cases, you can just install a Linux distro and see if it works. Maybe Ethernet or sound or something doesn't work. You could try a different distro with a newer kernel, maybe compile your own kernel with the modules you need, etc. But no matter what, it would at least boot (usually).
Intel x86/64 is a standard architecture. EFI makes the booting process even easier (although some motherboards still fuck this up; but for the most part fiddling with efibootmgr and turning off TPM will work. If not you can always turn on legacy BIOS and use the MBR). ARM is not a standard architecture. It's a spec that is sold to companies who all make their own SoC templates. There are things like Device Tree Config that make some of this more standard, but it's still far from x86/64. Just read Torvalds rants on ARM to learn more.
Even if you make some standard Android builds with all the drivers for all phones in a massive 20MB initrd, a lot of kernels are fundamentally different with the way bus connections are defined. Manufactures take forever to release their kernel code, often under threats by people for GPL violations, and even then they are filled with tons of binary blobs and shims that connect their .o files so kernel calls.
Stuff like Plasma looks amazing. It only has like two phones it supports. If you look at any android rom project, you see totally different builds for every single device. If Intel had been like this, Linux would have died off in the 90s, for both servers and desktops.
Device manufactures depend on you buying new phones. They cannot support phones after two years or else it kills their profit margins. Planned obsolescence like this leads to waste (don't kid yourself, e-waste recycling gets shipping to Africa where kids remove components. A small percentage of phones actually get recycled).
TL;DR Mobile phones are based on unmaintainable and non-standard hardware (intentionally). I wrote a post on this a while back:
>Device manufactures depend on you buying new phones. They cannot support phones after two years or else it kills their profit margins.
This is the reason after using Nexus devices for 5 year, I will buy an iPhone and I will never ever look at Android again. My girlfriend switched from Galaxy note 4 to iPhone last year, and she is amazed how much iPhone experience is better than high-end Android experience.
2 year only update? Give me a fucking break, this total rip off. If I remember correctly even iPhone 5 does get update(and remember iPhone 5 is 5 year old phone, which will get new version of OS, not just security update, this alone is more than lifespan of Nexus or pixel device). Let alone the fact phone processors passed the threshold, phone produced after 2015 are almost as powerful as desktop from ~2005. My point is , if you don't play intensive games or any specific use case, an above ordinary phone would run browser,mail client, chat apps for more than 4 year without any issue. But companies trying to minimize lifespan just because of their own profit.
I agree with you, phone companies have developed a planned obsolesce model that is very frustrating. I actually just went through the same process in the opposite direction - I switched from having iPhones to Android. I've heard tales of iPhones staying capable and functional for many years but my experience was that after a year or two there'd be an update that drastically reduced the performance (or rendered it basically unusable which happened 3 times). I suppose the grass is greener on the other side but I'm pleased so far with my switch. Good luck.
In my experience with iPhones, this was true for older generations where they simply didn't have the processing power for newer OS features. My switch from my iPhone 4 to a 5 was strictly for performance reasons, but I went from my 5 to a 6S just to have something newer with mostly a better camera and touch-id. Performance-wise the phone was still perfectly usable (my brother still uses it). Sure it was a lot faster, and there still are massive leaps in performance with every generation, but these days that performance is mostly used to race to idle for improved battery life.
For the current applications, an iPhone 5S level of performance - a phone which is 4 years old - is still very usable today. That's also why Android flagship phones aren't really in trouble while still struggling to match the performance of a year-old iPhone 6S, and can't even dream of getting near the iPhone 7's performance. They mostly try to compete with stuff people do notice these days: the camera - where they have a lot more success.
For instance, if your kernel depends on Qualcomm snapdragon 800 support and Qualcomm no longer supports those closed bits for OpenGL and the rest, then even with cyanogenmod you'll never be fully patched. But cyanogenmod isn't the smoothest experience to be honest.
"..remember iPhone 5 is 5 year old phone, which will get new version of OS, not just security update"
Yes, and remember that Apple intentionally writes OS updates that will run slower on their older devices, thus achieving almost the same thing but slightly less blatantly.
It maybe the case that OS updates run slower on older devices but I think it's a pretty strong statement to claim that this is "intentional", at least in the sense that you seem to be implying.
Do you have some strong evidence of this? Amusingly it's actually being tested in court (see the class action referred to in the link below):
I can't think of any reasonable definition of "standard" that admits x86 but not ARM. They're equally closed, proprietary ISAs.
It's the IBM PC architecture, not x86, that is the de facto standard. It's reasonable to prefer that to the relatively recent, and poorly adopted, device tree stuff that you see in the embedded ARM world. But let's not ding the ARM CPUs themselves for that.
That's just the thing, there is no 'ARM CPU'. There is a ARM ISA, and some Core spec's, not a real 'ARM CPU'. Maybe a complete ARM SoC design you can buy, but nothing like an interchangable CPU, let alone socketed with multiple vendors.
If it's ARM-based, it's probably an embedded, closed, proprietary system with zero design need for 'compatibility'. With x86-based boards, you know there will at least be some sort of standard BIOS of EFI interface, a set of busses, a minimal number of devices that will behave and work the same on almost all systems. With ARM, there is no such thing, except for most parts of the ISA, and that's simply not enough.
It's a bit misleading: he's referring to the Cortex-M series of ARM microcontroller cores, which do not implement the core ARM instruction set but instead only implement the Thumb series of alternate instruction sets that are optimized for code density. There are older ARM cores that pre-date Thumb and only have the core ARM instruction set, but there would never be a situation where you'd want to take binaries compiled for one of those devices and run them on one of the microcontroller cores.
There are however, plenty of other variables across the ARM ecosystem that can cause real headaches, like the different versions of the VFP floating point co-processor.
Cortex-A, Cortex-M, Cortex-R have different targets, ISA, System organization as far back as their origination. Not sure why you'd compare them, I was obviously talking about processors within the same segment, Cortex-R7 is backwards compatible with previous versions, Cortex-A72 is backwards compatible with previous versions, Cortex-M3 is backwards compatible with previous versions.
x86 chips are themselves almost complete SoCs at this point [1]. That's why you can buy things like Compute Sticks, after all.
It's true that Intel is by far the largest supplier of x86 chips, and so you get some level of "standardization" with things like Intel HD Audio. But that's more the effect of a monopoly than anything else. Competition breeds fragmentation, but given the choice I'd rather have competition.
While true, it wasn't always that way. The IBM PC with the BIOS was basicaly one of the first layers you'd have to be compatible with, and up to UEFI systems with CSM for BIOS emulation, it's been supported for about 30 years.
There was a time where the chipset did a lot more than it does now. Right now, it's the PCH or whatever it's called, and you even have those SoC's where you don't even need that anymore. You used to have the possibility of a standard BIOS with a chipset from someone else (SiS for example) and audio from someone else, as well as PCI controllers, PICs, RTCs, HBAs, UARTs, and CPU's. Or have an Intel chipset with a non-Intel CPU, also possible. You could even make a complete x86 system with no Intel chip inside (pun intended). Right now, that's something you probably can only do with an AMD system and that's about it.
Your points are valid but this clusterfuck doesn't excuse Android: both Microsoft and Apple were able to deliver working ARM-based systems not subject to these issues: Microsoft by mandating UEFI, Apple by reasons unknown to me, but presumably helped by the fact that they're a vertical.
As a few people have noted, it's not "Intel x86/64" that's standard, they just happen to be a dominant player right now. The original architecture is the "IBM PC", and its clones that are "IBM PC-compatible", that all descend from the same BIOS lineage.
IBM became dismayed how other companies were profiting from its architecture, and released the incompatible PS/2 architecture instead [1], which fizzled, and its good parts -- like 3.5" floppies, VGA, and PS/2 connectors -- were adopted by the clones. In the 1990s, Intel and Microsoft rose to prominence and began to exert more control and dictate the direction of the architecture with specs like 'PC System Design Guide' [2], and they and other vendors produced several improvements (ACPI, USB, PCIe, AHCI, SATA, etc.) which were adopted by broad community consensus, pushing the architecture forward.
ARM is different, because they make their money licensing their cores, so historically they had no interest in cultivating a general-purpose, "vendor consensus" platform. And Android's owner, Google, just wanted to get its services like Google Search, Google Maps, Google Mail, Google Now into as many people's hands and pockets as they could -- and they succeeded, despite the platform's haphazard nature.
Samsung knows that Google and the handset manufacturers are allies of convenience. Samsung is hard at work trying to cook up an OS and ecosystem for its hardware that's not contingent on Google's continual involvement, even allying with Microsoft to bring .NET to Tizen after its previous attempts saw no developer uptake.
Meanwhile, Google knows that continued press coverage of Android's security situation is hurting the platform. It's trying to re-frame the partnership it has with hardware makers, to design more hardware in-house, and to lean on its partners only for contract manufacturing -- a shift from the Nexus days, incompletely executed with the first Pixel phone, but likely more to follow. This will enable Google to control more of the software on the phone.
>Your points are valid but this clusterfuck doesn't excuse Android: both Microsoft and Apple were able to deliver working ARM-based systems not subject to these issues.
Then how do you explain all of the Windows Phones, from Microsoft and their OEM partners, that were stuck on the previous versions of the OS that are receiving no updates whatsoever?
>Samsung is hard at work trying to cook up an OS and ecosystem for its hardware that's not contingent on Google's continual involvement, even allying with Microsoft to bring .NET to Tizen after its previous attempts saw no developer uptake.
Let's see, if Microsoft wasn't able to make .NET work on their phones what makes you think Samsung has a chance with a platform that has even less marketshare and mindshare? Samsung is just doing what Samsung always does. Incidentally, Google also joined the .NET foundation for what it's worth.
Windows 10 Mobile is not subject to these issues. Windows 10 Mobile has more restrictions on manufacturers than older versions, hence why they're "stuck behind".
Any OEM, for instance, that didn't give up control of software updates, couldn't get Windows 10. Even 8 had some more leeway, Dev Preview could install over the OEM build whether the OEM drivers were ready for it or not.
Those are the cases of devices never supported with Windows 10 in the first place. Dev Preview still worked (for a while), but it never officially got 10.
How has Windows Mobile solved this? Dev preview is available for all phones, updates are pushed immediately from Microsoft regardless of the manufacturer. Firmware with drivers are released separately from the OS. All on the same ARM architecture.
Getting Windows go boot on the completely fictuous qemu -M virt platform for both arm and arm64 was very easy, USB and SCSI worked after less than a week of fixing Qemu emulation bugs (GIC).
You're basically patching the hardware to work with immutable software (as you won't have the windows sources). At the same time, the QEMU ARM virtual system and the Microsoft designated ARM SoCs are perhaps closely compatible whereas it would be very different with other ARM implementations.
Only GIC (interrupt controller) bugs needed to be fixed. The GIC is standard since the Cortex A9.
On the A9, you have to use an HAL extension (declared in ACPI) for the timer(a sample is available on MS' Git repo). On the A7/A15 and later, Windows uses the GTDT ACPI table only, so nothing is needed :)
Windows on ARM uses UEFI and ACPI, it can even boot with zero drivers on Cortex A15-class(architectural timer) and later HW. Of course, you only have USB and eMMC in such a config, the driver model is also stable.
Late response: I'm having a hard time understanding your reasoning here.
A less generic comparison is Apple. Apple builds it's own devices and supports them.
If I buy an ASUS Tablet, I'm not expecting them to provide security updates to Lenova or Samsung Tablets. I am expecting them to support their own devices. They have everything they need - they built the devices themselves.
Similarly, if I buy an phone that's been purposely tweaked by AT&T, working with Samsung - I expect that they are more than able to provide security updates but are simply unwilling to do so. They have all the tools (drivers, access, etc) they need.
You're looking at the general Android landscape. It's a question of holding the device makers accountable. Providing security updates for devices you build yourself, with drivers you developed yourself (or through a partner) isn't an issue - it's pure (litigable) greed.
It's far worse than that. If it were simply a matter of running mfg's blob's, this would be an easy problem. Instead manufacturers fork the kernel, then patch the hell out of it (often in horrific-never-going-to-be-accepted-upstream ways).
I'm not familiar with any of the specific reasons why manufacturers fork the kernel. But an obvious question to be addressed is: Can the kernel be modified, so they can achieve their use cases without needing to fork it? By making it more modular in some parts, or adding hooks they can attach to...
It's quicker and easier than submitting any patches upstream. They don't care about support past product release.
Usually the SoC vendor provides the forked version, and the manufacturer forks that again, so they are twice removed from upstream. If they ever upgrade Android versions, they port all of their patches onto a new fork from the SoC vendor.
Because kernel developers can only work with what they're given. If the hardware isn't supplied by the company or some grant, or if it's IP encumbered, then you have a situation where it's unlikely to be supported natively by the kernel.
At that point, it becomes a short-term or long-term benefit assessment. Long-term, it's better to work to get it accepted upstream, but that's more work in that you have to make sure your patch is acceptable and conforms to how the kernel devs want it, and they can verify the support works, instead of just working as you've set up in-house. With the rush to market, and with the specific configuration of chips possibly not being used in the next item released, short-term patches likely look really attractive.
I don't think I'm explaining myself well. Can't the kernel be modified so that manufacturer-specific code can stay in-house?
Let me give you an example: I don't need to fork my text editor to make it highlight and autocomplete any new programming language I invent myself. And I don't need to give the editor developers anything to work with either. Because they've put the needed hooks and interfaces in place for me to write my stuff without having to modify theirs.
> I don't think I'm explaining myself well. Can't the kernel be modified so that manufacturer-specific code can stay in-house?
The kernel is under the GPLv2 so redistributing kernel binaries also requires making source available (that is all part of the "freedom").
The kernel internals constantly change. For example the USB stack was rewritten 4 times. Each time all the drivers etc were converted over. By contrast Microsoft has also rewritten their stack 4 times, but has to retain backwards compatibility for each generation of driver API/ABI, simultaneously!
While in theory it is possible to have a stable API, in practise real life is more complicated. There are concurrency issues, power management, suspend/resume, memory allocation, constantly changing hardware etc. A stable API would result in way less optimal drivers (eg they may consume more memory or power, cause cores to run at higher speeds).
The kernel developers decided they weren't going to have that layer of indirection. Instead drivers will do the one true correct thing (updated as kernel versions change). That makes them simpler, and perform better in the dimensions mentioned in the previous paragraph.
That all said, Linux is fanatical about the userspace API to the kernel being stable. You can implement drivers (eg USB) and filesystems (eg FUSE) amongst other things in userspace. However they won't be as "good" as kernel drivers.
To get an idea of what changes in the kernel, check out the LWN page. If you have interest in Linux, I'd recommend subscribing too. https://lwn.net/Kernel/
Thank you for the explanation and the link to that article. I disagree with some of the philosophical statements, like:
> While in theory it is possible to have a stable API, in practice real life is more complicated.
(In practice it's also possible, as Microsoft demonstrated with Windows for decades).
or (from the article):
> benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place
(The reality is, that wasn't enough of a reason to move users from Windows, before the smartphone era. Nor is it the reason Linux won over Windows in the smartphone market, either.)
I think the article hits the crux of the issue, though: Nobody wants to spend their free time contributing to maintain an old interface, instead of working on the new one. A side effect of this policy is a better kernel, granted (for the devices that actually make it to the main tree).
So given that a stable API isn't an option, and the current model is clearly not working, I guess the solution lies in solving the hurdles these companies face to upstream their code. Do you know about that, or where could I learn more?
Microsoft only had to support one architecture, and continuously changed driver models. Except 32 and 64 bit. Plus you can't use drivers across Windows versions that much. But at the end of the day it was a financial decision by them to maintain a very large degree of backwards compatibility, and by their customers to pay that price. But also remember just how "sticky" Windows 98, XP etc were. People wouldn't give them up. Also have you tried to use USB 3 on Windows 7? Or how about skylake until the backpedal?
Note that with Linux you can get more a semblance of Microsoft style stability. Use RHEL (redhat enterprise linux) and they do the work of backporting relevant drivers and changes. You also get to pay handsomely for that.
Note that the majority of devices do make it to the kernel. You can plug in virtually anything and it works!
You really should read LWN. They do a fantastic job of covering various issues. For example here is an article on hurdles: https://lwn.net/Articles/647524/
> Note that with Linux you can get more a semblance of Microsoft style stability. Use RHEL (redhat enterprise linux) and they do the work of backporting relevant drivers and changes. You also get to pay handsomely for that.
> Note that the majority of devices do make it to the kernel. You can plug in virtually anything and it works!
it looks like you're mostly thinking of the server space. The problem of manufacturers forking the kernel, and the topic of this HN post in general, is on Android. E.g. my last two phones, a Samsung Galaxy Nexus, and an LG Nexus 5, won't get any more OS updates.
I'm going to read that article, and check LWN regularly.
No, the majority of devices do really work. Plug in a random webcam, drive controller, spi peripheral etc.
Embedded systems are different, but it isn't the device driver support that is the problem. x86 has a mostly standardised architecture, and due to an accident of history has a I/O address space that is separate from memory address space. Consequently it has been possible to probe for devices with very low probability of collateral damage. Which is why Linux and Windows can "just work" on virtually any x86 system.
In the ARM world, you get the CPU design itself from ARM and copy/paste that into your design program. Then you copy/paste in other pieces you want such as memory controllers, USB controllers, serial ports, displays, storage, SPI, and whatever else fits your needs. Then you hit print and get chips with all that working together. There is no separate I/O address space, so these devices all end up in memory address space. There is no standard location for them. Somehow you have to know the USB controller is at address 0x12345678, and you can't practically scan the address space trying to find all possible devices, and certainly not without collateral damage.
So what would happen is system developers would fork the current kernel, and make a permutation of an existing system but with hardcoded knowledge of where all the pieces making up the system live in the address space, and how they are connected. Then they'd add support for unique devices, connections, quirks and bugs. Throw in some binary blobs, NDAs, "IP" etc and they now have their own unique kernel. And that is why they get stuck on a kernel version that can't be practically updated.
The kernel developers adopted device trees as a solution. This is provides a data description to the kernel at boot time of what platform devices are present, how they are connected and where to find them. That allows the same kernel binary to support a very wide range of hardware. ARM64 systems also typically require ACPI, which if you squint allows the platform to also provide code that can run for dealing with the platform.
What this means is that the problem has been addressed technically. It does not address financial issues: the vendors get no more money after first sale, so they don't care about updates. It also does not address the folks doing binary blobs, NDAs and other "IP" concerns. The Linux (GPL) attitude is all about user freedom (as in freedom of speech), and gives everyone participating an equal playing field (no party has a special position).
You are welcome. It is actually something that has been very painful for me and the project I've been working on. The newest kernel we had for ARM boards we were considering was 3 years old, and hence missing a lot of newer device drivers and other functionality, not to mention missing bug & security fixes.
The 802.11AC card in that router will likely never have open source drivers. I'm pretty sure the routing engine is closed source too, although with 2x Cortex A9 chips I would have thought you could get away with doing it in software.
> (In practice it's also possible, as Microsoft demonstrated with Windows for decades).
There may be a handful of narrow cases where Microsoft has preserved third-party driver compatibility across long spans of time, but when looking across a decade or more, they break as much as they preserve. Consider DirectX, which is now completely antithetical to its original purpose and name of allowing applications (games) relatively direct hardware access. Modern systems can't survive without a level of hardware abstraction and sharing that mid-90s systems couldn't afford. The end result is that you get essentially no hardware accelerated graphics on decade-old GPUs anymore, except where the drivers were re-written for recent versions of Windows. Vista's new audio subsystem killed off an entire product segment of hardware-accelerated audio processing.
Oh, I meant the demonstration has lasted decades, not necessarily that the backwards-compatibility was eternal. Once you take the stance of preserving compatibility, there's a strong market force to deprecate and eliminate old interfaces and guarantees once it's practical. On both the PC market of then, and the smartphone market of today, hardware gets replaced faster than once per decade.
The shit disasters vendors force into their forks would never be accepted mainline, and even if they would be, these vendors take the route of most control - working with anyone else would violate their own ego that they always know best, so they never work with anyone else.
I can't speak definitively for any specific project, but I gather much of this is due situations like this:
SoC Mfg designs a new chip, heavily leveraging IP from an old chip. Since some old IP is still around, and already (mostly) has kernel support SoC Mfg, patches the existing code to work on the new SoC, publishes the bin/source as an SDK, and declares their work done. (The linux-meson/sunxi geeks will eventually clean this up and mainline it anyway).
In the mean time, Board Mfg needs to get a product out the door, so they start with the SoC and SDK, and find that a bunch of the work done in the SDK is really specific to SoC Mfg's reference board, and requires a few tweaks, so they hack on the SoC Mfg kernel tree until the device mostly works, declare a success and publish a board SDK. (Those same geeks from above will handle the mainline work if they want to run a mainline kernel anyway, so why should Board Mfg bother?)
In some cases, this cycle gets to repeat yet again when the board gets OEM'd into a half dozen devices, each requiring slightly different kernel tweaks.
I think with microkernel architecture this could have been very different. Even touching the kernel would keep outdated only a tiny part of the system with a relatively small attack surface, the rest could still get updates.
It would have, but in 1991 it would have taken some powerful crystal balls to architect towards a fragmented mobile hardware ecosystem unified by a JVM-run app platform.
Microkernels wouldn't really help. The point of a microkernel is to drastically reduce the coupling between parts of a system. Current hardware has far more coupling between parts. For example power management requires coupling (consider a NIC on a USB controller on a PCIe bus) where all pieces need to pull together. Or consider something like scheduling in a world where processor cores aren't identical and what runs where matters.
Your microkernel would either perform way worse (eg worse power consumption), or have pieces so tightly coupled that you'll wonder if it was worth it.
Well, they will still have to import all the upstream changes, and make sure that all the parts play well with each other, which, they can still do. Except that they don't.
I think what makes it hard is the dizzying variety of CPUs that makes it all hard to keep up with. I have heard from insiders that as far as manufacturers are concerned, a CPU stays "current" for about 6 months.
They don't usually "Fork" much of kernel, they (mostly) just have drivers(modules) outside it. When refactors happen to kernel internals, they don't happen to external modules so it is hard to get them up to date with the latest version. Over time this gets worse and worse.
That said there are often some small changes to the kernel itself, which are also an issue. This is more common if the hardware implements something new that hasn't really been standardized in the kernel yet.
Of course the kernel community looked at the "Too hard" and "afraid of upstream" responses and called the programmers lying lazy jerks, which I guess proves the point.
> If Intel had been like this, Linux would have died off in the 90s, for both servers and desktops.
That's the thing. You said "Intel". Intel is not an architecture. It's a company - that happens to dominate the x86 market. Do you think the situation would be the same if there were 10 different x86 chip companies with at least 5% market share each? If we wanted everything to just work, as it does on "Intel", then we should probably wish for a Qualcomm monopoly with 90% of the market. And hope it's profitable enough that they can support their own chips for more than 18 months.
I can only describe Intel's chips as a rip-off for the most part (and it's only gotten worse in recent years). I mean, they're now selling Atom chips for $160 (about 4-5x more than a similar performance ARM chip) to notebook manufacturers, with very little difference in performance between them and the older Atom for smartphones. So I would certainly hope Intel's chips would be better supported. Although I actually don't think its Atom chips are as well supported as its Core chips.
Now, not having a single company completely dominate the ARM ecosystem is certainly a "problem" from this point of view. However, I still mostly blame Google, who mainly just wants its ads to run well on these devices, which seem to do that rather well in the current situation, as well as OEMs who want to be "different" and are probably even hostile to the idea of allowing say an LG ROM run on a Samsung phone. I would try to fix this Google/OEM situation first and aim my complaints at them.
Tracing the history of those various competitors is really interesting. Some (Transmeta) failed completely in a relatively straightforward manner and just disappeared. At the opposite end of the spectrum, NexGen became AMD's future when AMD's in-house design was a flop. Parts of Cyrix ended up with VIA and parts with AMD. Almost all of the big semiconductor companies either owned one of these x86 design firms for a time, or sold those chips under license.
VIA, thanks to Centaur, was first with the low power plus had PadLock Engine with TRNG and crypto acceleration. Their ARTIGO's made nice little boxes for $300.
The IT industry's lack of attention to security (including confidentiality and system integrity) has enabled mass surveillance, by both businesses and government, and that problem now combines with the political situation to create a serious risk to people's rights.
Google has a very serious responsibility to implement effective security for Android, and it needs to be done urgently. They've known about it for years and put it off. The EFF has some basic specs here:
When I worked in the mobile industry (modems), blatant security holes to monitor all sorts of things was a requirement from the biggest operators (like AT&T).
So, as others have mentioned, the ARM chips out there don't really follow any common set of standards.
Some IP blocks, like USB controllers, can operate using a standard driver, but that's about it. Even for the bits that are migrating from PC land like PCIe and SATA, they aren't uniformly available or have standard driver interfaces across vendors.
And it gets worse. There's not even a standard means of discovering what all of the hardware is on the ARM System-on-Chip (SoC). You've just got to learn that this GPIO register is at this physical memory address from the reference manual.
And it gets even worse. There's no standard for hooking up the hardware peripherals either. You could have two phones with the same (for example Qualcomm Snapdragon 820 SoC) but they might have chosen to connect up different sets of peripherals, to different sets of ports. There might be three display output ports, which one did vendor X use?
And don't even get me started about power management. ARM Ltd doesn't do this, so every chip vendor has their own. Which is completely different. There is nothing close to what is available in laptop land.
What we need is a widely accepted standard for describing the on-chip peripherals, which can be read by the software. And we need a separate description for how the hardware is connected. And even all that isn't nearly enough.
This situation will not get better any time soon, IMHO.
All my disdain for Google aside, I wouldn't as well, in a sense you are implying. I develop a product, I care about its quality, I allow you to use its code on your devices. Should I care how badly will you fuck up your own proprietary version of the product I granted you to use? Not the slightest, IMO.
> Should I care how badly will you fuck up your own proprietary version of the product I granted you to use?
YES, because your name is on it. If it's white boxed and no normal consumer knows you are responsible (like the Android underpinnings of the Fire tablets) then they're OK.
But Android phones are seen as Google's phones and are known to run Google's OK. So when they suck, it reflects poorly on Google. Always crashing? Battery doesn't last? Got malware? Confusing to use? Never gets updated? "Android is like that".
So techies come out and say "Well only the Nexus line is real Android" and that's cute. It may be technically true. But it doesn't matter to a normal consumer. If your name is on it (and all the prompts to use Google software and log into Google don't help this) then you're going to be associated with it.
Let's say there are two restaurant chains. You have Taco Bell and Mex Express Featuring Taco Bell. They're both advertised the same way, and MEFTB makes it clear that Taco Bell is involved in the creation of their recipes.
Now as an ultra-informed consumer you may know that MEFTB simply buys their ingredients from TB and has additional original menu items as well.
When someone gets food poising from an original item at MEFTB do you think normal consumers are going to bother to understand that? Or because all the ads are intermingled do you think they'll assume that Taco Bell is having issues too and avoid them?
This is a fundamental problem with Android that a lot of fans seem to want to sweep under the rug. If your name is on it then it effects YOUR reputation. Doesn't matter if it's customized. Doesn't matter if it's not your fault.
Little Billy got an Android tablet (that's how it was advertised)... it was a piece of junk... Android tablets are junk. That's the lesson a LOT of consumers would learn.
In the case of phones the horrible low-end Android phones don't do that much damage because there are highly successful examples of good Android phones, such as the Galaxy series.
But if 95% of Android phones, including flagships, have serious security problems then saying 'But not Nexus' isn't going to do much for you.
>I develop a product, I care about its quality, I allow you to use its code on your devices
I don't have problems with Google if companies use their AOSP in horrible ways. I have problems with Google when they don't put a clause into their T&C for Google Play that the phone has to have some standards.
This is a false abstraction. Android is designed to be used as a component in proprietary products and Google requires that those products carry its brand. Google is intentionally taking credit for the products it brands, and therefore must also take responsibility for their shortcomings.
The problem with this mentality is the idea that people using phones with their Google accounts with apps bought from the Google Play Store with email via (Google)mail which reports their location and other sensitive data to Google are not Google's customers and that Google has no responsibility to them.
This is the Microsoft problem, right? People bought tons of computers with Windows and they were loaded to hell with crapware.
It wasn't MS's fault any more than it was Intel's. They just sold a component to the company (Dell, HP, NoNameBrand, whatever) that put all the crud on the computer.
But it was a WINDOWS computer so people blamed Microsoft and said "Why can't you fix this"?
They're trying, but because their product was so central to what was being purchased, as well as so obvious and in your face, that people associated them and they got blame they didn't deserve.
I don't think that's germane to the point I was making. How easy it is to reinstall Windows doesn't really factor in to how 3rd parties are able to change your reputation for you.
You're letting MS of the hook too lightly, in my opinion.
If Windows was -> OEM license: Regular licenses :: CVS : Costco (All OEM does is give bulk discounts), you'd be right.
If most OEMs weren't abusing their position by packaging cruft with Windows, you'd be right.
But when a company imposes T&C, often specifying exactly what apps/programs goes where, and doesn't insist on removing cruft, their silence is deafening.
-----
By the way, I'd blame MS the same way when OEMs sell underperfoming computers with Windows (um um, Vista). It's true that Vista on a behemoth machine for its day was quite usable, but there's no excuse, when you're already dictating resellers policies, for letting them put windows on a 512MB of RAM machine.
I'll admit it's the OEM's fault also, but Microsoft gets part of the blaim
I wasn't trying to blame MS, only referencing that this kind of situation had already happened in the computer industry.
I think they knew what they were doing. They didn't clamp down because that would have kept prices higher and hurt sales, just like your example of dictating a minimum amount of RAM that's too low to be actually usable. They could have gone higher but must have figured the extra $$$ would be better than the $ lost due to reputation issues.
Indeed. Google uses their (probably illegal[0]) contract to mandate that Google+ must be preinstalled on your phone, but not that your phone must get security updates for a reasonable period of time.
>What they forget is that to put Android on a phone, practically you need Google's permission.
I think you're forgetting the hundreds of millions of users that use Android without any Google services.
>If Google cared, they could have made it part of the terms and conditions that it has to have security updates for five years.
Wouldn't it be nice if it was as simple as that? You seem to think Google has the ability to do whatever they want and have the OEM's fall in line one by one.
>They obviously don't
In that case they should probably stop investing millions into improving Android security every year and stop releasing security updates each month.
>I think you're forgetting the hundreds of millions of users that use Android without any Google services.
If only the problem was with those phones. Anything in the US except for Amazon is under Google's thumb
>Wouldn't it be nice if it was as simple as that? You seem to think Google has the ability to do whatever they want and have the OEM's fall in line one by one.
They put their foot down about other things, like branding, app choices. This should be more important.
You don't want to port Android 7 to a three year old phone, fine. But to refuse to patch against stagefright?
>If only the problem was with those phones. Anything in the US except for Amazon is under Google's thumb
So you've now qualified it to only phones in the US and devices not from Amazon?
>They put their foot down about other things, like branding, app choices. This should be more important.
It's a balancing act to keep everyone happy. When it comes to things like creating patches and paying for carrier certification these all cost money and shave off even more margin. Support the OEM's that provide timely OS updates and patches and disregard the rest.
My 1st gen Moto G stopped receiving updates a while ago, but Cyanogenmod is still putting out new ROMs. It takes some level of understanding to put Cyanogenmod on a device, but nothing too challenging for the HN crowd.
If your phone has stopped receiving updates and you're not ready to buy a replacement yet, you can check if it's supported. It's a great thing that this project exists.
I was considering buying a new phone but I installed CM on my 2nd gen Moto E and that solved most of performance issues (so far, remains to be seen if it holds up.)
CyanogenMod has less bloat, and more actually useful core functionality, which means I need fewer apps. (For example, no need for something like Twilight since it has adaptive brightness/hue built-in.)
CyanogenMod is fantastic, but even then, the devs have to work with what they've got. Support for Exynos SOCs has traditionally been sketchy because Samsung plays games with xda devs and is slow to push kernel patches. And even with snapdragon SOCs I've had stuff happen like LTE and wifi 802.11n stop working after flashing with CyanogenMod.
CyanogenMod is a very high-quality android distro, but sometimes they're really stuck doing the near-impossible.
Their stock configuration doesn't even have root available unless you enable it in the hidden developer settings menu. Even then it works like SuperSU and such, non-root by default and popups to prompt for root access when an app requests it.
Mine certainly doesn't. I use an official CM build for my phone and I still had to root it if I wanted that (which I did). Then, barring exploits of which I'm sure there are many, I have to approve each app that wants root access. No "default root".
This article also linked to a post about Android disk encryption [0] that I found pretty interesting.
It goes through Apple vs Android encryption implementations, and talks about per-file vs full-disk. Android has only just now implemented per-file, but haven't made it granular enough to handle some very valid use cases and thus it has some pretty big holes. The worst part is fixing it means breaking 3rd party apps.
Pretty interesting that it only got 183 votes. Usually when people talk about Apple's security holes, it generates much more discussion (criticism) and votes.
Google decided to take on IOS by loosening the quality controls that help make the ecosystem secure. Google could easily require code signing and auditing for all non-google OS components, but it chooses not to because doing so would hinder phone sales.
The vulnerability in BLU phones was due to third party code packaged in the Android build for BLU phones. This was discovered because it sent texts back to china. Imagine if a slightly more sophisticated attack were included, how easy would it be to spot?
I'd estimate that there may be over 20 stuxnet level malwares lurking in the Android ecosystem, leveraging it to spread opportunistically deeper into infrastructure and onto higher value targets, etc.
And this doesn't even consider hardware level malware which could be included in bulk via alternative ASIC designs that end up on millions of phones.
I brought this up in r/ProjectFi (a google/android subreddit) and was wholly ridiculed and dismissed "for not knowing anything". It seems brand loyalty has become similar to American politics with little-to-no middle ground or room for unbiased opinion.
I'm glad to see a realistic approach to mobile security. We need more scrutiny in this area.
ProjectFi only works with Nexus (and Pixel) devices, which aren't impacted by this.
So posting complaints about manufacturers which aren't Fi compatible on the Fi subreddit seems unusual and may have resulted in some of the negative feedback you received.
That may not be true. Fi works with (and was marketed with) the Nexus 6 which is EOL as of this month (Oct 2016). That means the OS version will be halted at Android 7, as I understand it. They may still receive security updates, but I don't believe Google has said how long they'll be doing that for.
It will get no more version upgrades, but it still has at least a year of security updates (depending on when it went out of the play store). I'm not saying new versions wouldn't be nice but personally that seems like a minor advantage.
That's not the only place I've experienced mass bias about android vs. mac. Also, to say that I'm extrapolating to the whole population is assuming. I was simply pointing out the state of small communities I've been exposed to.
polarized is a good way to describe it. because a lot of the time, when you criticize a particular component, people assume your automatically promoting the alternative as opposed to having a discussion/wanting to improve the qaulity of the thing you are talking about.
Apple does have an iPhone in the traditional Nexus pricing zone. For $400 you get the iPhone SE - https://www.apple.com/iphone-se/ - which could be acceptable.
Nothing brand new however there is a huge second hand market for iPhones. Looks like you can get an iPhone 6 for around $250-$350 which is a pretty good deal in my opinion.
> Apple is still shipping security updates, albeit on iOS 9, for the iPhone 4s which was released in 2011 (5 years ago). The iPhone 5 is still being kept up to date with iOS 10.
Apple has a very good track record here. Based on past experience, it's likely that the iPhone SE will continue to receive security updates well past 2020.
This is exactly why I switched. My Nexus 5 which worked perfectly for a couple of years, suddenly crashed. And I looked up the new Nexus/Pixel phone and decided it was much better to switch to iPhone SE for a smallish phone which would be cheap, dependable, reliable and supported for a longer time.
My Nexus 5 glass broke last week, I am in exact position as you, after looking at market I thought there is no way I am buying another phone from Google(let alone other manufacturers).
Now I am happily switching to iPhone SE which I am 100% sure will get supported more than pixel phones.
Meanwhile, Windows 7 is supported until 2020, and was released in 2009, and could run on hardware up to about ~7 years old at the time.
That means an effective support period of about 18 years.
The entire cellphone ecosystem is toxic because of how it treats hardware as disposable in an effort to coerce money from users. I find that phones of the Galaxy S3 / Moto G first gen era are sufficient for 80% of use cases, but since the software stops working and depends on Cyanogenmod for long term usability it is a PITA and lets the hardware manufacturers off the hook for gross mistreatment of users.
The SE is based on the 6S (released a year ago). I'll bet the SE is supported for far longer than the just released Pixel!
It is also worth taking a step back and noting that Apple supports its hardware for a long time. This is done because it supports user experience - the software/apps, cloud services, media etc (aka "ecosystem"). While Apple has nice hardware margins, the ecosystem is what helps keep people loyal, keeps developers on it, and makes Apple a fair bit of revenue too. Life is simpler for all the more up to date all the devices are.
My daughter just got a hand me down 5 from a relative a few months ago, before that she was using my old 3GS. It wouldn't get OS updates of course, but it still worked perfectly with the App Store. She installed Whatsapp and I found I could even still download software I bought many years ago that doesn't even appear in the App Store anymore. Not bad for a 7 year old phone.
It got OS updates for 5 years. It's been out of support for only 2 years. How many Android phones sold 2 years ago are still getting updates? How many sold today will get any updates whatsoever?
> Apple does have an iPhone in the traditional Nexus pricing zone. For $400 you get the iPhone SE - https://www.apple.com/iphone-se/ - which could be acceptable.
My 2c: After 3+ years of android (moto g w/ cyanogenmod, then project fi), I finally made the switch back to iOS. I'm beyond happy so far, and have the benefit of google not tracking my every step and key press. It is good when the manufacturer of a product you pay for has interests in line with your own.
You moved from a sub $200 entry-level phone to something that is (in my country at least) 4X the price and impressed by the experience?
Not exactly a fair comparison.
4X the price, but can still be hugely subsidized through a phone contract or simply buying used. Getting any hardware widespread and into the hands of consumers is an artform in itself.
>subsidized through a phone contract or simply buying used
Those aren't solutions because the 'subsidization' is just a payment plan with interest, and the used costs are reflective market prices. It is exactly why whenever I go to Europe I typically bring old devices to sell.
The problem is how can users obtain better devices which will in turn provide a higher quality experience. It's absolutely a solution. Providing an incentive and/or partnership with telecom carriers and allowing the hardware (and perhaps supporting the software) to have lasting resale value is a solution. It doesn't have to be a comparison from what immediately hurts the wallet more... Providing users with an entry barrier to obtain the hardware at (or almost) zero immediate cost is exactly why these contracts exist.
I am happy for you, but please stop spreading FUD about Google/Android. I would like you to point out a single practical example of tracking in Android that you can't opt out of.
It's not the opt in/out, it's the Intention that matters. It is known that a company built on advertising will want as much data to profile and target you as possible. If you can disable all/most of the telemetry that's nice, but doesn't change the intent of the vendor, nor does it change the way you are perceived as a customer/data source.
This is the same for most vendors; with Apple, they want to make you a happy customer with the hopes that you'll buy whatever they release next, with Microsoft it's more like an ecosystem idea where they'd like you to connect as many services, software suites and devices with their software as possible, connecting home, work, private, and entertainment. It doesn't need to be the best in quality, but definitely in quantity. With Google, they want as much data about you, and as much exposure to ads as possible, with a free opt-out for data gathering, and a paid opt-out for ad serving (i.e. paid apps vs. free apps as other vendors put them in their play store).
Nothing new here, but it's not FUD about Google/Android, it's just the way they work, and there's nothing wrong with that.
The problem isn't that you can't opt out of it. The problem is that Google cripples your phone if you opt out of it. Because Google's software is not designed to function properly without tracking. (For instance, your local Google Maps install won't even remember where you live or your last location search if you turn search history off in the cloud.) Not having basic local-only functionality is silly, unless you're specifically trying to push people to stay in your tracking system.
Yes. Apple emphasizes data processing on the device itself to enhance privacy.
Additionally the tracking that does take place is generally less invasive, since Apple cares a great deal less about correlating your buying habits with your life history to sell you ads.
If you "opt out" it cripples locations for third party apps. If you opt in Google tracks your location.
Google Accounts.
If you don't put a Google Account on your Android phone it cripples, well, everything. But if you do put a Google Account on it then Google tracks the IP address when it connects to the internet as well as sync times/login times/etc.
Yes, this. Location services. Good luck keeping that off if you use any maps for navigation. Google accounts... Good luck using Android apps securely without the Play store.
I tried rather hard but was ultimately unsuccessful in using Android in any convenient way and not allow Google to track everything I do. If you have any suggestions I am still all ears!
> You realize that you traded Google no longer tracking your every step and key press with Apple tracking your every step and key press, right?
Apple exerts substantial effort to NOT relay unnecessary information to their servers; spend some time in Wireshark and you will see.
> And because iOS is closed source, you know even less about what is being tracked than you did with Android.
Don't get me wrong, AOSP is open source and that's great, but Google Play Services (which you need to use to use the Play store) and friends are completely closed-source. The iOS kernel is open source; it's a pretty similar situation either way. This is not a good argument IMHO.
Do you seriously think Wireshark tells you anything about what is being sent to servers? All it tells you is what hosts are being contacted, but for anything else, you're completely in the dark.
> This is not a good argument IMHO.
I totally agree, so why did you make the argument that you felt that Apple respects your privacy more than Google does?
All you have to do is look at their business models.
Google exists because of your data. Without it they don't sell ads.
Apple exists because it sells devices. Consumer trust is critical. If it turns out Apple is lying about differential privacy, on-device data processing, etc, then that trust would be broken.
Were Apple lying about your privacy, that information would leak out. It always does.
But go ahead and keep the tinfoil hat firmly in place because you'd rather hate Apple than go with the more secure, more private offering.
Hate Apple? Where did you see I hate Apple? I understand it's comfortable for you to think that since it allows you to continue believing incorrect things about how these companies operate.
The discussion is about disputing the claim that Apple cares about your privacy while Google doesn't.
I'm just demonstrating this argument is not just nonsense, there is simply no way to know what either of these companies do with your information and saying that you don't trust Google with your data and therefore, you pick Apple demonstrates a fundamental ignorance of how both companies work.
I'm still using my over two years old OnePlus One with the Cyanogen that came pre-installed and I've been installing all the ota updates, being in security patch September now and QuadRooter showed no vulnerabilities. Pretty near for such a cheap phone.
What stops me from using iPhone is my opus music collection I want to carry with me, Rocket player and my pure hate towards iTunes.
I was looking to switch to Android, but even after briefly reading up on security/privacy on Android, I came to the same conclusion. It's too bad iPhones are pricey and/or despised among a subset of customers. I'm sure more users would vote with their wallets if they were aware of this.
Many very popular Android phones cost as much as iPhones do (which includes models like S7, Note 6/7, etc. ). This implication that people buy Android because they can't afford iPhones is a bit arrogant don't you think?
I can't imagine what's arrogant about it. It's hardly the only reason someone might choose an Android device, but it definitely influences many consumers, and thus the market as a whole.
If someone wants to spend $100 on an unlocked phone, it's not going to be an iPhone. There are entire market segments in some parts of the world that Android basically has 100% market share in, because the cheapest iPhone is still too expensive for mainstream consumers in that market. It's not as much of a factor in the US, but it's still a factor. It's a huge factor in some other parts of the world.
Only if you want to spin it that way. You can also afford an iPhone and choose not to buy one because of the price (e.g. because you can get the same raw specs cheaper).
But yes, there are people that can't afford an iPhone and I don't see anything arrogant about saying this. I want devices with good privacy and security affordable for anyone.
> Many very popular Android phones cost as much as iPhones do (which includes models like S7, Note 6/7, etc. ).
In theory, they cost as much as iPhones, in practice if you wait a few months and shop around, they're quite cheaper: my GS7 (bought last month) cost me 460€ (with an ODR and a 'reprise').
I'd consider switching to an iPhone, but lots of my music is just MP3 files and I'd hate to lose the ability to play them on my phone. Using iTunes is not an option.
Yeah iTunes makes transfering libraries or switching PCs unnecessarily tedious. I've had a lot of problems with it. I also think Apple's product decisions (hard- and software-wise) are becoming more dubious, which is why I was looking to switch. Privacy and security still outweigh it by a wide margin which is why I won't switch for now.
As for the MP3 problem: There are 3rd party apps, where you can simply drag the files into the iTunes window and they'll sync without hassling much with iTunes.
Couldn't you just dump your files in VLC for iOS and play them that way? There are probably more tailored music apps where you could put your local music collection too.
That's possible, but VLC doesn't have a good UI for browsing your music library. Grove Music was good at this, but it was bought by Microsoft and imho has since regressed.
There are several 3rd party options for playing audio files on iPhone without iTunes. The two I use most often are Plex and CloudBeats. Recently, I have been giving Bound a try for audiobooks instead of CloudBeats. I really want Plex to support some basic Audiobook features so I can use just the one app. The audio I listen to is stored either on my home server (Plex) or a cloud service of my choice (CloudBeats and Bound). I don't touch iTunes.
Disclaimer: I rarely listen to music. I'd wager 85-90% of my aduio listening is podcasts and I do that with Overcast. This may lead me to have the false belief that not using iTunes for music is easy/not a hassle on the iPhone.
Actually Xiaomi (a Chinese vendor) has one of the best update models I have seen. They update MIUI weekly, every Thursday a new update with small changes/security fixes. If only more companies would adopt such a model we'd have a different situation.
Small problem with this model, if you want your devices to be Google certified. Google requires that every official software needs to be certified with Google (CTS and GTS verification need to be passed at a Google certified lab).
This might not be a big problem once you are rolling after your first certification, but it does create some overhead every time you need to release a software.
Well, if you are not certified, you are not allowed to pre install the whole suite of Google binaries and Google Market along with Google Pay and probably other services are not going to work on your device (at least you wont be able to make purchases).
I think this article is spot on. We should vote with our feet. Since Samsung do not wish to keep my phone secure, and so far they are averaging one update per year, my next phone is likely to be a pixel.
"Vendors (LG, Samsung, Xiaomi, etc.), after selling you their phone, have no incentive to keep your phone’s software up to date with Google’s fixes" - that means that they have no concept of long-term (long term = more than a month) customer satisfaction. If that is the case (and that very well might be), the future is very bright for Apple.
However, people will endure much pain and problems to save a few dollars. Reminds me a bit of the "inexpensive footwear" Dilbert cartoon: http://dilbert.com/strip/2007-05-01
Can anyone comment on the Blackberry Priv? The article mentioned it, and I know their security goes down to hardware level and what they claim is a secure manufacturing process, but all I know is what they claim ...
I purchased one used, mostly to see what it is like but also to have as a backup phone Just In Case. The hardware is a mixed bag: the screen is gorgeous, the keyboard is a bit narrow but allows for very accurate typing, the back of the case is flimsy, and the CPU is underwhelming. The software is great though! You get a very up to date (second only to Google brand phones w.r.t. security updates) OS and the Blackberry software (like Hub) is an actual improvement over the stock Android experience.
Basically, if you want a secure Android phone and wouldn't mind trading older hardware for a physical keyboard, it is the phone for you. Otherwise, you might want to look at a Pixel device.
As to security at the hardware level, I'm not aware of the PRIV featuring anything special outside of the TrustZone TEE stuff that most recent Android phones have.
I found some notes from when I was looking into the Priv at the end of last year. They lack detail, but maybe are a good starting point for someone.
* Root of trust: unique crypto keys at the hardware level: Somehow implemented in way that guarantees Blackberry through supply chain, they claim. Maybe Blackerry supplies own chipset, w/ key included?
* Verified Boot and Secure Bootchain: Verifies integrity of all layers, from hardware to software. Uses hashes, crypto signatures
* hardened Linux kernel with numerous patches and configuration changes to improve security
* FIPS 140-2 compliant full disk encryption for data and applications
* Monthly updates through the Google Play store (only?)
* DTEK: "a single dashboard to monitor and control application access to your microphone, camera, location and personal information."
* Can customize each app's privacy settings, like in Android 6
It's hard to tell. There's indications it's meant to work on any form factor, but at least initially their focus seemed to be on desktop-esque hardware like the Intel NUC, an Acer slate tablet that runs x64, etc. and then with the Raspberry Pi for ARM support. There hasn't yet been a clear indication that they're working on phone support for it, or when that would be.
It's still super early for Fuchsia though, so it's anyone's guess.
I agree, it's still early and there's not much info at the moment. Still, in the maxwell repo, there's mentions of "GPS acquirers" and in the SysUI repo, there's icons for battery, airplane mode, screen rotation and cellular signal.
Nothing really specific for phones since these things can be found in some tablets and laptops, but apps in Fuchsia are made with Flutter, so it's interesting since it was made to make cross-platform mobile dev easier on Android/iOS.
I'm in the market for a new android these days. Looking at the too tightly with Google coupled Pixel, the Samsungs S6/S7 (Samsung led me down without updates once), the Fairfone 2 (thick and ugly) and others.
Let's jump back to the late 90s. You want to try Linux. You might partition your disk, or build a different machine and get a KVM or use an old laptop or add a second hard drive. In all cases, you can just install a Linux distro and see if it works. Maybe Ethernet or sound or something doesn't work. You could try a different distro with a newer kernel, maybe compile your own kernel with the modules you need, etc. But no matter what, it would at least boot (usually).
Intel x86/64 is a standard architecture. EFI makes the booting process even easier (although some motherboards still fuck this up; but for the most part fiddling with efibootmgr and turning off TPM will work. If not you can always turn on legacy BIOS and use the MBR). ARM is not a standard architecture. It's a spec that is sold to companies who all make their own SoC templates. There are things like Device Tree Config that make some of this more standard, but it's still far from x86/64. Just read Torvalds rants on ARM to learn more.
Even if you make some standard Android builds with all the drivers for all phones in a massive 20MB initrd, a lot of kernels are fundamentally different with the way bus connections are defined. Manufactures take forever to release their kernel code, often under threats by people for GPL violations, and even then they are filled with tons of binary blobs and shims that connect their .o files so kernel calls.
Stuff like Plasma looks amazing. It only has like two phones it supports. If you look at any android rom project, you see totally different builds for every single device. If Intel had been like this, Linux would have died off in the 90s, for both servers and desktops.
Device manufactures depend on you buying new phones. They cannot support phones after two years or else it kills their profit margins. Planned obsolescence like this leads to waste (don't kid yourself, e-waste recycling gets shipping to Africa where kids remove components. A small percentage of phones actually get recycled).
TL;DR Mobile phones are based on unmaintainable and non-standard hardware (intentionally). I wrote a post on this a while back:
http://penguindreams.org/blog/android-fragmentation/