Prolific leaker evleaks, whose stock in trade is smartphone-related rumors, has said that Microsoft is going to produce a Lumia phone running Android, branded "Nokia by Microsoft."

This isn't the first time that this kind of rumor has been floated, with both Windows and Windows Phone talked of as candidates for running Android apps. The logic is very simple: developers aren't writing apps for Windows's Metro environment or Windows Phone. They are writing apps for Android. Put those apps on Windows and Windows Phone and the app problem is instantly solved.

Of course, the downsides of this approach are quite clear. If Windows Phone or Windows can run Android apps, why should developers looking at Microsoft's platform bother writing Windows Phone and Windows apps? Might as well just write Android apps and have an app that works both on Microsoft's platform and beyond. This logic applies even to those developers who have taken the plunge and created Windows or Windows Phone apps; why bother maintaining them when an Android app could target the very same users plus many more?

We've arguably seen this in practice already—on BlackBerry 10. BlackBerry 10 supports (some) Android apps, and while it's hard to be certain, it seems that this facility (combined, no doubt, with BlackBerry 10's minuscule market share) has stifled the development of BlackBerry-native applications. There are signs that BlackBerry has largely given up the fight, with the news earlier this week that it has adopted Amazon's Android app store on BlackBerry. This more than doubles the number of apps available for the platform but essentially concedes that developers are unwilling to write native apps for BlackBerry 10.

The difficulties actually run deeper still, in a number of different ways. Perhaps the biggest issue is one we touched on before: the unforkability of Android.

If you buy a Samsung Galaxy S5, for example, it will contain a range of Google-developed software. Parts of this software, such as the operating system kernel, the Java-like virtual machine used to run many Android applications, the basic user interface, are freely available open source (called the Android Open Source Project, or AOSP). Other parts, however, such as the "OK Google" search, the Gmail application, the fancy caller ID that does reverse lookups for you, and the Google Play Store, are not open source. They're closed source components that are not freely distributed or modifiable, and in principle these are only licensed for use on devices that meet Google's compliance criteria.

Moreover, these proprietary parts include various APIs. For example, while AOSP includes a basic geolocation API, the closed source components include a newer, more capable geolocation API. While one can develop apps that use the AOSP API, Google encourages developers to use the closed source API so that they can take advantage of additional features such as geofencing. Collectively, these apps and APIs are known as the Google Mobile Services.

If Microsoft made its platform compatible with Android, it's likely that it would only make it compatible with AOSP. Compatibility with AOSP is more straightforward; Microsoft could, for example, run AOSP inside a virtual machine. This may be a little inelegant, but it would at the very least ensure good compatibility.

But there's no such straightforward route with the Google Mobile Services. Microsoft can't simply bundle those proprietary components with its Windows or Windows Phone devices. It would have to negotiate a license for them. While, technically, this is possible (assuming Google would be willing), it would mean bundling apps such as Gmail, Google Drive, and the Google Play store with Windows and Windows Phone.

From a software compatibility perspective, the impact of including AOSP but not the GMS varies. In some markets, the lack of GMS is not such a big deal. In China, for example, many tens of millions of phones are sold that use AOSP in conjunction with third-party, non-Google storefronts. Apps are routinely built to take advantage of these alternative storefronts, and they use non-Google services for capabilities such as in-app purchasing.

Microsoft even has one of these alternative storefronts of its own, courtesy of the AOSP-powered Nokia X that the company continues to support and update.

But in the US and EU, the Google apps and services are much more important. Vendors, most notably Amazon, have shipped tablets (and, imminently, phones) that use AOSP without the Google apps and services, but the experience of these devices falls short of what most people in these markets expect. For example, want to run the Starbucks app on your shiny new Fire Phone when it's released? No can do. At the time of writing, the app is only available through Google's storefront.

This is, of course, not set in stone. With the release of each new Kindle Fire tablet, Amazon has announced an array of big-name Android apps available for its new tablets; the Fire Phone is likely to repeat this. Developers can modify their applications to work with Amazon's set of services instead of Google's, and it appears that they are willing to do so, at least occasionally.

What's not evident, however, is a long-term commitment to support Amazon's services. Amazon was proud to announce that it had Plants vs. Zombies when it launched the Kindle Fire. But that's where it stops. The smash hit Plants vs. Zombies 2 is nowhere to be found. Given the choice, Electronic Arts has opted not to bother making an Amazon-compatible version of the new game. Likewise, while many of King's games are available on Amazon's store, including Candy Crush Saga, the new release Bubble Witch Saga 2 isn't there.

It's this gap, among other things, that leads none other than Sundar Pichai, who oversees Android at Google, to say that he doesn't view phones such as the Amazon Fire as "Android Devices." He categorizes most of the phones in China as being "'Android open source' rather than Android."

Unless Microsoft included or cloned GMS, its own Windows and Windows Phone devices would be in the same boat as Amazon's. Yes, they'd work with lots of AOSP-compatible apps, and yes, Microsoft could offer alternative APIs for things like geolocation and in-app purchasing, so apps could be ported if developers wanted to. But if you wanted to call an Uber taxi? No go. Sext someone in Snapchat? No official app. Show off your lunch to all your Instagram buddies? No official app. More generally, whenever you see someone advertising an app with this logo:

There's a pretty good chance that it won't be available for your hypothetical Windows Phone. This is in spite of the work required to port being really quite light overall. Developers have shown that they can't really be bothered.

To emphasize this point further: porting an Android app to Amazon's fork is (in general) tremendously easier than porting that same app to Windows Phone. And yet, if you want official, first-party apps for, say, Instagram or WhatsApp, Windows Phone has them. Amazon right now doesn't. Both platforms have a range of unofficial, third-party apps for these services.

It's not impossible that, given sufficiently many users, developers would support Microsoft's Android in a way that they haven't with Amazon's. But getting there is hard work: Microsoft would need to somehow draw people to its platform's second-rate Android experience in order to get a long-term good one.

Update: Amazon tells us that Instagram, Uber, Starbucks, and WhatsApp should be available by the time its Fire phone launches. Whether this will translate into the long-term, on-going support that "real" Android enjoys, or be the one-off support that has been more common for Amazon's store, remains to be seen.