Ending Support For Android 4.x
In February 2017 HL launched a revamped application on both IOS and Android platforms. During the development of the updated application we measured the usage of our existing clients for the upper and lower ranges of Android versions that they used. Our lowest supported version of Android is currently Android Jelly Bean 4.3 — which was originally released July 2013. At the time of the release of our updated application this was already just under three years old. Our highest supported version when we relaunched was Android Marshmallow 6.0. In December 2017 we increased this to Android Oreo 8.0, again in August 2018 to Android Oreo 8.1, and most recently in November 2019 to Android 10 (sadly this has no desert based code name).
In three years of operating the updated version of the app we have increased support by 6 Android versions (due to the way Android internally numbers their platform it is API 23 to 29 — you can find out more about this on this page). However we have not deprecated support for lower versions which has meant the number of Android platform versions we support is now API 18 to 29. That’s 12 distinct Android versions!
This story is very common in the Android community. Unlike our IOS friends support for older platform versions tends to have a pretty long tail — meaning they stick around in use for a long time — and it is not uncommon to see apps support older Android versions. However, what is also common is for apps to periodically reassess this at various points. According to our stats for the last quarter Android 4.x versions account for less than ~ 0.54% of our user base.
Starting today we are advising clients that support for Android 4.x will be withdrawn by the end of summer 2020.
The reasons we are doing this
Relative Effort
At a conservative estimate, we spend around 5% of our time testing each Android 4.x platform version (4.3, 4.4.x) for specific issues. The chart above shows the relative weighting of Android 4.x users against the total population of our Android users. In terms of percentages we are around 0.54% and falling. Given that the older the Android version, generally, the harder it is to find suitable test devices and that the platform itself is worse compared to newer Android versions this effort has become unsustainable. For example the way certain Android device manufacturers used to provide support for vector graphics meant that we frequently see issues on these devices when we try and display simple vector icons. Supporting these niche devices incident by incident is not an efficient way to develop the application.
Build Times
We spend a large amount of our time as developers constantly building the code base (compiling the code, arranging the many visual and text based assets in the app, packaging the application) so that we can distribute test builds to our developers, test teams, and product owners. At the time of writing the code base is around 177k lines of code and takes a large amount of time to build from scratch. Improvements in later releases of Android can help here but not until we update our minimum supported version to Android 5 Lollipop. The practical benefit of this is that we can spend more time improving the app and less time waiting around for builds.
Features
We want to take advantage of new platform features without having to create workarounds for older Android devices. These workarounds aren’t always the best and at the very least introduce extra code paths that we need to be careful of when we are developing / testing. Examples of this include not making full use of the In App Updates API (this allows our update process for new and critical versions of the app to be smoother and faster for clients), and (full) use of transitions framework which is a user experience improvement. Whilst the situation has improved vastly in recent months for the longest time supporting background tasks was not a great experience. This is one the areas we needed to pay special attention to because the implementations differed so wildly between Android versions.
Security
We have a high commitment to security with our apps. Older versions of Android are typically out of their update windows from the manufacturers and do not receive critical security updates. In addition, older version of Android (whilst judged secure at the time of their release) now may be judged insecure by today’s standards. Security is an ever changing landscape so one of the best things you can do to protect yourself is make sure you are running up to date software. An example of this is the level of TLS v1.2 support starting in Android 5.0 Lollipop. Whilst lower versions may enable this feature it is enabled by default starting with Android 5.0. This improves the security of connections when your device talks to servers. In lower versions of the OS we had to do a considerable amount of extra work to enable this and test TLS v1.2.
Third Party Dependencies
Like the majority of the Android apps we use OkHttp as the basis to create connections and communicate over the internet. The OkHttp team have made it clear that new versions will not support lower than Android 5.0. Given that this is a critical dependency for our app we want to ensure that we can continue to update the library.
The Rest Of The Industry
This follows similar requirements from across the Financial industry:
· Nationwide Android 5.0 and up
· Santander Android 5.0 and up
· NatWest Android 6.0 and up
· Barclays Android 5.0 and up
· Lloyds Android 5.0 and up
What should users do after the end of support?
We will be reaching out to users on Android platforms below Android 5.0 to inform them about the end of support for their device. If they are able to upgrade to Android 5.0 or above we recommend they do so at their earliest convenience.
Thanks to Nathan May for proofreading.
