Sure, Microsoft Could ‘Fork’ Android—But It Would Be A Complete Waste Of Time

Windows Phone may not be the blockbuster mobile operating system that its designers in Redmond (or Espoo, Finland) hoped it would be. But that doesn’t mean Microsoft and its new CEO Satya Nadella would be better off doing something drastic like scrapping the project and building a new mobile OS based on Google’s open-source Android.

Some have suggested the move as a “can’t-beat-em-then-join-em” way for Microsoft to reassert its relevance in mobile. And the Wall Street Journal just reported that Nokia—whose mobile-phone division is about to become part of Microsoft—is about to release a new smartphone based on Android, one whose design predates the Microsoft acquisition.

But there’s no reason to think it’s a good idea.

Microsoft To Build On Android?

Windows Phone has made incremental gains in market share over the last couple of years, but its growth remains stagnant when compared to the volumes at which consumers and business are adopting Android and Apple’s iOS. The natural inclination of the technology punditocracy is to say, “Well, Microsoft could always just adopt Android. It’s open source, has a million apps in its app store and a billion users across the world.”

To call that outcome unlikely is almost to do a disservice to the term. We are, after all, talking about Microsoft and Google, two companies that have fought bitterly over something as minor as getting a decent YouTube app on Windows Phone. Before taking anything else into consideration, let’s just say that a Microsoft turn to Android isn’t bloody likely.

That being said, from a technical perspective, Microsoft doesn’t need to involve Google at all if it wants to build a smartphone on Android’s skeletal framework.

The logistics of such as effort are intriguing. At its core, Android is a fully functional mobile OS that will make a smartphone do everything that a smartphone is supposed to do. It ties into all the relevant hardware a smartphone needs—cellular antennas, CPU/GPU, GPS, Wi-Fi, Bluetooth, various sensors and so on. It also provides basics apps such as messaging, contacts and telephony.

All that’s included in the Android Open Source Project, or AOSP. That’s the platform any Android smartphone maker starts with before customizing it to their liking.

AOSP is, almost by definition, commodity software. It’s open source and generic and that’s the way it was always intended to be. The AOSP is kind of like an artist’s starter kit: you get the canvas, paints and brushes. What you do with it is up to you.

So in that sense, the idea of “forking” Android—say, by making a Microsoft-specific version—is sort of a joke. How can you fork a free canvas and toolset into multiple versions? It’s a starting point or a foundation, not a finished product.

In reality, though, when the punditocracy talks about forking Android, what it really means is, “using Android without Google.” And that’s a much trickier proposition. Microsoft can’t really fork the AOSP—at least, there wouldn’t be much point to doing so. And it can use Android—i.e., the AOSP—just like any other manufacturer.

But to actually make a smartphone that capitalizes on the Android ecosystem, Microsoft needs a lot more than just the AOSP.

How Google Builds Android

Many people suffer from the common misperception that Android is Google and Google is Android. This is not exactly accurate.

Yes, Google does most of the heavy lifting in Android development, but it’s not the only contributor to the AOSP. Head over to the AOSP project repository and you’ll notice that companies like Sony, Samsung, Intel, ARM, Nvida and even researchers from the U.S. National Security Agency contribute to Android.

Each new version of Android is the result of discussions that Google’s engineers hold with manufacturers and app makers to see what features and attributes they want and need. Google then sets it engineers on those problems. When enough new functions and features are ready, it releases a new version of Android.

Google Android engineer Dave Burke explained this process in an interview with ReadWrite late last year:

I think one of the things you remember that we have a pretty large developer relations team so we have a pretty close relationship with all the developers in the ecosystem so we are constantly evolving and taking feedback from those guys and using that to drive requirements to the APIs. Another example is like Netflix.

Netflix has a lot of requirements around DRM because they are basically streaming content with very strong digital rights associated with that. So we work very closely with them to make the APIs more flexible. We also had a media summit recently where we sat down with all of these media streaming companies and asked them what they wanted from Android and one of the things that they came up with was closed captioning so we added that to Android 4.4 KitKat for example. 

That is sort of the cycle that we go in. We talk to developers, work very closely with developers and get their input and then feed it into the platform and then hatch the platform.

Android development also touches on a variety of open source projects that aren’t technically part of Android itself. For instance, Google contributes the WebKit engine for browser rendering (which both the Chrome browser from Google and Apple’s Safari browser use), the Dalvik app rendering engine and so forth. Google has taken steps to build new versions of these engines (Blink for WebKit, ART for Dalvik) that are often controversial among developers but are still open source.

“We are fine with writing version two of something,” Burke said when discussing the decision to begin the project to replace Dalvik with ART in Android.

While it may seem like Google is in 100% control of all things Android, that’s just not the case. Google’s game is to be the tool builder and hub of Android development. What manufacturers, partners and app developers build on top of it is their own prerogative, at least within reason.

Google’s Android Canvas

To think about how Microsoft might fork Android by creating its own set of non-Google functions and services, it’s important to understand what Google has built on top of Android to make it the ecosystem that it is.

Consider, for instance, Google Mobile Services. This is a collection of system software and core apps that Google has built on top of the Android canvas. It includes core Google apps such as Gmail, Maps, Calendar, Hangouts, Drive, People (Contacts), Google+ and the variety of Google Play media (apps, music, videos, books, newsstand).

