Recently, there have been a lot of articles written about version updates, the interactions between vendor and chipset maker, and what this means for devices going forwards. Why has this come to rise this week?
Well, it emerged this week given that the venerable Nexus 5 won't receive the update to Android 7.0 (Nougat), and Qualcomm announced it won't be providing support for the MSM8974 (more commonly known as the Snapdragon 801) on 7.0. This article was written as a collaboration with XDA Recognized Developer bumble-bee.
The topic has attracted a fair bit of interest from various news sites, but many miss out on the subtle nuances of what's really going on behind the scenes. This article will explain a bit more about how software updates work, using our experience in working with OEMs on their official firmware updates. We'll step you through what goes on behind the scenes (and why), and why you might not end up getting the latest software on your phone.
Upstream Updates
The first step in the life of an Android firmware update is the upstream update. This is what Google works on internally. In contrast with "open workflows", Android is developed using a closed workflow, with source code thrown over the wall every year or so, when a new release comes out. Originally, Google said this was to prevent fragmentation from people running bleeding-edge versions while things were rapidly evolving in the early days, but they seem to have kept this policy in place.
At some point in time, usually before the public announcement of an update (although with the recent introduction of public betas, these timescales are shifting), OEMs will be made aware of an upcoming update. They will then receive the source code at a second point in time for the final update (in the past, it was sometimes a little in advance of the launch, although we're also aware of cases where there's no early release).
The upstream AOSP repositories contain device support for only a limited number of devices. These are typically your Nexus devices. For reasons that will become clear shortly however, it is significant to note that Google doesn't have complete hardware control over these devices; the devices are manufactured by an OEM, and that OEM will buy a System-on-Chip (SoC) from a chipset maker.
Chipset Makers
Once the source code is released, the OEM's firmware team will (figuratively) sit back and put their feet up. The main Android source tree doesn't have hardware support for the myriad of chipsets used in shipping devices. Your Qualcomm chipset is most likely not supported within AOSP, for example. Your Exynos one most definitely isn't. Mediatek or HiSilicon? Forget it!
"The BSP contains the drivers and hardware abstraction layers (HALs) needed to get Android running"
It's worth noting here that OEMs like Qualcomm don't necessarily fully trust their OEM partners — the BSP is made available on a "need to know" basis. OEMs don't usually get access to the source code for some of the super-secret parts of the device (such as the software running on the baseband). Having this part closed up certainly also has potential issues, as shown by the near copious and recurring ASN.1 parsing vulnerabilities.
The BSP contains the drivers and hardware abstraction layers (HALs) needed to get Android running on your device. AOSP contains a set of HALs, which act as definitions as to what the operating system expects your drivers to implement. To use a ridiculously over-simplified (and made up, for the purpose of demonstration) example, let's imagine the flashlight on your phone.
An Example HAL – Your Flashlight
Let's imagine your device has a flashlight on the back (if you have a Nexus 7 2013, you'll need to do a bit more imagining than everyone else — sorry!). This is controlled by a driver. For our crazily simple example, let's suppose the v1 HAL says you should have one function called "setLED" taking a single parameter, the state of the light. It's a boolean – true or false. In C, this would look something like this:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
This function is defined within the BSP source code. The BSP is then compiled by the OEM during the building of the ROM, and this becomes one of the proprietary ".so" libraries on the vendor partition or area of your device. This lets an OEM keep certain parts of the workings of their device secret. For now, let's assume they want to stop everyone seeing how they turn that LED on and off.
Now imagine Google releases an updated version of their HALs in a future version of Android. They now decide that it would be nice to allow you to update the brightness of your LED, rather than just turn it on or off. Maybe this is for adaptive flash, or maybe it's just to force a HAL update, and keep the chipset makers in business? We'll let you, the reader, reach your own opinion on that one. Some HAL updates do have clear benefit (such as the new Camera HAL exposing raw shooting and similar), whereas others are somewhat less clear in purpose.
With this new (fictional) HAL for brightness, let's suppose Google says you need to again expose a function called setLED, but this time with an integer passed in for brightness. Now, 0 would turn it off, and 255 would put it on full.
If you are the OEM, you can take your super-secret code to turn on that LED, and put it into this new function. You might even use pulse-width modulation to adjust the brightness of the LED based on the number. You change the function to appear like this now:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
So what? Well, now this new version of Android is incompatible with existing "blobs". Your OEM needs to use these new blobs, because the Android OS expects to see the new function definition, and won't "find" the old one when it goes looking for a way to set the LED.
How do Custom ROMs do it?
At this point, let's take a brief intermission to look at how Custom ROMs (built from source) manage here. It's what the astute among you will be shouting at your screen right now – after all, we are XDA, the home of the HTC HD2, the longest lasting phone in the world… (just for the record, the crazy geniuses over there are running Android 6.0 on the HD2 these days! Not bad for a phone originally shipped with Windows Mobile 6.5 in 2009)
The "shim" approach is to write and build a tiny new library yourself, which contains the expected function definition – for our example, we'd support the integer for brightness. Then, within the shim, this is translated to meet the requirements of the old HAL. So for our example, we'd maybe say that any brightness requested above 128 will turn on the LED, and anything below that would turn it off. Or you could say anything not zero will turn it on. It's up to the developer. They compile the shim, and get Android to use it instead of the native one. The shim then calls the OEM blob.
A quick `adb push` and reboot should get the shim going, and let you control your fictional LED, even though you only have the old HAL.
The problem is that this is clearly an imperfect process. You'll now get quirks – this device will have a rather crummy flash, that is either fully on or fully off. That's not ideal – the OS thinks it's making a very gentle light, but the actual LED is being told it's competing in an artificial sun contest, and is trying to blind you. But hey, life's not perfect, and you now have a working LED on your old phone!
(Yes, this is one of the reasons why there are quirks and bugs when XDA users and developers manage their crazy and insane feats of porting prowess. I mean heck, the Galaxy S II is toting a seemingly usable Android 6.0 ROM now. A lot of phones released last year still don't have 6.0!)
Back to the OEM
Let's jump back to the OEM's perspective. Sadly, most OEMs are already working at least 1 phone ahead of where we're at right now. Their focus is on the next phone they are about to sell – you can't really blame them, as they only make money on devices they sell. They don't make any money from devices they sold a year or two ago, so they have to keep releasing new devices to exist. This is one reason HTC and Blackberry are in trouble – it doesn't matter how many executives are retaining a death-grip on their old Blackberry Curve, as they aren't getting a new device sale there.
If the OEM doesn't get a BSP, they aren't going to go down the XDA approach of hacking together a build. Why? Well, they need to support this firmware for their customers. If they release a firmware that's half-working, users will hate them, and rant and rave, and keep their support lines ringing out for days.
OEMs also have to contend with carriers, at least in non-European markets. Carriers don't want customers to have issues with software updates. In fact, carriers would often rather not release software updates.
To understand this, imagine your Great Aunt Alice. She's the one who phones you up at inconvenient times of day to ask for help with "that computer thing". You then describe how to click on the "Start menu", and have to identify it as the "big flag in the bottom left corner", and are met with confusion. About 45 minutes (and much frustration) later, it emerges Aunt Alice has dragged her start menu to the right hand screen edge, and simply needed to drag it back. Yes, with the left mouse button!
Now imagine you have a thousand Aunt Alice'. They're all phoning up your customer support, unable to find Candy Crush on their phone, worried that a hacker deleted it from their phone. Oh, and the icons look a bit different now – maybe the hacker is still in their phone?
Yes, this is meant to be a bit of light-hearted humour, but until you experience the reasons people will call up their carrier for support, you won't believe the problems they have. A software update which changes how the phone works, or where things are, will cause a significant support overhead. At minimum, it requires re-training of support staff (because most of them aren't your avid XDA reader, sadly).
OEM Gets the BSP
Once the OEM gets the BSP, they'll port their ROM across, and apply all their changes to the ROM. They'll pile in their bloatware, and add a horrific cartoon-ish skin that would look more at home in a teenager's Anime. Then they'll test it.
A lot.
There's all manner of requirements your phone has to comply to. The mobile networks are designed to trust the user equipment (what we call the phone) to behave correctly. This means there's a lot of testing needed to get the device approved. Software updates risk changing behaviours, so things need tested again. This is why you'll commonly see information about upcoming Sony software updates from external test services, which confirm firmware is compliant with test requirements.
Now… what happens after an update or two (or in some cases, none)? The SoC maker won't give the OEM an updated BSP. After all, the SoC maker won't get much from this. The OEM isn't making any more money on your phone since it was sold. And at this point, your phone doesn't get any more major version updates.
Cutting back on the number of BSPs the OEM wants delivered is a great way to save money – if you only need the current one, and don't intend to deliver any major version increases, this will save money on the initial SoC purchase and licensing, but at the expense of a few angry nerds on XDA down the line, wondering why they didn't get an update.
So what does this mean for updates on my phone?
Updates are complex. There's lots of different people involved in the chain. None of this excuses OEMs from the current lackadaisical and pathetic state of updates on Android. Nonetheless, there are some real challenges here.
Many OEMs are to blame for over-promising, and the inevitable under-delivering that we now associate. The sad reality is that for most OEMs, software updates are just an annoyance they could do without.
The mobile sector is mostly stuck in the mindset of feature phones. That is, where a device never gets any updates. Test it once, ship it, and never look back. With the security issues of modern smartphones, and the sheer complexity of running a full general purpose operating system, with hundreds of external libraries, that's no longer an option. Or at least it shouldn't be. Google has made some steps towards fixing this, by at least publishing security bulletins and patches for existing releases of Android (remember that until very recently, the only way to get security updates was via a new major Android OS version!)
Alas, however, this isn't really enough. Even though Google keep releasing updates, your device's security is still dependent upon the SoC maker – since SoC makers are so petrified of someone discovering how they turn on a couple of LEDs or make a sound through a speaker, they ship huge quantities of binary blobs on their devices. These blobs contain some pretty horrifically insecure code (just take a look at past Google security bulletins if you think this is an exaggeration!), and need updated. Which means updated BSPs are required.
But why isn't my laptop like this?
Desktop computers (and by extension, laptops) are completely different in architecture from mobile devices. Your mobile phone or tablet is effectively a heavily proprietary lump of silicon, designed in a rush by some people who mean well, but have nowhere near enough time to make something good. The market moves so rapidly that they're barely able to keep up with the pace at which marketing is demanding new products be launched.
This means shortcuts are taken – you won't find your phone supported by the mainline Linux kernel, and you'll find every phone has a different way to boot. On your laptop or desktop, however, vendors settled on some standard ways to boot – previously it was MBR (master boot record) with a BIOS, and now it's UEFI. This standardisation makes it possible to run the same software on each device.
While there's been some steps towards this recently, especially with Sony's outreach program and their unified kernel, it's not practical to run a mainline kernel on most phones, due to the sheer number of new vendor-specific hacks introduced to each device.
Wired the headphone jack the wrong way round? Just hack it in the drivers! There's no time to fix it in the production design.
The manufacturing team have mounted the camera module upside down in production batch 1? Throw a hack in to check the internal version code, and flip the video around if it's version 1!
Hacks like these solve the immediate problem, but only scrape the surface of the weird and product-specific changes going on. Heck, there's even sometimes entirely different chips in different revisions of the same phone, due to commercial decisions. These lead to hacks in drivers and weird decisions that only made sense at the time, to get the phone working so it can be shipped the next week.
While there is work ongoing to mainline support for 64-bit ARM chips to boot using UEFI, there's so far been no clear movement towards a more standardised way to boot ARM devices. And that's sad, because it means phones will continue to be thrown out well before the end of their working lives, because it's simply too expensive to maintain the technical debt and burden on their software.
On the other hand though, if an OEM will only make money on sale of a device, don't they need to ensure people continue to buy new phones? Would the PC market move to this model if there wasn't 30 years of momentum and legacy software already out there using the open PC platform and standard?
OK, so back to topic! What about my MSM8974? Will I get 7.0?
This is a tough question without inside knowledge from Qualcomm, which sadly we do not have at the moment. However, we can draw some information from the 7.0 Android driver API and CTS requirements. The CTS requirements specify what Google expects of a device running a given firmware. The "big hammer" used to enforce these requirements is Google's licensing to use their proprietary Google Play Services bundle – if you don't comply, you can't ship Google Apps on the device. While, for some, this might be seen as an advantage, this is obviously not what users want and expect from a device.
Android 7.0 hasn't added much by way of changes to the HAL or drivers (as described above), so any incompatibility is unlikely to come from there specifically. What is more likely to pose an issue, however, is the introduction of a new requirement for the Vulkan graphics API to be available in order to pass CTS.
At present, a lot of Systems-on-Chip (SoCs) have not had Vulkan support on their graphics processor, including the MSM8974. This is also most likely where the issue of compatibility with Android 7.0 will arise. Again though, without inside knowledge from Qualcomm, and their future plans, it's hard for us to give a definitive statement without qualifying it. At the moment however, we believe it is likely that this is the "simple" case of Qualcomm discontinuing support for the (in their eyes) aging MSM8974 chipset, and not providing a BSP (board support package) for 7.0 on that platform. If that were the case, it would mean OEMs would be almost certain to not ship 7.0 on the device – they'd have to somehow find Vulkan support for their GPU, and GPU source code is one of the ridiculously tightly-guarded parts of the mobile stacks (for no real reason, we would add – see AMD, open sourcing their own AMDGPU driver on the desktop for Linux). Sadly, however, Vulkan and graphics in general are a bit more complex than a simple LED, so this isn't something we're going to see shims to introduce compatibility for.
As 7.0 hasn't been out for long, there is a real possibility for other chipsets (other than the small number within AOSP itself) getting left behind on 6.0, due to either hardware and driver issues (i.e. no updated BSP) or a lack of SoC vendor support with regard to the Vulkan API.
The best bet is to watch this space – developers on XDA are already making good progress with unofficial ports to 7.0 for many of the devices not getting official 7.0 support from Google. These are without Vulkan support however – perhaps developers of games on Android will start to experience frustration through fragmentation if enough users start running custom ROMs without Vulkan support?
Apple tend to support their iPhone line on the latest iOS version for around 5 years – the iPhone 4s was launched in October 2011, and has been kept up-to-date up to iOS 9. It won't receive the upcoming iOS 10 update, however, which would give the phone an effective lifespan of 5 years, assuming iOS 10 is launched around October. It's worth noting that Apple don't always back-port graphics API support – The iPhone 4s and iPhone 5 don't feature Apple's Metal graphics API, which is a somewhat similar scenario to that seen with Android in Vulkan. The only difference is that Apple continued to support the older devices without the new graphics API.
What do you think? Will you flash a custom ROM on your phone to extend its lifespan? Have you say in the comments below.
from xda-developers http://ift.tt/2bRUfDT
via IFTTT
Aucun commentaire:
Enregistrer un commentaire