The state of Android updates: Who’s fast, who’s slow, and why
arstechnica.com
arstechnica.com
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.
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.
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?
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.
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.