Essentially, Google Mobile Services provides both critical user apps for Android devices and the backend cloud services and application programming interfaces (APIs) that make them run. If Android software touches Google’s servers in one form or another, it is part of Google Mobile Services.

Ars Technica writer Peter Bright argues that Google’s recent emphasis on adding functionality to GMS has effectively rendered Android “unforkable.” He drew this reply in comments from Dianne Hackborn, an Android engineer at Google:

The thing you don’t have is stuff related to cloud services, and this is not an evil secret plan of Google, but a simple fact we have been clear about from the initial design of the platform: Android as an open-source platform simply can’t provide any cloud services, because those don’t run on the device where the platform code runs. This is a key point that seems to be completely missed. If you want to understand what Android is, how it is designed, and how the pieces fit together, you must understand this point.

Whereas Android is an open source project, Google Mobile Services is not. The development, updating and functionality of GMS is controlled by Google. Google licenses the GMS with its Android partners to make Android phones Google-y. If a smartphone manufacturer (like Samsung or HTC) wants access to the Google Play app store, Google insists that it take the entire GMS suite with it. The Google Play app store—with over a million apps—is Google’s big stick to get its manufacturing partners to adopt Google Mobile Services.

One big part of GMS is Google Play Services, which allows developers to build and deploy apps to the Google Play app store. This includes the ability for developers to accept payments from paid apps or in-app purchases. Payments are not part of the AOSP because it requires a transactional element where Google acts as the middleman and storefront between the developers and the payment processors around the globe.

Building On The Android Canvas

To use Android without Google, manufacturers have three choices. They can just use the open-source platform, which would give them a basic smartphone without access to Google Play or Google apps; they can build specific components on top, such as their own maps service; or they can try to replicate the complete stack of Google Mobile Services on their own.

It is this last bit that the industry often refers to as “forking” Android. So far, only Amazon has effectively created an entire ecosystem of its own—with proprietary apps, its own app store and developer services—without Google. The Amazon Appstore services Kindle Fire users, and Amazon has its own developer services included payments, game servers (authentication, login etc.), location services and so on. 

There’s a reason that Amazon can build its own engine on top of Android that doesn’t touch Google at all … it is Amazon. The ecommerce giant has all the capabilities to duplicate all the functions Google provides in GMS—its own cloud infrastructure, plenty of money to spend on engineers that build resources for the platform, its own media store (books, movies and music) and an app store.

Not many companies have the infrastructure or clout to use Android go head-to-head with Google Mobile Services and hold their own, but Amazon is certainly one of them. Microsoft certainly looks like it could be another. It has its own infrastructure and cloud, developers to build a platform and resources to make it a reality.

Whether it’s a good idea to do so is an entirely different question.

Microsoft Building On Android: Completely Impractical

Nothing is stopping Microsoft from taking the AOSP and building its own services on top of it. Nothing, that is, but logic and reason. 

Windows Phone may not be a blockbuster, but at least it has a semblance of an app store, a unique user interface and millions of users. What would be the purpose of tossing Windows Phone in favor of Android? The biggest reason is attracting developers and their apps. But that’s not exactly a winning proposition, as both Amazon and BlackBerry demonstrate.

The Amazon Appstore has about 131,000 apps as of February 2014. It has reached this number after almost three years in operation (it launched in March 2011; the Kindle Fire followed that autumn). It’s nowhere near the million apps on Google Play and is missing some big titles that prominent developers haven’t ported to the Appstore. Amazon doesn’t say how many Kindle Fire tablets it has sold, so it’s impossible for developers to know how large its user base is.

BlackBerry didn’t build on top of Android, but it did give developers the ability to use the Dalvik runtime engine and to port Android apps to BlackBerry 10. This has turned out to be a major disaster for BlackBerry. One developer abused the system and flooded the BlackBerry app store with thousands upon thousands of awful apps.

In the end, the Amazon Appstore and BlackBerry World are niche markets that have presented as much opportunity as frustration and headache for developers. Microsoft has no desire to be a niche market within the realm of Android app developers. 

Why Start From Zero?

For Microsoft, to build on Android is to start from zero. Zero marketshare, zero apps. Zilch. Nada. Nothing. Microsoft has already been on this road when, earlier this decade, it ditched the prepubescent Windows Mobile CE for Windows Phone.

A transition to Android would be similarly wrenching. It’s not as if Microsoft is going to come out with a device using the AOSP and all of a sudden have access to a million Android apps. Developers would need to port their apps to any Microsoft store that houses Android apps, tie into Microsoft’s APIs and cloud and maybe redesign their apps to meet Microsoft’s aesthetic and user interface standards. As BlackBerry and Amazon have shown, there’s a limited market for developers willing to do that.

The bottom line is that developers chase eyeballs. Developers don’t build for Windows Phone—despite the earnest actions of Nokia and Microsoft’s outreach efforts—because Windows Phone doesn’t have a user base in any way comparable to those of its larger competitors. Why would developers then port to a Microsoft app store running Android apps when that device has no users?

It’s too late for Microsoft to start over, using Android or anything else.

Read more : Sure, Microsoft Could ‘Fork’ Android—But It Would Be A Complete Waste Of Time