How do you feel about this article? Help us to provide better content for you.
Thank you! Your feedback has been received.
There was a problem submitting your feedback, please try again later.
What do you think of this article?
Community developed Android builds step in when manufacturers bow out.
It can be particularly frustrating when a smartphone is physically capable of providing a few years more good service, but the manufacturer has shifted their attention to shiny new models which are the focus of current sales — leaving previous hardware stuck on an older version of Android which no longer receives updates. As a result of which, security vulnerabilities are not patched and current versions of some applications may fail to run, else operate with reduced functionality.
In a previous article, we took a look at software and its implications for hardware sustainability, covering topics such as software which runs locally and software-as-a-service (SaaS), along with IoT and the benefits it can be afforded by local APIs. We also touched on custom Android distributions, a.k.a. “custom ROMs”, which we will now explore in a little more detail.
First though let’s start by taking a look at Android itself, which is from Google, right? Or is it from the handset manufacturer? As we’ll come to see, it comes from both — and others. A basic understanding of this and the complexities involved is important when it comes to appreciating what is possible with third-party Android OS device support, and what is not.
The Android Platform
The Android Open Source Project (AOSP).
The Linux Foundation amongst others argue that Android is a Linux distribution, much like Ubtuntu or Red Hat, for example. And of course, the operating system is based on the Linux kernel, which at a recent count came in at somewhere around 30 million lines of code. However, Android is significantly different from a typical Linux distribution in a number of key areas, such as the C library, package management and application frameworks used, to name but a few. Nevertheless, it is a Linux kernel which Android hardware boots and to which it owes a great deal.
Although it is possible to run native Linux applications on Android devices, this is rarely done and instead, apps are usually compiled to bytecode which is executed by the Android runtime (ART). This helps to enable compatibility across different hardware. As does the hardware abstraction layer (HAL), which provides a standard interface for hardware vendors to implement, so that the system and applications have consistent mechanisms for accessing USB, WiFi and graphics etc.
There are also system services, APIs and the Android framework, which provide functionality which is either available to end-user applications, or else restricted to use by the manufacturer’s software only. Finally, we have the applications, which might be of the privileged type installed by a hardware vendor or network operator, else just regular Android apps.
This may sound complex enough, but so far all we have covered is the Android Open Source Project (AOSP), which is developed by the Open Handset Alliance led by Google. Downstream of AOSP we then have all the low-level drivers which are integrated for a particular set of hardware, plus the vendor customisations which are used to differentiate their product. More often than not we also have Google Play Services and the associated suite of apps, which provide integration with Google cloud products, such as the app store, e-mail, instant messaging, calendar and payments etc.
Why is this important? Well, when it comes to picking up where a smartphone vendor left off with software support, there is only so much that can be done, due to the complex and in parts heavily proprietary nature of the operating system stack. Android may be notionally open source, but in practice, large parts of it are not and this can present significant hurdles for third-party support.
Open and closed
Let’s take a look at some of the key components which might be found in the Android operating system loaded on a typical smartphone, and consider which are likely to be open vs. closed.
- Linux kernel
- Mostly open source;
- … but there are likely proprietary driver modules.
- Radio baseband firmware
- Closed source.
- IMS client
- Closed source.
- Network operator apps
- Closed source.
- Google Play Services and Google apps
- Closed source.
So this means that we cannot simply take AOSP and build a new image or “ROM” which we can then flash to our smartphone and expect to have the same functionality. Without all the required kernel drivers, devices won’t work. Without a baseband firmware, our cellular radio will be useless. If we don’t have an IMS client, we won’t be able to make any Voice-over-LTE/NR/WiFi calls.
Network operator apps might provide useful features, such as supporting eSIM enrolment. While the absence of Google Play Services will at the very least mean that we need to find some other way to install apps, but may also prevent some applications from actually functioning.
As can be seen, there are a lot more moving parts involved than just those which are provided by AOSP and the above list is by no means exhaustive. Furthermore, these component technologies come from different parts of the supply chain. For example, a SoC vendor may provide not only baseband firmware, drivers and low-level SDKs, but also the IMS client, as this is often tightly integrated with the SoC. The smartphone vendor provides Android customisation and apps, which again may also be provided by a network operator. And Google provide Play Services and apps.
Fortunately, the situation is not quite as dire as it may at first seem and there are workarounds which enable functioning custom Android images to be built. This typically involves extracting the “binary blobs” from a stock vendor image, then integrating these into a new image which is built from AOSP, along with any customisations. In addition to which, apps may be installed from alternatives to the Google Play store — such as F-Droid — although these may offer far more limited choice.
In short, the situation is complex and the older hardware gets, the more difficult it it can be for third parties to provide Android operating system support. This is of course separate to the issue of newer versions of the Android OS making greater demands on hardware as time progresses.
So now that we have a basic understanding of the challenges, let’s take a look at just a few custom Android distribution options. These tend to vary in terms of their features; some are focused on extending hardware lifetime as far as possible, while others are more focused on increased security. It is also common to remove reliance on Google, while providing options for those who still want to be able to install apps from the Play store and run applications which require Google Play Services.
CyanogenMod gets a special mention despite the fact that it was discontinued over 6 years ago, due it being the first custom Android distribution, while also providing the starting point for a number of others. The distribution began life as a modified version of the OS for the HTC Dream — the first ever commercial Android smartphone — and was named after “Cyanogen”, nickname of its developer, Stefanie Kondik. Features not present in the original OS included theming, support for FLAC audio, and per-application permission management, amongst many others.
HTC Dream. Akela NDE, CC BY-SA 3.0.
Kondik managed to secure funding for the commercial Cyanogen venture in 2013, but sadly this didn’t work out long-term. Fortunately, since the OS was open source it could be forked and original features from CyanogenMod were even later integrated into the official Android codebase.
LineageOS was born out of the ashes of CyanogenMod and development resumed as a community effort. It offers features not present in AOSP, such as support for a much greater degree of customisation, along with security and privacy features, such as PIN scrambling and privacy guard (per-application permissions).
At the time of writing, LineageOS actively support almost 200 devices. In addition to which many more devices were supported and for one reason or another have been dropped, but developers are still able to create their own private builds for these, or even volunteer to restart official support.
LineageOS comes without Google apps bundled, but they can be installed. Alternatively, something such as MicroG may be installed, which is a collection of open-source libraries and services which implement the functionality required to run apps that use Google Play Services, along with a frontend to the Play store.
GrapheneOS is a heavily privacy and security-focused open-source Android distribution, which only targets selected Google Pixel smartphones. Just a few of the features include a hardened memory allocator (malloc), sandboxed version of Google Play Services, revocable per-application network and sensor permissions, a hardened Chromium-based browser, and an auditor app and attestation service which can be used to verify the integrity of the OS from another device.
/e/OS is a fork of LineageOS, with a focus on privacy and which uses MicroG as an alternative to Google Play Services. However, some of the /e/ sources and applications, such as the maps app, are proprietary. Development is led by the /e/ Foundation, while two privately held corporations are responsible for sales of smartphones with the OS pre-installed and for provision of online services.
In a previous article, we took a look at the Fairphone smartphone vendor as an exemplar for the right to repair. Their models 3+ and 4 are supported by /e/OS and although not the official operating system for these devices, they have partnered with /e/ Foundation and Murena, who offer Fairphone handsets with /e/OS pre-installed. Fairphone do also provide a website with details of open-source components and build instructions for their devices.
In this article, we have taken a high-level look at some of the challenges associated with providing third-party Android support for smartphones, and just a small selection of the custom Android distribution options available. We have also focused purely on Android and not considered other somewhat more niche options such as Sailfish OS.
As we have seen, the Android operating system stack is complex and involves many stakeholders. Unfortunately, it is not possible to simply take Android Open Source Project, build this and flash it to your device. However, there are custom distributions downstream of AOSP which integrate the additional required components and provide turnkey installation images. Furthermore, with some older and presently unsupported devices, it may also be possible to build your own ROM after a distribution has dropped official support — and optionally volunteer to become the maintainer.
It goes without saying that care should be exercised when downloading a custom ROM to flash to your device and it is recommended to use only reputable sources.
Finally, the Android smartphone serves an excellent example of both a mass market device where the useful lifetime can be extended — thankfully, Google/manufacturers don’t lock down hardware to prevent use with third-party distributions — and at the same time illustrating how we can strive to do better as engineers, by taking steps to actively enable this.