If we were to ask for any new feature from a new Android version, it would be some kind of scalable update solution. Right now a custom update still needs to be built for every single individual device model, and that’s really not a workable solution when you have more than 24,000 models out there. The Stagefright vulnerability seemed to be a wakeup call for the Android ecosystem, but it came too late to affect anything in Marshmallow. Google instituted monthly updates for Nexus devices, and OEMs are pledging to bring the monthly update program to flagship devices. The majority of Android devices, though – the low-end devices – are being ignored. Monthly updates for Google, Samsung, and LG flagships only works out to a very small percentage of the Android install base.
Android 6.0 could dispense gold nuggets and clean my bathroom for free, but as long as this update hell exists, it’s all for naught.
Google is the only mobile OS vendor which doesn’t control its hardware (except for Nexus devices which are few and far between in comparison to the overall number of Android devices being sold).
Apple and Blackberry fully control its hardware. Microsoft also does to some extent (and even they couldn’t provide an option to upgrade Windows Phone 7 devices).
Now imagine trying to centrally update Android on roughly ten thousand wildly different hardware configurations (different SoCs, different sensors, different RAM/storage configuration) and you’ll understand why you’re asking Google the impossible.
Windows Update.
… is a terrible mess. It did get better since Windows 7, but it’s still a mess, especially for any ‘non-standard’ drivers and software. Is Microsoft to blame for that? I’m not sure, but it doesn’t take away the problem.
Windows Update is magical. The amount of problems it creates is virtually nill if you consider the almost literally infinite amount of permutations in the PC world.
I know hating on Microsoft and Windows Update is what the cool kids do, but it has no basis in reality.
The permutations you have in mind are mostly the same: standard office PC from different brand, and for those it mostly works (never had a hanging update?).
What definitely does not work in Windows Update is if you add in drivers and software for external components, usually from less known brands: printers, scanners, rfid/barcode stuff, programmers, sensors, cameras, firmware, etc. It’s just as much of a hell.
And like I said, I’m not sure one can blame Microsoft for what external parties do, but I do think it could have been setup in a more distributed way so that external parties could easily set up their own update repository. Too often it’s a “download once, install and forget about it until it breaks” or a “have a few dozen background processes running their own update check” system.
Please keep the ‘hateboy/fanboy’ talk out of this, it just pollutes the discussion. I’m not hating Microsoft at all here and I’m honestly surprised you even drag that in here.
And for the record, it doesn’t absolve Google here, I just think they face similar problems and neither came up with a solution (Windows Update / Google Play) that solves the wide variation problem.
Edited 2015-10-06 11:26 UTC
Thom,
I respect your opinion specially considering that you are not from a technical background. But in this case, there are some facts you should consider.
x86 is a world of difference with the ARM world. You can think of ARM as the wild west of configuration with tonnes of SoC and peripherals, all mapped to different addresses with no rule to follow.
x86 architecture is quite fixed, yes you do have different processors, add on boards and so on, but they all use standard interfaces like PCI, SATA, etc.
Google had no say on how people did things on the ARM world, and they have been trying to fix it (https://lwn.net/Articles/656324/).
They will get there but it does take time. Also as soon as Microsoft started having some models on the wild, the update times starting getting longer because maintaining multiple ARM images does not scale.
However, the OEMs could be doing a much better job if they really wanted to but alas it seems the incentives to update are quite weak when compared to the need of selling new devices.
Please stop using Windows Update as an example that it can be done since the technical difficulties are totally different. You can say Google have had enough time but I would reply that there were other priorities such as decoupling as much as possible APIs from the Android versions which was very smart.
Exactly ARM is not x86, and each ROM or update is a bespoke version of Android for that device.
Throw in how hardware manufacturers who only like shipping binary blob drivers and Google only doing massive code drops rather then open development and we have the mess we have today.
I know this specific difference between the ARM and x86 world, but at the same time, the number of possible permutations in the Android device world is still far, far less than the PC world. The Windows world is effectively a wild west, both in hardware and software, with effectively infinite permutations. While, yes, ARM in and of itself is ‘messier’ than x86, said messiness doesn’t even come close to how messy the PC world is.
And yet, Windows Update works effectively flawlessly every month, which is pretty crazy. There is no reason Google couldn’t do the same for Android *if they really wanted to*.
Sure, it’s not as sexy as Now on Tap or fancy Material animations, but unless Google fixes this, Android will remain the update mess that it is.
Thom Holwerda,
I must actually side with raraujo in this little debate. Indy OS programming on x86 is so much more feasible than ARM precisely because x86 is not the wild west. In the context of standardization, x86 has BIOS/PNP/VESA/DMI/ACPI/UHCI/EHCI/etc services. In no way am I arguing that these are good standards, but it’s still true that an x86 platform has much less variance than an ARM platform, which is the wild west by comparison. Hey, I’ve reversed your metaphor
MS has the additional benefit that virtually all hardware manufacturers are developing modular drivers that are certified for Windows ABI/APIs. By contrast Google has no such benefit in the ARM world, the lack of a stable ABI in Linux means that drivers must be rebuilt for every new kernel. If the drivers aren’t open source, then Google basically requires the manufacturer’s participation for every new kernel it wants to release – multiply this for every hardware combination.
x86 may not be a charmer, but ARM is even less tidy – just my two cents. I’d love to see more standardization on ARM, as well as a shift towards more stable kernel ABIs.
Edited 2015-10-06 12:55 UTC
And lets face it, this is where the problem is. The major problem with “generic” updates on Android are the following:
1. Device specifics builtin into Android proper (much is already moved to the HAL layer modules, but there’s still stuff around that’s simply compiled in).
2. “Unstable” linux kernel ABIs. The core Linux kernel changes over time, and since Google doesn’t promote sticking to a “stable” branch, hard to standardize.
3. “Unstable” Google linux kernel ABIs. Google themselves keep changing stuff around in their layer onto of Linux proper, so that only creates more issues. Also, every major release is based on new Linux kernel versions, with both Linux and “Google” kernel changes all around.
This in total makes it a rather big mess, on exactly the device specific code. The only way (imho) is to get Google to base their stuff on the “stable” branch of the kernel, have a much better tracking of their changes (preferably upstreaming most of that), and then force the use of that branch as base for all SoC/device vendors to use.
This, with the use of kernel modules, and probably smart use of DT (device tree), could actually get this all to work……
Ithamar,
I’d sure like to see that happen.
They were just continuing a long tradition of not having platform standards for ARM. But certainly within the Android ecosystem, had Google taken the initiative, it wouldn’t be as big a mess as it is today.
Edited 2015-10-06 16:21 UTC
> I know this specific difference between the ARM and x86 world, but at the same time, the number of possible permutations in the Android device world is still far, far less than the PC world.
This is just not true as it’s been indicated earlier. Let’s just compare Linux kernel 4.1 archs (without crypto and virtualization):
arm + arm64: 22,867,786 bytes
x86: 6,622,827 bytes
Threefold difference. Not to mention that x86(-64) is more or less standard in regard to memory and CPU initialization/memory regions/ACPI/power management/etc. In the ARM world every SoC is unique.
I know, and I never said otherwise. You’re focussing on JUST the architecture, but an OS update has to account for A LOT more – and that’s where the PC world vastly outdoes the ARM world. There are infinitely more peripherals, software stacks, programs, etc. on Windows/x86 than there are on Android/ARM.
Those peripherals are just built-in in each ARM device. It’s not because you don’t see them that they’re not there (cell phone, wifi, bluetooth, cameras, GPS, accelerometer, sensors, vibrations, NFC, radio…) . And like mentioned earlier, Windows Update doesn’t really deal with those all that well either. It’s a tough problem to solve when you give brands the freedom to develop their own thing (which is also good).
Edited 2015-10-06 14:01 UTC
Thom Holwerda,
I’m not so sure if this is true, but for the sake of argument let’s assume the following: 1 billion x86 peripherals versus 5k ARM peripherals. On the face value, one might say supporting 1 billion peripherals in an OS should be 200,000 times more difficult than the 5k. However, if those 1 billion x86 peripherals support PNP and come with (certified) drivers adhering to a common ABI, that becomes a tractable problem. Conversely if those 5k ARM peripherals are memory mapped to unknown hard coded locations and use proprietary drivers that don’t follow any particular standard interfaces, this may in fact be much harder to support.
Not to over-trivialize the matter, but hopefully this offers a plausible explanation as to why things are so difficult on ARM. To really solve these difficulties we’re going to need some serious standardization efforts across all ARM device platforms.
Edited 2015-10-06 15:22 UTC
That’s not because of ARM, that’s because of how Google builds, integrates, and distributes Android.
Not saying it is easy to do otherwise, but it can be done. There is no single technical reason for the update situation to be like it is, except for (company) politics from all the different players….
Go lookup DeviceTree for example, there are fine solutions to not having a PCI bus everywhere
> That’s not because of ARM, that’s because of how Google builds, integrates, and distributes Android.
Word!
I’d venture that this is by design rather than thru any sort of real technical difficulty. This is vendor lock-in top down bulls**t. These guys know about the market and they know that strings must be firmly attached if control is to be retained.
For decades have real Linux-based systems been able to deal with plethora of different architectures/hardware combinations thru kernel modules, binary firmware blobs, whatnot.
Have a look at https://www.debian.org/ports/ to see all the archs Debian runs on. Oh hey, there’s even Arm64 which means you can run Debian on Google’s “own” Nexus devices. Once that’s running just apt-get dist-upgrade and you’re laughing. Lollipop my mellow, Google!
And if you’re tempted to say that all these embedded devices with their wild SoCs are tricky and that the camera probably wouldn’t work have a look at what OpenWrt devs have achieved. Where there’s will there’s a way.
Blaming “difficulty” of user-space upgrades on the complexity of hardware architecture is nothing but an indicator of bad software design. Bad by design. But then they only promised to not be evil. Bad is ju$$$t fine.
Edited 2015-10-06 16:38 UTC
kakaka,
Well, a router has fewer peripherals than a phone. Don’t get me wrong, I have tons of respect for awesome work being done at OpenWrt and I am impressed with the support that OpenWRT has. But take notice of their hardware support page: 54% of hardware has no support. The latest 15.05 version has about 15% support. 67% of the devices which used to be supported by OpenWrt are no longer supported by the current release.
There are undoubtedly legitimate reasons for not being able to maintain support for all the hardware. But if we’re going to highlight the project as a role model, then we need to be careful not to create a double standard when criticizing other projects.
This isn’t to let Google off the hook, they certainly need to do better. But hopefully we don’t ignore that poor ARM platform standardization is part of the problem and that having standards would benefit not only Android but also projects like OpenWrt as well as Indy OS development. That’s why we should be pushing for them.
Hmm… had a look at the ToH and arrived at slightly different results. Total supported = 468, supported in 15.05 = 150 gives 32% (which I think is pretty good tbh) Half of that are devices supported since 12.09 release (Apr 2013) or before and quite a few from 10.03/10.03.1 (Apr 2010/Dec 2011). Not to mention the long legendary wrt54g which is still supported since white russian 0.9 (2006/2007)
.
Also note that OpenWrt dropping “support” for a device does not necessarily mean that a new release won’t run. It is sometimes down to a simple matter of severly limited ram/storage. In some cases I’m sure it’s possible to create stripped down builds of newer releases which would still run on those older devices.
kakaka,
That’s fine but to be fair we have to give the same hand-waving benefits to Android as well.
With all the differences between ARM platforms, the idea of trying to keep hardware drivers open and in the kernel makes a lot of sense…
The solution is to require that all kernel drivers be open source and merged into the standard kernel, and with a distinct separation between userland and kernelspace.
Google (or any third party) could rebuild the device specific kernels, while distributing a single unified userland to run atop those kernels.
You are absolutely right. Windows Update is a terrible mess. And I think it’s gotten worse, much worse, beginning with Windows 8. I have had a lot of problems updating Windows 8.1. I’ve since upgraded to Windows 10, and it seemed to be somewhat better than Windows 8.1 was… except that now my laptop is stuck in an upgrade loop – where it fails to install the update and as soon as it reboots it tries to install the update again, and fails again, etc.
I just want to say that I’m immediately switching my entire tech portfolio to whatever OS figures a way to help clean my bathroom.
You picked the clean bathroom thing over gold nuggets?
PC is a PC. ARM is all over the place. I don’t think it is a fair comparison. Nevermind all the other issues like the massive number of different display resolutions.