Android L – and what you need to know about stability of prior Android versions!

Bitbar, the mobile devops company. Logo, large

Not Liquorice, Lollipop or anything that were predicted to be the name of the next Android version. Google just calls it ‘L’ – at least for now. What makes Android great is its constant improvement, version by version, provided by Google with tons of new features – and naturally a bit more challenging for app developers as well. As it is not always about the look&feel – let’s see how some latest versions worked for app devs:


The design of Android’s look and feel was definitely in the key role in yesterday’s keynote. The new look – frankly, very impressive – will feature animated transitions, new interface elements, better performance, and all of those new promising improvements in UI were really well-received. In fact, Google’s folks spent quite a lot of time to describe what they call “Material design”. However, from the app developers point of view this will have an impact on how 1) existing apps work on new devices (running Android L) and how 2) new apps will work on old/existing devices (running Kitkat or older).

From the GUI point of view, every new Android version has provided some new tricks for app developers. The picture here illustrates a snapshot from our Testdroid Cloud test run data of how apps performed on various OS versions. As you can see, ICS (Icecream Sandwich), JB (Jelly Bean) and KK (Kitkat) all differ.

When it comes to the latest versions of Android – and let’s count ICS, JB and KK among that group – ICS is clearly the most robust platform. It was even obvious that updates done by OEMs broke this platform version the least and majority of tested apps worked very well on API level 15 (4.0.3-4.0.4).

The change to JB and API level 16 didn’t significantly break any other and median failure percentage remained low. However, there were many outlier cases with API level 16. For example, more issues were experienced with Vsync, extendable notifications, and especially with lock/home screen rotation support.

The API level 17 brought those lock screen improvements to users, and generally this version was very stabile until version 4.2.2 where several OEMs built their stuff on this version. Apparently, it was a big problematic version to users than ones before.

Probably the most surprisingly, the failure rate got up when Kitkat API level 19 was taken in use. The average failure percentage got nearly to the same level as it used to be with Gingerbread. Google patched Kitkat quite quickly after original release with two patch releases (4.4.1 and 4.4.2). Of those, it seemed that 4.4.2 lived much longer and 4.4.3 update got out more than half a year later.

Time will tell how well does Android L and Material Design components/effects work for app developers.

PS. If you are interested more about this type of data, check this out.