Even New Phones Are No Longer Guaranteed To Have the Latest Version of Android (theverge.com)

Vlad Savov, writing for The Verge: The OnePlus 5T and Razer Phone are two fundamentally different devices, which are nonetheless united by one unfortunate downside: both of them are going on sale this month without the latest version of Android on board. OnePlus will tell you that this issue is down to its extremely stringent testing process, while Razer offers a similar boilerplate about working as fast as possible to deliver Android Oreo. But we're now three months removed from Google's grand Oreo launch, timed to coincide with this summer's total eclipse, and all of these excuses are starting to ring hollow. Why do Android companies think they can ship new devices without the latest and best version of the operating system on board? The notorious fragmentation problem with Android has always been that not every device gets the latest update at the same time, and many devices get stuck on older software without ever seeing an update at all. What's changed now is that the "one version behind the newest and best" phenomenon is starting to infect brand new phones as well. The 5T and Razer Phone are just two examples; there's also Xiaomi, which just launched its Mi Mix 2 in Spain with 2016's Android Nougat as the operating system.

Comments

Apple devices

[Quzak]

Say what you will about Apple and their devices, but I always have access to the latest version of macOS and iOS.

Oreo may be an outlier

[swillden]

It won't surprise me if OEMs are a little slower to roll out Oreo than they have previous dessert releases, because Project Treble is an enormous change for them. With Treble, Google is drawing a hard line between the Android system and the underlying hardware. Because OEMs have in the past been accustomed to being able to change things at all levels of the stack -- as long as the compatibility test suite passes and associated non-functional requirements are met -- this change is requiring them to restructure their customizations.

Further, since the hardware API is now well-defined, Google is testing it. That couldn't be done before. It's a good thing for the ecosystem and for future compatibility, but it requires work. For example, I wrote a suite for the hardware API that I own and found that the Google Pixel couldn't pass it, because the implementation (from Qualcomm) on the Pixel didn't actually meet the specification in many small ways. Not ways that actually produced observably-incorrect functionality at the higher layers, but it was wrong. It took Qualcomm a couple of months to fix the problems and deliver a version that could pass the new test suite.

So, Oreo has created a lot of new work for component vendors and OEMs, and it's going to take them time to work through it.

In the long run, of course, this should be great for the ecosystem. It should actually allow a vanilla AOSP build to be be flashed onto any device (assuming locked bootloaders and verified boot don't stop you). And once everyone is accustomed to the new structure, it should actually make it much easier for OEMs to get new versions out faster, not only for updates, but on new devices as well.

In the short term, I'm not surprised to see OEMs choosing to launch with Nougat, where they don't have to meet Oreo's requirements. This isn't because they don't want to, but because they have product launch deadlines to hit. By next year's launches they'll have had time to get squared away and I expect things to start moving faster than in the past.