
The state of Android updates: Who’s fast, who’s slow, and why - thekonqueror
http://arstechnica.com/gadgets/2014/08/the-state-of-android-updates-whos-fast-whos-slow-and-why/
======
wtallis
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.

~~~
k-mcgrady
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.

~~~
amalcon
It actually costs money to compete on those things. Branding is comparatively
inexpensive.

------
Zigurd
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.

------
userbinator
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.

~~~
vacri
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)

~~~
cnvogel
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.

------
mschuster91
Wasn't the whole point of Android to leave the HW abstraction to the kernel?

What's then preventing to leave the old kernel and just dump a new userland on
it?

~~~
nakattack
No.

------
lnanek2
> 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.

------
Aqwis
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.

------
tomjen3
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.

~~~
on_and_off
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.

~~~
gizmo686
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.

