It would be nice if OEM performance on delivering updates was tracked for all first-tier OEMs and more devices. This is great guidance for buyers of Android devices, but there needs to be more of it.
The article doesn't mention the huge number of unbranded/clone/not-well-known Android phones/tablets from China, which basically won't get any version newer than the one it came with (unless unofficial ROMs come out).
I have one myself, it's running a 4.2.x (rooted) and does what I need it to, so I'm not really concerned. It probably doesn't affect the average user all that much either.
I think for the user, the fragmentation of Android at versions 2.x was an issue, since major, fundamental features were coming in at each release. The features for 4.x have been less fundamental - my own phone gets typical use, and has gone 4.1 -> 4.2 -> 4.3 through the carrier's own slow process, but I haven't noticed a difference in the day-to-day functioning of the device (it does run a little smoother, and the battery is 2 years old and showing it, but nothing in terms of features)
I don't know by heart about the versions you quoted, but it might just be that some of the user visible changes have been hidden from you for the sake of not irritating users.
Be concerned: It's not getting security updates so you can get a malware infection from a bad app or malicious web ad. There goes your Google account etc.
There is a continuous stream of fixes for remotely exploitable bugs being committed to the public repos by Google and apple. Just shift through them and apply to the old WebKit...
A lot of folks don't know because they don't want to know. Again, I am not sure who to blame here. People might not be even aware of what an upgrade is or what Android is in itself.
I stick with all Nexus devices. I get upgrades 2 weeks after the release announcement. I don't think Android is fragmented by design but by user choice.
>I don't think Android is fragmented by design but by user choice.
Google forces vendors to ship Google's services if they wish to use the Android branding. I don't see why they can't include language in the contract that says vendors should update the OS too. All Google seems to care about is whether user data flows into their servers.
I got a OnePlus One - a device from China that is on 4.4.4 and where the developers promised (yeah, okay.. Just words so far) a timely upgrade to the next version (”3 month after AOSP release").
So basically, the vendors who maintain Android forks that diverge significantly from upstream take longer to ship updates, the carriers don't care about updates, and even slightly-aged phones get left out in the cold. It seems like all of that could be significantly helped by Android and the vendors' forks being operated like open-source projects, with continuous pulls and rebases as necessary to keep the forks in sync.
Unfortunately, the entire OS and all its feature set of stuff that's got nothing to do with cellular is still held back by the carriers "concerns" about controlling the devices on their network: the carrier-locking and attempts to prevent the device owner from having root access. We need to separate the connectivity from the user-facing OS, the way we have a dichotomy for our wired internet connections with ISP-controlled modems and user-owned and controlled routers. The hardware's pretty much set up that way already, though the carriers might want a bit more compute power available to them in the cellular baseband if they don't get to have access to the application processor.
Why do US carriers care so much about modifying device software and branding etc. In the UK I don't think any carriers mess with the device in anyway. At least not that I've seen. Competition is almost completely based on coverage, price, data etc.
I really wish Android was split into a kernel which just needed to support the device and _everything else_ which was an app that was updated regularly or else you couldn't market your phone as an Android.
Obviously not as drastic as that but it seems that's what Google are trying to do with Play Services. Take the core features of Android and put them in an app on the Play Store. Still a long way to go though.
That's exactly what Google has been doing for the past years.
It took some time but now :
-Google Apps are entirely decoupled from the OS. They are preinstalled and live in the system partition but are updated by the PlayStore. That way pretty much everyone (minus some apps that don't support 2.x) always has the latest version of these apps.
-Google Play Services embeds many features that are considered OS level : security, job batching, location, chromecast, ... It is updated every 6 weeks.
Not to mention that from a third party dev perspective, Google provides compatibility libraries that allows to manage apps that run on a dozen of APIs levels, with either backports or 'gracious fallbacks'.
There are some features that can't be decoupled from an OS update though, and so far it does not look like it is going to change.
I am curious to see how the OEMs are going to handle Android L. The 4.x updates were very smooth from an user point of view with only added features here and there.
L is revamping many things, which might confuse some users.
That is still far away from just a device specific kernel (although it does cover most everything a user would care about).
I recently looked into porting cyanogenmod to my tablet (Dell Venue 7). It has an interesting scheme that seems more in line with what tomjen wants. There is an unlocked bootloader that allows you to flash the "/system" partition. Within a days worth of porting, I was able to Intel's fork of Android and successfully flash the system partition. [1] What is interesting in their setup is that the root parition (and bootloader) live in a separate part of the storage, and I did not find a way of writing to them (I think that requires a key). This still isn't creating just a device specific kernel, but the root filesystem is pretty low-level stuff that even most tinkerers wouldn't care about updating, and you can work around it (run an updated version from /system) if you want to.
[1] Unfourtuantly, Intel's changes appeared to not have propigated back to cyanogenmod yet, so I abandoned trying to port it to avoid duplicating a lot of effort.
> As for everyone else, how quickly they update seems to depend on how complicated their skin is and how much they take advantage of the update mechanisms Google has created.
Honestly, as someone who worked at an OEM, all that matters is how many engineers are assigned. There are usually hardly any assigned to port a new Android version to an old product, and almost all are assigned to the next product release. The skin often isn't even a huge issue. At the company I was at there were two different software divisions, and the one that ported a new version of Android to platforms (ripping out all the software drivers and getting the hardware ones working, mostly) was completely different from the one that worked on getting the skin framework many levels above running on the vanilla version of Android then produced for the target.
LG's Optimus G is supposedly getting the Kit Kat update in August/September/October. I'm not sure why they're even bothering given how late they are. Personally, I've switched to Cyanogen on my Optimus G despite some issues with charging and battery life.
30 comments
[ 4.1 ms ] story [ 82.4 ms ] threadI have one myself, it's running a 4.2.x (rooted) and does what I need it to, so I'm not really concerned. It probably doesn't affect the average user all that much either.
E.g.: http://arstechnica.com/security/2014/02/e-z-2-use-attack-cod...
And when running Firefox, compromising the browser will yield an easy whole device compromise since the OS won't provide an extra layer of security.
I went with a Samsung when LG never updated I'll be getting an iPhone next for the same reason.
I stick with all Nexus devices. I get upgrades 2 weeks after the release announcement. I don't think Android is fragmented by design but by user choice.
Google forces vendors to ship Google's services if they wish to use the Android branding. I don't see why they can't include language in the contract that says vendors should update the OS too. All Google seems to care about is whether user data flows into their servers.
What's then preventing to leave the old kernel and just dump a new userland on it?
Unfortunately, the entire OS and all its feature set of stuff that's got nothing to do with cellular is still held back by the carriers "concerns" about controlling the devices on their network: the carrier-locking and attempts to prevent the device owner from having root access. We need to separate the connectivity from the user-facing OS, the way we have a dichotomy for our wired internet connections with ISP-controlled modems and user-owned and controlled routers. The hardware's pretty much set up that way already, though the carriers might want a bit more compute power available to them in the cellular baseband if they don't get to have access to the application processor.
Closed handsets and user locking goes back to the roots of the industry.
Not to mention that from a third party dev perspective, Google provides compatibility libraries that allows to manage apps that run on a dozen of APIs levels, with either backports or 'gracious fallbacks'.
There are some features that can't be decoupled from an OS update though, and so far it does not look like it is going to change.
I am curious to see how the OEMs are going to handle Android L. The 4.x updates were very smooth from an user point of view with only added features here and there. L is revamping many things, which might confuse some users.
I recently looked into porting cyanogenmod to my tablet (Dell Venue 7). It has an interesting scheme that seems more in line with what tomjen wants. There is an unlocked bootloader that allows you to flash the "/system" partition. Within a days worth of porting, I was able to Intel's fork of Android and successfully flash the system partition. [1] What is interesting in their setup is that the root parition (and bootloader) live in a separate part of the storage, and I did not find a way of writing to them (I think that requires a key). This still isn't creating just a device specific kernel, but the root filesystem is pretty low-level stuff that even most tinkerers wouldn't care about updating, and you can work around it (run an updated version from /system) if you want to.
[1] Unfourtuantly, Intel's changes appeared to not have propigated back to cyanogenmod yet, so I abandoned trying to port it to avoid duplicating a lot of effort.
Honestly, as someone who worked at an OEM, all that matters is how many engineers are assigned. There are usually hardly any assigned to port a new Android version to an old product, and almost all are assigned to the next product release. The skin often isn't even a huge issue. At the company I was at there were two different software divisions, and the one that ported a new version of Android to platforms (ripping out all the software drivers and getting the hardware ones working, mostly) was completely different from the one that worked on getting the skin framework many levels above running on the vanilla version of Android then produced for the target.