Z10 - BlackShop Now!

₦ 36,900

Forums Register Log in

TECHNOLOGY LAB / INFORMATION TECHNOLOGY
Neither Microsoft, Nokia, nor anyone else should fork
Android. It’s unforkable.
Canning Windows Phone and using Android would be a huge mistake.

by Peter Bright - Feb 8 2014, 2:00pm WAT

414

Broderick

As happens from time to time, the suggestion has been made that Microsoft
cancel Windows Phone, and instead fork Android. It's not the first time this
suggestion has been made. It's probably not the last, either.

It's a poor idea. Google has worked to make Android functionally unforkable,
with no practical way to simultaneously fork the platform and take advantage
of its related strengths: abundant developers, and abundant applications.

The outline of the "Microsoft should fork Android" argument is as follows:

Windows Phone doesn't have huge developer buy-in or sales success, but
Android has both. By forking Android, Microsoft could provide unique value—
corporate integration with things like Exchange, Active Directory, and System
Center or InTune; full Office support; a polished user experience—and make
the platform depend on its own cloud services (Bing, Bing Maps, Azure) rather
than Google's. But simultaneously, it would still have access to all the Android
applications that people depend on.

The result should be a platform that's somehow more attractive to consumers,

by virtue of the Android brand and all those Android apps, more attractive to
developers thanks to the Android APIs, and cheaper for Microsoft to develop,
since core operating system development can be left to Google.

Where this falls down is that there's no good way to use the Android platform
this way. It's not designed for it. In fact, with each new Android release, Google
is making a forked operating system less and less viable.

Not-very-open source
Broadly speaking, Google produces two big chunks of code. The first is the
Android Open Source Platform (AOSP) codebase. This provides the basic bones
of a smartphone operating system: it includes Android's version of the Linux
kernel, the Dalvik virtual machine, and portions of the basic user interface
(settings app, notification panel, lock screen). This part is licensed under a mix
of the GPL and Apache license. Google produces periodic code release of these
open source parts, though has been criticized for performing the actual
development largely behind closed doors.

The second chunk is called the Google Mobile Services (GMS). (Or at least,
sometimes it's called GMS. Sometimes it's called just Google Services, and
sometimes it's Google Play or Google Play Apps; GMS is what it's called in the
code, though, so that seems to be the most common name). This has two big
portions. The Google Play Services provides a wealth of APIs and system
services: APIs for Google Maps, Location, and in-app purchasing; Google+
integration; Remote Wipe; Malware scanning; and more. Then there's the Play
Store collection of apps: Search, Gmail, Chrome, Maps, and many more.

The GMS has a few important features. GMS isn't open source. Anyone can take
AOSP and slap it on a phone. That's not true of GMS. To get GMS, the device
has to meet certain technical requirements (performance, screen resolution,
and so on), and it has to pass validation. Though Google says that the GMS
suite is itself free, the validation process isn't, with reports that it costs around
$0.75 per device.

GMS also seems not to be divisible: if your phone passes the GMS validation
and can include GMS, it includes everything: both Play Services, and the
various Google-branded apps that use those services.

The split between AOSP and GMS is not constant, either. Google has slowly
been migrating more and more functionality to GMS. For example, in the latest
Nexus 5, the core phone user interface—the thing that you use to launch apps
and show icons—has been rolled into the GMS Search app.
Similarly, APIs have made the move. AOSP contains a location API, but GMS
contains a newer, better one, with additional features. Google encourages
developers to use the GMS API, and the AOSP Location API mostly dates back
to Android 1.0, and hasn't seen any substantial changes since Android 1.5. The
result is that many third-party applications are not merely "Android"
applications: they're GMS applications, and won't run without the proprietary,
non-open Google software.

Four ways to do Android

There are four ways that hardware builders can use Android on their phones.

The first is the way that Google really wants companies to use Android: by
relying both on AOSP and GMS. Pass the certification, include all the Google
services and Google apps. That's what companies like Samsung and HTC and
LG do. Going this route still provides some facility for the OEM to customize.
OEMs can provide their own apps to sit alongside the Google ones, for example.
It appears that Google isn't completely happy about this—there are reports
that the company recently made an agreement with Samsung whereby
Samsung would reduce the amount of customization of the user interface and
deprioritize or remove its apps that competed directly with Google-branded
equivalents.

