Neither , , nor anyone else should fork Android. It’s unforkable.

As happens from time to time, the suggestion has been made that cancel Phone, and instd fork Android. It's not the first time this suggestion has been made. It's probably not the last, either.
It's a poor id. 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 appliions.

The outline of the " should fork Android" argument is as follows: Phone doesn't have huge developer buy-in or sales success, but Android has both. By forking Android, could provide unique value—corporate integration with things like Exchange, Active Directory, and System Center or InTune; full 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 appliions 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 cer for 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 ch new Android relse, Google is making a forked operating system less and less viable.
Not-very-open source
Broadly spking, Google produces two big chunks of . The first is the Android Open Source Platform (AOSP) base. 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, notifiion panel, lock screen). This part is d under a mix of the GPL and Apache . Google produces periodic relse of these open source parts, though has been criticizedfor performing the actualdevelopmentlargely behind closed doors.
The second chunk is called the Google Mobile Services (GMS). (Or at lst, 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 , though, so that seems to be the most common name). This has two big portions. The Google Play Services provides a wlth of APIs and system services: APIs for Google Maps, Loion, and in-app purchasing; Google+ integration; Remote Wipe; Malware scanning; and more. Then there's the Play Store collection of apps: Srch, Gmail, Chrome, Maps, and many more.
The GMS has a few important ftures. 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 . Though Google says that the GMS suite is itself free, the process isn't, with reportsthat it costs around $0.75 per device.
GMS also seems not to be divisible: if your phone passes the GMS and can include GMS, it includeseverything: both Play Services, and the various Google-branded apps that use those services.