A collaboration with Ruadhan O’Donoghue, published on mobiforge.com. Below is a short excerpt; visit Mobiforge for the full article.
With worldwide sales of phones based on Android forks on the up, and with big cloud competitor Amazon consolidating its move into the Android-based OS space race with the release of the Fire phone, it’s time to look at Android forks. What is a fork? When is a fork not really a fork? And what do they mean for users and developers?
What is an Android fork?
There are two kinds of Android forks – ‘compatible’ and ‘non-compatible’. ‘Compatible’ Android forks are those that are based on the Android Open Source Project (AOSP); comply with the Android Compatibility Definition Document (CDC); and pass the Compatibility Test Suite (CTS) (see here).
The CDC defines compatibility across all technical aspects of a device, covering hardware, such as minimum acceptable specifications (e.g. minimum screensize, RAM, and storage are all specified), and also acceptable software configurations including UI, native APIs, and security models.
The CTS is a downloadable test-harness which executes JUnit test-cases, packaged as Android .apk files, on a target device or simulator to determine its compatibility.
Compatible forks may or may not include Google apps (gApps) or Google Play Services, but, because they’re ‘compatible’, gApps and Play Services can be sideloaded or added later by users, meaning they can participate fully in the Play app ecosystem. Examples include CyanogenMod and the MIUI OS. ‘Non-compatible’ forks are built on AOSP, but are built to run their own ecosystems. These forks are locked out of Play Services, though many Google apps can be sideloaded without rooting, and the Play Store installed on rooted devices. Examples of ‘non-compatible’ Android devices in the West (we’ll talk about China and Asia later) include the Amazon Fire phone and the soon-to-be-discontinued Nokia X.
Some history
On 5 November 2007 a group of technology companies announced the development of Android through the Open Handset Alliance (OHA). Android, per the announcement, would be ‘made available under one of the most progressive, developer-friendly open-source licenses, which gives mobile operators and device manufacturers significant freedom and flexibility to design products.’ That license was and is Apache 2.0, but for manufacturers the ‘freedom and flexibility’ touted in the announcement was qualified almost from the start. The most obvious lock-in was the requirement for any manufacturer wanting to gain access to what used to be called the Android Market (now the Play Store) and to leverage the Android brand (trademarked by Google) to sign up to the OHA – and signing up to the OHA meant signing up to an anti-fragmentation agreement. This agreement is a non-disclosure one, but in practice, it means not releasing handsets that failed the compatibility test suite (CTS), and the CTS was and is controlled by Google.
So while AOSP was open, and manufacturers, in theory, were free to do whatever they wanted with it – including forking – in practice anyone wanting to get access to the juicy, marketable bits of Android: the app store, the Google suite of apps (Gmail, Maps, and so on [1]), had to sign up to the OHA, and had to cede an awful lot of control to Google. In a 2012 blog post, Google’s Andy Rubin described this as a ‘virtuous cycle’: sign up to the OHA, make ‘compatible’ Android phones, and ‘all members of the ecosystem’ – app developers, OEMs, consumers – benefit. Alternatively, as Google engineer Dan Morrill wrote in an internal email: ‘[…] we are using compatibility as a club to make [OEMs] do what we want.’
Image: Wonderlane.