Taking this path provides the best compatibility with third-party applications by
ensuring that they have both AOSP and GMS APIs available to them. It also
provides the most consistent experience: in spite of the various customizations
that are done, it means that Google's apps will be available, and those apps will
work the same way on any AOSP+GMS device.

It also cedes most control to Google, and that level of control will only grow.
Each new release increases the level of integration with Google's own services,
and Google is moving more and more new functionality to GMS, leaving AOSP a
barebones husk.

At the other end of the spectrum, you can ignore GMS entirely. Ship a phone
with AOSP and perhaps some custom software on top of it to make the
experience a little less rough for users, and call the job done. At the very
cheapest end of the market, there are companies doing precisely this; it's
abundant in China, in particular. If they choose, OEMs can provide their own
stores and other services to fill the many, many gaps that omitting GMS leaves,
but they're always at a disadvantage relative to GMS devices, because they
won't be compatible with any third-party applications that use GMS' APIs.
That's not a small category, either, since features such as in-app purchasing
are in GMS.

The third option is the one that spans the two: ship a device with AOSP, and an
equivalent to GMS that provides new implementations of substantially the same
APIs. Provide workalike replacements for services such as location and
mapping, but plumb into Microsoft services rather than Google ones. No
company has really gone down this route. The closest is Amazon, which
provides near-drop-in replacements for some Google APIs (in particular
mapping), but which hasn't even begun to keep pace with GMS development in
general.

Technically, however, a company with sufficient development resources could

provide its own GMS replacement. The overhead would be not insignificant,
especially as—to ensure optimal compatibility—the replacement would have to
replicate not just correct functioning, but any bugs or quirks of the GMS
implementation.

There are also lots of little awkward aspects of the GMS API; it includes such
capabilities as "share with Google+" which few companies have any real
counterpart to. Another example: there is an API for handling turn-based
multiplayer gaming. A company could implement this API and have its own
server infrastructure for managing the gaming sessions, but obviously these
gaming sessions would be completely separate from Google's gaming sessions,
fragmenting the player base in a way that game developers are unlikely to be
keen on.

As an added bonus, should the ultimate resolution of Google's long-running

legal battle with Oracle be that APIs are, in fact, copyrightable, this kind of
wholesale reimplementation of GMS would become legally actionable. Google
could, if it chose to, shut it down through the courts.

To these three options, one could perhaps add a fourth: use AOSP to provide a
few essential services—support for hardware, telephony, and so on—but then
build an entirely new platform and APIs to run on it. Aspects of Amazon's API
support would fall into this category, with some of its APIs covering the same
ground as GMS APIs, but in a completely different, incompatible way. It's not
clear, however, that any manufacturer has entirely embraced this path, though
one might argue that Ubuntu for Android is similar, at least in spirit.

You can have compatibility or control: Not both

The first of these options—AOSP with GMS—is the only option that provides
the full Android experience. It's the only one that ensures developers can
transfer their skills perfectly, the only one that ensures that the full breadth
and variety of Android software is available. However, it's clearly not a good
option for Microsoft, given that it would almost entirely cede control of the
platform to Google—and judging by the advertising company's track record, it
would cede even more control with each new Android release.

The second option—AOSP with a few extra custom extras—has the upside of
providing an opportunity for Microsoft to integrate its own services. It would
support some Android software, though exactly how much is unclear. It would
certainly mean omitting any high-profile title using in-app purchasing, so, say,
Plants vs. Zombies 2 or the latest iteration of Angry Birds would be out. If one
were building a feature phone platform, this may be a somewhat reasonable
path to take. When the phone is only really built for running the built-in apps
(camera, browser, e-mail) the fact that many Android apps would be
incompatible doesn't really matter.

The rumors of a Nokia-built Android phone suggest this kind of approach:

AOSP under the hood, but with Nokia services, not Google ones, on top.

This approach also probably works acceptably for ultra-low-end devices where
compatibility isn't such a big deal, which accounts for much of the Chinese
AOSP market. But for Microsoft, this would be missing the point: the company
already has a platform that's not compatible with the latest and greatest high
profile apps. It doesn't need another one.

