Opinion: Android Is Its Own Worst Enemy for Updates
XDA users are no doubt familiar with the common complaint on Android over the delays on updates reaching their phone. Users are often seen eagerly awaiting the latest security update to protect them from something like Stagefright, or waiting on the next point-revision to fix some AOSP bugs. And, once a year or so, users wait to find out if their beloved device will receive a major version upgrade to the next major release of Android (Marshmallow being the current example).
While the first (and possibly second) type of update should be resolved by the major OEM players announcing monthly security updates (with carrier agreement and assistance to get things sped along), the last type of update remains an ongoing challenge. Major updates, for want of a nicer way to put it, are a nightmare. Let's take a look at why that is.
Big Changes
This first point will most probably provoke significant disagreement and anger in the comments, but it needs to be said, because it's actually one of the biggest factors. Major versions of Android often change a lot. Too much, in fact, for OEMs and carriers to be comfortable rolling out an update. Look at the progression of Android from version 2.3 to 4.0, and then from 4.0 to 4.4. Finally, take a look at the progression from 4.4 to 5.0 and 5.1. We're talking fairly significant user experience changes for users.
While XDA users will be keen to get their hands on the latest changes as soon as possible, and play around with (and critique) the latest UI changes, this is unfortunately a major issue for carriers and OEMs. Their customer-facing support teams need updated scripts (yes, as you probably had guessed by now, anyone you speak to on the phone is typically not familiar with the handset, but is instead simply reading from a script).
"Customer support is a big business, and it takes time to build up new scripts and test them"
Where is this "any" key?
The best way to imagine this is to think about a time you've tried to give a relative IT support over the phone – you tell them to press "Start", and they say they can't see a start button. You and I know that "Start" is the button at the bottom left, but they don't, now that the text "Start" is missing from it. Likewise, when you tell them to press "any key", they go away to spend a minute or so, only to pronounce they can't find the "any key".
Given the number of recent UI paradigm changes in Android (into Holo, then away from Holo towards Material), this means a lot of changes for customer support. Before an update can be released, it needs full support documentation to be made and tested.
This takes time and costs money – it's often cheaper to just not release the update, or to plan for a device to only receive a single update.
If Google would get their user interface right, test it thoroughly, seek feedback, then stop changing it, it would be a real help to carriers and OEMs wanting to update phones. Yet if things keep changing, there will always be a reluctance to push out major updates. If something big changes, the OEM often needs to modify AOSP to restore their previous behaviour. Take a look at how each OEM modified the Android 5.0 volume system, to try to avoid users losing the "silent mode" function. The average user doesn't care about the arguments for or against it – they just want their phone to work the same today as it did yesterday, before they took this update. Therefore, radical changes to Android make it less likely for an update to roll out, as it means more engineering to "fix" the broken user interface or user experience changes made.
If things keep changing, there will always be a reluctance to push out major updates.
So yes Google, if you're reading, it would be a great help if you could get a UX paradigm and stick with it. iOS has barely changed over the years, yet Android can't seem to get comfortable on something for more than a year or two. Awesome for people who like constant change, less than awesome for the average user, which OEMs and carriers cater towards.
Hardware Support
Every major release of Android supports some new hardware. It's pretty much a given – with major releases every year or so, there's inevitably some hardware added by OEMs during the preceding year, using their own APIs. In a bid to reduce this fragmentation, Google tends to bring this functionality into the core Android API. Some examples of this included Bluetooth Low Energy (BLE), which was originally supported by a vendor-specific API, before Android 4.3 brought cross-vendor API support.
Likewise, Android 5.0 added support for OpenGL ES 3.1, a new Camera2 hardware API, and some new media and audio handling support. It also added support for detecting other hardware features, like verified boot, ambient temperature and humidity, and the user's heart rate.
Android 5.1 added support for multiple SIMs on a device, and a number of carrier integration services. Not as big as 5.0, but remember 5.1 was a minor update.
With Android 6.0 though, we're going to see fingerprint authentication support baked into the APIs, so devices can authenticate users via fingerprints, and use fingerprints within other apps as a standard means of authentication. There's also a whole host of voice interactions code, to integrate with hardware and build conversational voice services with users. Bluetooth styluses are also supported via APIs, and BLE scanning is adjusted for power saving. There's also support for 4K displays, and a host of audio protocol changes for interfacing with dedicated audio hardware and MIDI devices. There's a specific API (finally) for the device's flashlight/torch, and for Camera image reprocessing on the camera module.
Phew. That's a lot. The problem with these significant changes to APIs though is that it is more workload for OEMs and carriers to develop and test. What sounds like a small change to BLE power saving during scanning will require some exhaustive testing to ensure it doesn't introduce regressions. Adding fingerprint support via an Android API means Samsung (and anyone else who's released a device with a fingerprint reader already) will (well, should) rewrite their support around this new API, and ensure the API talks nicely to their driver, and update their userland software to interface with these new APIs.
That's a load of work. For a device that's no longer your priority. As alas, much as you may disagree, any phone that's been released is no longer the priority of the vendor or OEM – their engineering division is already hard at work on the next product, going through the exact same process as last time, trying to wipe out as many bugs as possible before release. Scale this up to a company like Samsung (with perhaps 18 variants of one "flagship" device, to satisfy each US carrier's whims of consumer oppression). And we've not even started talking about the mid-range devices (which are still new, such as their J-range). And then we have the Note range, and the Edge range, and the Edge+. And the Core range for developing markets. And their "mini" variants. And the "Active" range of flagship-derivatives. I think you get the idea…
Whose Fault is it?
Can't let you update that, Dave.
At this point, you're perfectly right to call into question the title of this article, and say it's OEMs to blame for releasing too many devices. And that's definitely a factor. But underneath this, we should consider what custom ROMs manage to achieve – groups of dedicated hobbyists manage to maintain firmware for large numbers of devices, by using more sensible approaches to product development, where they run the same code on every handset, and make minimal changes needed to get something running on a device.
Will we likely ever see OEMs do this? Nope… Not until hell freezes over – it would hinder product differentiation on software features, and would mean that "new" features would likely be seen on existing devices before the launch of the next product.
The challenge, however, is one faced by the OEMs as well – when a new major version comes out, everyone rushes to re-sync their code, and merge any changes they had, which Google didn't have in AOSP. Then, nothing works, because of hardware changes. While there's not much publicly accessible information about this, since it's part of the PDK, or platform development kit, only made available to partners in the Open Handset Alliance (OHA). The PDK is where Google announces the changes to hardware support and drivers which are needed to match with changes in the underlying hardware abstraction layer (HAL).
Abstraction?
The purpose of abstraction is to make available a generic (and standardised) interface to something else. We see abstraction every day in real life – abstraction allows us to understand the concept of "paying for" something, with multiple ways to pay for it. We're achieving the same underlying task, but we recognise it happens in different ways. We form the generic task and policies surrounding it (pay before you leave the shop) independent from the means of payment (cash, cheque, debit card, credit card, NFC contactless). This means when a new payment technology emerges, we all already understand how "payments" work, and just add a new type of payment.Similarly, a HAL does this for hardware and its drivers. Rather than handle every different camera modules' means of switching on the flash LED for flashlight/torch functionality, a HAL is created. This HAL is a definition of the outward-facing interface (i.e. expose a function taking 1 integer argument, being flash state. This will be 0 to turn off the flash, and 1 to turn on the flash). This is a load easier than the Android operating system needing to directly send an I2C command to the camera module, where that command is unique to each particular manufacturing revision of a particular model – some devices have different revisions with different camera modules, putting Samsung's 18 "models per phone" to shame! Heck, different hardware on the same model isn't even a new thing!
The problem is that the abstraction layers do change between Android releases. Sometimes significantly. And, most often, the OEM doesn't have access to the driver source code, in order to update the exposed abstraction layer code. This means the OEM needs to wait on new, updated blobs from their SoC (system-on-chip) developer. That's often Qualcomm, or possibly MediaTek or Intel. This company, invariably, wants paid money for these updates (since otherwise they'd be doing the work for "free"). You'd better hope your OEM budgeted for this. I know from experience (although you simply need to trust me on this, as I will not disclose specifics) that this has been the direct cause for a number of specific handsets to not receive further updates – the OEM didn't have an agreement with their SoC provider for updated board support packages, and they had not budgeted for this. This meant no new board support package of drivers, and therefore no update for that device.
That's a Wrap(per)!
"So, how do custom ROMs run Android 5.1.1 on the HTC HD2?", I hear you ask. A device which never even ran Android, and which was released in 2009. More to the point, how do custom ROMs bring recent firmwares to devices that didn't get OEM support? There are three approaches – one is to reverse engineer open source drivers for a device. This is no mean feat, but it leads to a really well-supported device for the future, since the driver's outward-facing interface can be adjusted when Google tweaks the AOSP HAL. The next approach is to find a similar device using the same hardware, and "repatriate" the drivers from it. This often is done on GPUs, which are very fussy about the versions of their driver blobs. The last approach is to "wrap" the original driver. This is easiest when only a small change has been made to a HAL. If, for example, the HAL changed our exemplar flashlight implementation from:
int toggle_flashlight(int status) { int success; success = i2c_write(FLASHLIGHT_ADDR, status); // ... }
to now require two separate functions, one to turn on the light, and one to turn it off. That's not a big change, but if this driver is a proprietary binary blob, you can't easily edit the source to fix it. You could write a wrapper though, which would do this:
int light_on() { int success; success = toggle_flashlight(0x1); // ... }
int light_off() { int success; success = toggle_flashlight(0x0); // ... }
We've now "wrapped" the existing function (toggle_flashlight) with the new ones we have to present (light_on and light_off). As you can imagine, this gets more complex and time consuming with things more complex than an on/off LED.
The root cause here is the changing of HALs. If Android would keep its HALs the same, and not make changes with each version, we'd be in a much better place. It would also be really beneficial if older HALs remained fully supported for a longer period of time than at present. Today, while the old HAL might not completely break, it's not likely to remain around for long. Changes to HALs lead to problems going forward. On the iOS platform, Apple is in control of its hardware and its software, so this is less of a concern. Yet we see devices supported for a long time (the iPhone 4s from October 2011 will receive the upcoming iOS 9)! This just goes to show that the hardware isn't necessarily the limiting factor.
It's worth noting, though, that security updates are not typically affected by these considerations – they can (and should) be easily back-ported to previous versions of the operating system. That doesn't happen though, as it generally seems Google have no interest in maintaining anything other than the very latest major version of Android. This is a real shame, when you consider the very limited resources that would be needed in order to maintain security patches for (say) 5.0 and 4.4, while 5.1 is the latest (and the target for new patches and exploits) and 6.0 is under development.
Conclusion
If AOSP had a fixed HAL, where changes were versioned, and older versions remained fully supported for a minimum of 5 years (which sounds like an eternity), that would be a good step towards getting Android devices supported like iOS devices are. Yes, 5 years sounds like a long time, but if you consider a 4-year handset is getting an update, 5 years is enough to give a small safety margin. With a versioned HAL, we'd see OEMs able to keep using devices, without being held at the whim of their SoC supplier's pricing. A stable user interface paradigm would also be essential – we need to get the user experience right on Android, and keep it there.
If you look over at the competition, they're doing incredibly well without constantly altering their user interface. Yet there's a huge article showing the progression of Android UI.
iOS 8 on an iPhone 6, versus the original iPhone )
At the end of the day though, just imagine if the Galaxy S2 was receiving the upcoming Marshmallow (6.0) update. That's where we need to be, to even match what Apple are doing with their software updates. Will we get there? Probably not… But we could certainly do a lot better than we are seeing right now, if Google would stop messing around with their HALs, and realise they need to engineer an operating system that is compatible with previous devices, and stick to a UI for more than a year.
source: xdadevelopers
0 comments :