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 (CDD); and pass the Compatibility Test Suite (CTS) (see here).
A taste of Android forks: Amazon Fire Phone/Fire OS (left), Oppo N1/CyanogenMod (middle), Blackphone/PrivatOS (right)
The CDC defines compatibility across all technical aspects of a device, covering hardware, such as minimum acceptable specifications (e.g. minimum screen size, 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.
Open Handset Alliance logo
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.’
Andreas Constantinou pointed out in early 2010 just how closed the supposedly ‘open’ Android platform was, identifying eight ‘control points’ used by Google to keep OEMs from straying. But it took until 2012, when Google shut down Acer’s planned launch of a phone running Alibaba’s Alyiun OS, for the world to really sit up and take notice of the fact that, for OHA members, forked Android was a big big no-no.
An insistence on compatibility within the ecosystem makes sense: a messy and fragmented, multiply-forked Android would be a nightmare for developers and consumers alike, with apps running differently, or not at all, on different manufacturers’ phones. However, over the years Google has tightened its grip on Android, bit by bit, and revealed that practical considerations aren’t the only thing driving their insistence that phones be ‘compatible’. ‘The’ ecosystem has shrunk, and it’s looking more and more like ‘Google’s’ ecosystem: and that’s driven as much by business as by practical concerns.
Google Mobile Services
From the beginning, Android phones were made up of two things – AOSP, and Google Mobile Services (GMS). In the early days, the GMS suite was pretty small – Gmail, YouTube, Maps, Talk, amongst others. AOSP is open, and GMS is proprietary. To get their hands on GMS apps, OEMs need to license them from Google; and in order for a device to get a license for the apps, it must pass the Android Compatibility Test Suite and meet the Android Compatibility Definition. In other words, if an OEM wants those ‘must-have’ Google apps, it can’t go inventing a new flavour of Android – a few chocolate sprinkles are OK, maybe even a cherry on top, but the basic recipe is a fixed one. According to a leaked 2011 licensing agreement between HTC and Google, any OEM shipping devices with Google Applications on it must agree not to ‘take any actions that may cause or result in the fragmentation of Android, including but not limited to the distribution by Company of a software development kit (SDK) derived from Android or derived from Android Compatible Devices, and Company shall not assist or encourage any third party to distribute a software development kit (SDK) derived from Android, or derived from Android Compatible Devices.’
Over time, Google began migrating applications – like Search, Music, and the Calendar – out of AOSP and into GMS. Any OEM wanting to use AOSP to build its own Android fork would now have to build their own versions of these apps, on top of email, maps, and so on. (Ars Technica has a good rundown of the application migration here.) On top of that, the device would lack the Google services APIs that lots of third-party apps need. And Google didn’t stop there. Google Mobile Services mutated into Google Play Services in September 2012.
A fork in the road: Why Google Play Services is key to understanding the ‘forking’ question
Back in May 2013 at the Google I/O Keynote there was no mention of an Android upgrade. Instead, Google announced a bunch of new features to be rolled out to Android devices via Google Play Services. Google had started to move away from Android-as-platform to Play Services-as-platform. As Ron Amadeo writes: ‘Play Services has system-level powers, but it’s updatable. It’s part of the Google apps package, so it’s not open source. OEMs are not allowed to modify it, making it completely under Google’s control… If you ever question the power of Google Play Services, try disabling it. Nearly every Google App on your device will break.’ It is ‘a single place that brings in all of Google’s APIs on Android 2.2 and above.’ Things like Play Game services, Google Cloud Messaging and fused location services are all handled by Play Services, and not the OS.
Some of the better known apps packaged as part of Google Mobile Services
By rolling out updates through Play Services, Google gets around the problem of fragmentation – no more waiting around for OEMs to implement the latest version of Android – and it also makes it less attractive for anyone to want to fork Android. The non-Google bits of AOSP, already attenuated from the GMS days, become positively pallid with Play-as-platform. This means that as time goes on, anyone wanting to build an Android fork will have a lot more work to do than, say, even Amazon did with its Fire OS. It also means that apps that hook into Play Services won’t work properly on forked versions of Android.
When is a fork not a fork?
Reports that ‘forked Android or AOSP smartphones grew 20% sequentially from 1Q 2014 to 2Q 2014 and also accounted for 20% of the smartphone market,’ have generated a lot of chatter in recent months about ‘the “more open” version of Android… beginning to threaten the “less open” version of Android’, and what the implications might be for Google of AOSP’s rise.
Implicit in this line of thinking is that ‘forks’ of Android by vendors like Xiaomi are a threat to Google’s business. Or, as one Time journalist put it: ‘That means Google, not Apple, is Google’s largest competitor. By powering such a large percentage of the competition, the company has become its own worst enemy.’
Xiaomi’s Mi3, with Play Store installed
In reality, though, while OEMs like Xiaomi, Oppo and Gionee aren’t members of the OHA, their phones are ‘compatible’ – that is, they can tap into Play Services and the Play Store; Xiaomi’s Mi3 comes pre-loaded with the usual suite of Google apps, including the Play Store if bought outside of China. In other words, these aren’t forked phones, or AOSP-only phones, or anything of the sort. Within their own, Chinese markets, they use their own app stores, and have their own ecosystems, but outside of that, Google, and Google’s apps, work just fine on them, subject to Google granting the OEM a license. (For a list of Google Play compatible phones, see here.) If Chinese OEMs can have their cake and eat it – their own app stores and ecosystems in China, and Google’s Play Store and ecosystem in the rest of the world, that’s good for Google, for so long as it’s locked out of the Chinese market. Russian search behemoth Yandex’s Android ‘fork’, Yandex.kit, is, similarly not a fork of Android at all – it’s a suite of apps that connects to Yandex services. Hence the Huawei Honor 3 Yandex, which runs Yandex.kit out of the box, hasn’t seen Huawei booted out of the OHA.
CyanogenMod and custom ROMs – are these forked Android?
Custom ROM-makers like Cyanogen aren’t OEMs, so the same rules don’t apply to them – passing the CTS, compliance with the Android CDD. If the custom ROM is flashed onto a ‘compatible’ phone, then everything is gravy… except for the pesky issue of Google apps, which need to be licensed. Cyanogen found this out the hard way in 2009, when Google slapped lead developer Steve Kondik with a Cease and Desist letter, the gist of which was that he wasn’t licensed to distribute Google apps with CyanogenMod.
In his response to the letter, Kondik argued that, ‘I only develop for google-experience devices which are already licensed for these apps’, but Google’s lawyers didn’t think that stood up, so Kondik duly ceased and desisted, and no longer bundled Google apps into CyanogenMod. However, he came up with an ingenious solution: users could Google-ify their CyanogenMod installations by backing up the Google parts already on their phones, and reactivating them after installation – without incurring Google’s wrath.
Since then, Cyanogen has become Cyanogen Inc., and has released two Google-certified CyanogenMod phones: the Oppo N1, in partnership with OEM Oppo last December, and the more scarce, buy-by-invite-only OnePlus One, in partnership with Chinese startup OnePlus. Both the Oppo N1 and the OnePlus one have passed Google’s CTS and CDD, meaning that they officially run Google’s apps and access the Google Play Store out of the box.
So… Is Cyanogen a fork?
Yes, Cyanogen is a fork, but unlike, say, Amazon’s, it’s a compatible one. It’s AOSP, with Cyanogen-flavour extras, and the option to include Google apps. For now, at least, Google seems to be viewing the Cyanogen fork from AOSP with the same benevolence it does Samsung’s Touchwiz, or HTC’s Sense – technically forks, but not so much that they risk fragmenting Android. Indeed, CyanogenMod can be considered closer to the Vanilla Android experience than Touchwiz or Sense, since it doesn’t seek to differentiate itself in the same way by adding a distinctive layer or skin (launcher, icons, and general interface and menu customisations) on top. That said, news last week that Google has sought to acquire Cyanogen Inc. would suggest that Google views the company’s version of Android as a threat – and one that can’t be neutralised by the CTS or the CDD.
What about the Blackphone, and PrivatOS?
And then there is the Blackphone, a high-end device running PrivatOS, a fork of Android with privacy optimisations at its core, and pre-loaded with a suite of security-focused apps. It claims secure browsing, secure file-transfer, and secure voice, text and video. Unsurprisingly it does not come with the Play Store installed, or any other Google Services for that matter, and according to Blackphone support center, Google Play Store is not supported.
PrivatOS also overhauls the Android app permissions model, allowing for much more fine-grained control over the behaviours that a given app can perform.
But this is something of a niche fork, and shouldn’t be too much of a concern for Google, even in this post-Snowden era of heightened privacy-awareness. And in terms of app compatibility, the target user of this device is unlikely to be too upset if Angry Birds crashes due to more restrictive permissions. Blackphone makes no apology for this: the Blackphone support pages state outright that this is likely to happen if you install apps from other App-stores and sources.
Who is really really forking Android?
When we look at who else is really forking Android, the picture becomes a little clearer. Close to home, it’s Amazon, with its Fire OS and Fire Phone. In China, Baidu has produced its own Android fork, Baidu Yi, and has produced three phones with three different companies, Dell, TCL and Foxconn; while Alibaba is pushing Alyiun OS. What these companies have in common is that they’re cloud and services companies, first and foremost. Device manufacturers have been notably slow to fork Android wholesale – and with good reason: OEMs who do lose GMS/Play Services, and have to go it alone to build an entire ecosystem from the ground up. The only companies, so far, who have truly forked Android are those ones which want to compete with Google’s real business – selling eyeballs to advertisers, or, as with the Blackphone, those who actively reject Google’s requirements on security grounds. Amazon’s Fire OS is primarily a content delivery platform, while on the Fire phone the main distinguishing feature – Firefly – has been described as ‘a barefaced attempt to drive more sales’ on the site. The aim of all of these forkers is to push extant ecosystems under consumers’ noses; the ecosystem comes first, then the fork. Indeed, Samsung have been making noises about moving to forked Android for a while, but the launch of its Tizen OS has been postponed, indefinitely, tellingly because of a need to ‘further enhance the Tizen ecosystem’.
What might the future hold for Android forks and Android forkers? Google’s bid for Cyanogen Inc. gives us a hint. ‘Compatibility’ has, from the start, been Google’s not-so-secret weapon in the fight against Android competitors, but with both Cyanogen and Chinese manufacturers deftly dodging the strictures of the OHA while remaining compatible, the seach giant will almost certainly be looking at ways to counter any future threat from them to its control of the Android ecosystem. This could mean acquisitions, a redefinition of compatibility, or a tweaking of Play licensing agreements to lock potential competitors out. Neither of the last two options seem likely or necessary in the near future – in the developed world Chinese manufacturers are happy to play ball with Google and the Play ecosystem, while in the developing world Google’s Android One phones will likely squash any ecosystem competitors (Chinese or otherwise) at the lower end of the market.
In the meantime, Yandex’s move with Yandex.kit is a clever one. It can technically be shipped by OHA members, as shown by the Huawei example, meaning that in time – barring any really swingeing moves from Google – the biggest names in Android manufacture like Samsung, HTC and so on could also ship phones with Yandex.kit on them. Yandex can, meanwhile, build up and out its ecosystem, extending beyond Russia thanks to its piggy-backing on ‘compatible’ Android phones; in time, then, OEMs might have a choice between Yandex flavoured Android, or Google flavoured Android, and they might start really forking. Until that happens, forks in the Android road will keep looking an awful lot like roundabouts.
[1] The full list of ‘Google Applications’, per a 2011 agreement between HTC and Google, is: Set-up Wizard, Google Phone-top Search, Gmail, Google Calendar, Google Talk, YouTube, Google Maps for Mobile, Google Street View, Contact Sync, Android Market Client (not products downloaded from Android Market), Google Voice Search, and Network Location Provider – this list has since been extended↩
This piece was written in collaboration with Eadaoin O’Sullivan
Leave a Reply