However, it's important to understand just how deficient this kind of device
would be. Google has pushed very significant pieces of functionality into GMS,
including messaging and the Chrome browser. The AOSP counterparts are
buggy, feature deprived, and by at least some accounts, barely maintained. If a
company wants to use AOSP without GMS, it has a lot of work to do if it wants
to produce a high quality experience. The open source parts just aren't good
enough.

Amazon's Kindle experience also demonstrates how even having an

Android-like AOSP-derived platform is challenging. Kindle doesn't have the
latest and greatest Android games, because their various developers haven't
bothered making non-GMS versions of their games, even though the Kindle
platform is very similar to Google's. In other words, the application challenge
already faced by Windows Phone isn't solved by using AOSP. The only way to
solve the application issue is to be not merely an AOSP platform but a GMS
platform.

The third option—AOSP with a home-grown GMS equivalent—would solve this,

but it would also maximize the development effort required by the forker.
Providing equivalents to every GMS capability ensures at least that users get a
decent experience. It would also reinstate the software compatibility that AOSP
without GMS forfeits.

But this is a huge undertaking. For Microsoft, the effort required to build a GMS
workalike on top of AOSP is going to be comparable to the effort required to
build the Windows Phone shell and APIs on top of Windows. In fact, it's likely to
be somewhat greater: Microsoft already has, for example, a browser engine
that runs on Windows. It doesn't have one that runs on AOSP.

Moreover, it still implicitly gives Google control over the platform. Various
aspects of how Android is used are determined by the underlying APIs: sharing
between applications, for example, is done in a particular Android way. Any
platform using Android in this way would have only a limited ability to take the
platform in a different direction from the one Google chose.

The fourth option—use AOSP with an entirely new software stack on

top—gives freedom and flexibility, but to what end? The kernel isn't the
important bit. Microsoft already has a smartphone kernel. Windows Phone 8
already uses it. And strikingly, for Microsoft, ditching Windows Phone doesn't
mean that the company can ditch development of this kernel. It's already being
developed—for Windows! The kernel isn't the hard part.

Fork off
If Android were an open platform in the way that Firefox OS or Ubuntu for
smartphones were an open platform, the forking suggestion would make more
sense. The AOSP/GMS split wouldn't exist. Everything would be in AOSP, so
piecemeal substitution of back-end services without having to reinvent vast
tracts of code and without any major compatibility implications would be
practical.

But it isn't. Not only is it not this kind of an open platform, but Google is
actively working to make it functionally less open with each new release. The
result is that a forker has to make a choice: they can give Google control and
get the all the upsides of the platform, or they can snatch control from Google
and get almost none of them.

Android isn't designed to be forked. With GMS, Google has deliberately

designed Android to resist forking. Suggestions that Microsoft scrap its own
operating system in favor of such a fork simply betray a lack of understanding
of the way Google has built the Android platform.

PROMOTED COMMENTS

wffurr Smack-Fu Master, in training jump to post

You left out Google's licensing agreements with hardware manufacturers, which
prohibits them from shipping incompatible (read non-GMS containing) Android
devices based on AOSP code AND GMS devices. Basically, a hardware OEM will
have all GMS applications rejected if they build an AOSP-based device for a
different software vendor. Amazon has had to shop around a *lot* to find an
OEM for the Kindle - it has to be an OEM with no ambitions of becoming their
own Android brand.

5 posts | registered Nov 8, 2012

READER COMMENTS 414

Peter Bright / Peter is Technology Editor at Ars. He covers Microsoft, programming and software
development, Web technology and browsers, and security. He is based in Houston, TX.
@drpizza on Twitter

← OLDER STORY NEWER STORY →

 SITE THEME
Light on Dark
Dark on Light

VIEW FULL SITE

© 2014 Condé Nast. All rights reserved

Use of this Site constitutes acceptance of our User Agreement (effective 1/2/14) and Privacy Policy
(effective 1/2/14), and Ars Technica Addendum (effective 5/17/2012)
Your California Privacy Rights
The material on this site may not be reproduced, distributed, transmitted, cached or otherwise used,
except with the prior written permission of Condé Nast.

Ad Choices