Microsoft Ends Effort To Bring Android Apps To Windows 10 Mobile
by Brandon Chester on February 25, 2016 4:50 PM EST- Posted in
- Smartphones
- Microsoft
- Windows 10 Mobile
At the 2015 BUILD developer Conference Microsoft demoed four application bridges that they hoped would improve the number of applications available for Windows 10 Mobile, which would benefit the Windows platform as a whole. The two most interesting showcases were Project Islandwood, which helps developers to port their Objective-C applications to Windows, and Project Astoria, a subsystem for running existing Android applications right on a Windows smartphone. Today it looks like the latter of those projects has officially met its end.
The death of Project Astoria won't come as a big surprise to those who have been keeping track of Windows 10 Mobile's development process since BUILD. Back in October of last year, preview builds of Windows 10 Mobile stopped including the Android runtime and there wasn't really any explanation as to why. Since that time, Project Islandwood has continued to be promoted by Microsoft while there hasn't been much news about Astoria. This led many in the development community to suspect that Microsoft had decided to kill the project, although there was no official confirmation until today.
In my view, the death of Project Astoria has both good and bad elements. Since it was essentially packaging Android applications to run on Windows 10 Mobile, the applications never fit in with the rest of the platform and so the question then became why you wouldn't just go buy an actual Android device. On the other hand, it did provide an easy way for developers and users to bundle up applications that didn't exist at all on Windows 10 Mobile, which would help fill the app gap in a less than optimal but usable manner.
According to Microsoft, the official reason for the death of Astoria is that developers felt that having two bridges from mobile operating systems was mostly redundant when their applications likely existed on both Android and iOS. With Microsoft's recent purchase of Xamarin, they may also be betting on developers creating applications in C# that can be deployed across Android, Windows, and iOS. In any case, Microsoft's bridges for Objective-C, JavaScript, and Win32 apps are still very much alive, but the prospect of easily bringing over Android applications to Windows 10 Mobile is gone.
Source: Microsoft Windows Blog
Facebook
Twitter
RSS
45 Comments
View All Comments
AndrewJacksonZA - Friday, February 26, 2016 - link
@ddriver: "1 - C#... is slow, even slower than Java"I can tell you from personal experience that for the use cases that I had, both developing the code and executing the code was faster in C# than it was in Java.
lmcd - Friday, February 26, 2016 - link
C# is slower than Java? Where have you been?And Xamarin's been doing great work. Given that .NET is in the process of being ported to Linux and .NET has consistently been closer to the metal than Android's various VMs and RTs, I wouldn't be surprised if .NET ends up being more native than Java on even Android.
Isn't the point that Xamarin makes it portable?
C++ is "as fast and efficient" as you can get it to go. Not the same thing.
ddriver - Saturday, February 27, 2016 - link
OK, let's be generous and say it is not slower, but only AS SLOW as Java, still far from ideal.CaedenV - Thursday, February 25, 2016 - link
I wonder if this is due to how well the iOS bridge is coming along and they don't want the confusion of having 2 big bridges; or if this is because the Android bridge just had issues and had to be abandoned.Omoronovo - Thursday, February 25, 2016 - link
Astoria ended up not being a "bridge" but more akin to an entire android subsystem. All of the W10 Mobile builds with Astoria enabled ended up having degraded performance the longer they ran due to the "effective" Android subsystem siphoning resources.Astoria was nothing like Islandwood - it was not a "recompile and forget" process, it was literally running native Android binaries on windows phone by catching and modifying native android calls... the overheads were enormous, and ended up impacting native applications.
It never made sense for Microsoft to introduce a bridge for one ecosystem (islandwood) and then a whole-hog abstraction layer for another. If they re-imagned Astoria as a bridge (like Islandwood) but for Android applications, it would be far more successful, far more usable, and would in no way detract from making native Windows Phone applications.
lmcd - Friday, February 26, 2016 - link
Well, yes and no -- the more open nature of Android means that there can be surprising system calls that you wouldn't get in iOS development.Omoronovo - Saturday, February 27, 2016 - link
I don't really feel that's much of a valid concern though. Android applications can't call what isn't in the SDK, so Microsoft just needs to use the SDK as a base for the bridge. As long as they can provide analogues for all of the calls used in the SDK, they can build a bridge compatible with all apps built against that version of the SDK.Any calls that don't have direct analogues will need to be coded for on an as-needed basis, but since Microsoft controls both half of this potential software stack (Bridge and OS), they wouldn't have much issue doing so with minimal performance loss, so long as performance-critical calls were handled natively rather than abstracted.
Omoronovo - Saturday, February 27, 2016 - link
Note that my comment also included the NDK extensions to the SDK for covering native syscalls. Luckily those are getting rarer in Android development, since they tend to limit application compatibility between devices. Only apps made purely using the SDK are officially going to work across all Android versions (and handsets) that support that level of SDK, so it's a good place to start for Microsoft to get the best compatibility, with the least amount of work.Chufteh - Friday, February 26, 2016 - link
It's very easy to make Windows Phone apps or port Android apps to the platform. The problem with the lack of apps is not due to a shortage of talent, experience or tooling, it's due to incumbent project bureaucracy and the perceived cost of supporting an extra platform. If your budget or timelines are tight, the small market of the Windows version of your app is the first to go.A full abstraction layer would alleviate this, particularly if WP10 were to have access to the Play store, as the software houses wouldn't have to do anything at all.
It's a shame these technical hurdles were insurmountable, as I don't see Islandwood as fixing the right problem.
Cliff34 - Friday, February 26, 2016 - link
I sure hope there are good apps being developed for Windows 10. No good apps = the death of mobile market for Microsoft.