Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Android Microsoft Operating Systems Windows

Microsoft's Plan To Port Android Apps To Windows Proves Too Complex (networkworld.com) 131

Posted by timothy from the hard-job-to-do dept.
An anonymous reader writes: The Astoria project at Microsoft has failed because a breakthrough was needed to overcome the complexity of the software development challenge. Microsoft tried to automate mapping the Android UI into the Windows 10 UI and to map Google services within the app such as maps, payments and notifications into Microsoft equivalents. Automated conversion of a UI from one platform to another has never been successfully demonstrated. When I first saw Microsoft's Android bridge at Build 15, I thought it was achievable. But project Astoria, as it is called, is much too complex. Drawing on my architectural knowledge of the underlying Microsoft/Lumia hardware that is very similar to Android phones.I concluded that in the context of partitioning the device or running a VM Microsoft would succeed. But Microsoft tried something much more ambitious. Rather than "failed," The Next Web reports that for now the project may have only been delayed.
This discussion has been archived. No new comments can be posted.

Microsoft's Plan To Port Android Apps To Windows Proves Too Complex More

Microsoft's Plan To Port Android Apps To Windows Proves Too Complex

Comments Filter:

  • TFS is oversensational? Say it ain't so! (Score:4, Funny)

    by halivar ( 535827 ) <bfelger@gmai l . com> on Tuesday November 17, 2015 @12:57PM (#50949263)

    But kudos for pointing it out.

    • Considering pretty much all other news sites are covering the story from the aspect that providing an Android compatibility layer has more legal issues than not (considering the unsure outcome of the Oracle vs Google API case - if MS went ahead with a compat layer and Oracle won then both Oracle and Google could take issue with it) and that providing a compatibility layer cheapens the Universal Windows Platform MS has been touting for WP10, Im not entirely sure where the angle taken in TFS has come from - s

      • Re: (Score:2)

        by Z00L00K ( 682162 )

        At least last time I was looking into the Windows for mobile devices it had severe shortcomings but maybe they have filled in the grand canyon-sized holes in their platform, otherwise they don't have any hope of succeeding.

    • Geez - it's not that hard - just license the Android OS from Google and give it a Windows UI skin!

      ( /me ducks and runs like hell...)

    • Re: (Score:2)

      by Junta ( 36770 )

      To be fair, a company like MS will 'delay' a project a lot before admitting publicly that it's a lost cause...

  • Honestly ... (Score:5, Insightful)

    by gstoddart ( 321705 ) on Tuesday November 17, 2015 @12:59PM (#50949279) Homepage

    Honestly now ... did anybody believe this could be achieved? I'm pretty sure lots of people looked at this and thought "yeah, right, never gonna happen".

    This is why people have been maintaining cross-platform libraries to solve this problem -- because it's a huge and difficult problem.

    Automagically converting apps from Android to use all the Windows stuff? That always sounded like a pipe dream. They'd be better off writing something like a reverse Mime to allow native Android apps to run on Windows.

    I am not in the least shocked Microsoft isn't going to create the magic path to putting Android apps on Windows phones. And, honestly, I'm not sure the Android users ever expected to care about this, this was all about trying to lure people to Microsoft's platform.

    As usual, Microsoft can only see the world through their own lens, and have yet to demonstrate they know what people are actually looking for.

    • "just" an implementation of what Android/Google (Score:4, Insightful)

      by raymorris ( 2726007 ) on Tuesday November 17, 2015 @01:21PM (#50949445) Journal

      The Android API is some thousands of functions. Android and Google already implemented that API on top of Linux . I don't see any fundamental reason that a company with Microsoft's resources -couldn't- implement the same API as follows:

      Android.textbox.Draw(blah, x, y) {
              Winforms.textbox.Draw(x, y, blah);
      }

      Sure there are thousands of functions, but Microsoft can put hundreds or thousands of programmers to it. It's not an easy task, but mostly it seems -big-, lots of functions, not necessarily anything all -that- complicated.

      Looking at it another way, not only did Android and Google implement the Android API, Google also re-implemented the Java API from scratch, while the Mono project and Wine have re-implemented the Microsoft APIs. Given that they've done that, I don't see how it would be impossible for Microsoft re-implement the Android API, mostly with simple stub functions which call the corresponding Windows function.

      • Re:"just" an implementation of what Android/Google (Score:4, Insightful)

        by TheRaven64 ( 641858 ) on Tuesday November 17, 2015 @01:25PM (#50949465) Journal
        It's really easy to reimplement it in that way if you want to - you can reuse all of the AOSP code directly and just plug in your own back ends for OpenGL, Skia, and so on. The problem is that you'll now have an Android app running on a Windows phone, looking and behaving like an Android app. If you've ever tried to use WINE for anything other than games (which try not to use the platform-native UI, as it breaks immersion) on OS X then you'll know how badly that sucks. You won't have an app that integrates nicely with the underlying system services (even things like copy and paste won't work correctly) and you'll have UI patterns that don't quite fit and feel weird and wrong, and a load of frustrated users. Even UI ports where a human is involved are very hard. Automated ones suck - remember Java's AWT?
        • Comment removed based on user account deletion

          • Re: (Score:2)

            by Junta ( 36770 )

            Problem is there's a lot of awkwardness to reconcile. Off the top of my head:
            -Background execution managed by a notification icon
            -Things like accelerometer, magnet, gps, and other sensor data inputs
            -Low level data from the cellular radio

            Now for something like an angry birds, the bar is probably pretty low. If you want to claim support for 'everything', well that's a whole world of possible hurt.

            However supporting the common pieces that a lot stick to because they are already trying to have consistent exp

          • To give a simple example: If you want to share a document between two apps on Windows Phone, then one passes it directly to the other. To do the same on Android, one writes it to the (typically emulated) SD card and now that you've completely bypassed the security model, everything else can open it. It would be easy to designate a directory on Windows Phone that would act as the SD card, but only Android apps would be allowed to use it, you wouldn't have the same user model for document sharing between An

      • Re:"just" an implementation of what Android/Google (Score:5, Informative)

        by beelsebob ( 529313 ) on Tuesday November 17, 2015 @01:29PM (#50949491)

        The Android API is some thousands of functions. Android and Google already implemented that API on top of Linux . I don't see any fundamental reason that a company with Microsoft's resources -couldn't- implement the same API as follows:

        Android.textbox.Draw(blah, x, y) {
                        Winforms.textbox.Draw(x, y, blah);
        }

        Simple... Android.textbox.Draw, and Winforms.textbox.Draw usually don't have the exact same semantics. In fact, usually the APIs are structurally different. Often there simply isn't analagous functionality on one or other platform.

        Furthermore, even if you somehow magically managed to make all of that work out properly, you'd still be stuck with a bunch of functionality that's subtly different. The behaviour of the controls is subtly different, and that can make or break the functionality of an application.

        • Re: (Score:3)

          by DrXym ( 126579 )

          Simple... Android.textbox.Draw, and Winforms.textbox.Draw usually don't have the exact same semantics. In fact, usually the APIs are structurally different. Often there simply isn't analagous functionality on one or other platform.

          The same could be said of lot of emulation / compatibility layers yet they still exist. Apparently the Xbox One supports certain 360 games because they recompiled and linked the executables using a compatibility library - they run natively but think they're running on the 360.

          Likewise wine / winelib allows Windows software to run on Linux or OS X (through commercial forks of Wine). And Wine didn't even have the benefit of being able to look at the Windows source. I actually looked at a Wine implementation

        • Re: (Score:1)

          by Anonymous Coward

          Which is why you dealt with those problems when making the conversion wrappers that handled said calls.
          All they had to do was write something similar to WINE that took every Android call and did it natively.

          It seems they tried to over-analyse things and make it way more complicated than it need be.
          WINE is complex, but it is only complex because there are loads of different calls and specs they need to basically recreate manually.
          It is heavily TIME-based, not complexity based. That is the issue. Microsoft

          • All they had to do was write something similar to WINE that took every Android call and did it natively.

            You realise that Wine is 1.4 million lines of code, and *still* doesn't accurately implement all the windows SDKs, right?

            That's not an "all" you have to do.

        • Android is OSS under a fairly liberal license. You don't need to emulate it completely, you just need to emulate the relatively small number of syscalls/kernel interfaces so that the existing OSS code could run on a Windows kernel and get a graphics context to draw on ... Pretty trivial with OpenGL or DirectX since Microsoft will try to shoe horn that in instead of using the more directly compatible OpenGL layer.

          That's the first month. Now you spend a couple years integrating with your own services instea

      • Except they are trying to implement, emulate whatever the entire damn ecosystem, sounds like, rather than just port an app, or provide a limited technical environment in which it will run...sort of...
        Sounds like just the spot of mega-project that will fail hard.

        Given the amount of cash they're sitting on, would it not be easier to get the "thousands of programmers" the easy way?
        Just contact the dudes that wrote the top 100 (or 200, 300 whatever your budget) apps on android and iOS and given free free dev to

      • I don't want to write a thesis on this, but it's really not that easy. APIs have all sorts of implicit rules that are not obvious at first glance (and undocumented, hence 'implicit'), so even if you write what appears to be a valid drop-in replacement for every individual API function, you may end up with a garbage result. Throw in multi-threaded programming and event-driven GUI programming, and it becomes exponentially more complicated. It's not unusual for a GUI program to rely on a specific order of e
      • It's fine for AOSP where you can see what everything does and wrap that behavior, it's a lot harder when you have programs relying on proprietary libraries like Google Play Services.

    • Re:Honestly ... (Score:4, Interesting)

      by Anonymous Coward on Tuesday November 17, 2015 @01:27PM (#50949483)

      Of course it can be achieved!

      Ever heard of Jolla? They are a small Smartphone manufacturer created by former Nokia employees who were let go when Microsoft bought up the phone activities of Nokia.
      => jolla.com

      Ever heard of sailfish? It is an operating system based on Linux and Qt, with its origins in the next Linux OS developed by Nokia. It was suppose to replace the OS running on the N900 (which used GTK for the UI). That was before that smart guy Stephen Elop became CEO, if you know what I mean...
      => sailfishos.org

      So what, you ask? Jolla runs sailfish and sailfish contains an Android runtime (VM + glue code + libraries).

      In a sense, I just love the irony of the situation!

      • So what, you ask? Jolla runs sailfish and sailfish contains an Android runtime (VM + glue code + libraries).

        In a sense, I just love the irony of the situation!

        Which is essentially what I said: instead of trying to write something which re-maps all of the Android stuff to Windows to try to create a native app ... implement an Android runtime, or a layer like Mime which allows the Android calls to run without caring it's Windows underneath.

        The problem is Microsoft was trying to map it to their own native cal

        • Re: (Score:2)

          by unrtst ( 777550 )

          The problem with what you're saying is that you're blaming the complexity/difficulty and saying it's not possible. That's just plain wrong. It's certainly possible. Is it feasible? Even if it was feasible, if they did it, would it be a good thing?

          I suspect this is pretty much a bait and switch type of situation - lure people along thinking they'll have the entire android ecosystem available, and then just give up on that project as they slowly get the top NNN apps to move over to native apps. They don't wan

    • Very simply, Microsoft has to work on the Universal apps - making as many apps available on Windows 10 Mobile as there are in the mainstream Windows 10 platform.

      Also, Microsoft should identify and work on helping vendors port some major apps in the market - like Uber, Lyft, Vonage, et al to their platform. Do a drive so that most apps that are already there for both iOS and Android are also ported to Windows 10 Mobile. It doesn't have to be most, or even a majority of apps, just the ones that are alread

    • I'm pretty sure they put it on a shelf for now - and that developers can still take a look at it. I don't think open source - but it is still available for people to play with and take a look at it. Gosh - can't remember my source, maybe a recent Dotnetrocks episode?

      Apparently there were parts that they couldn't figure out - and the implementation was becoming ugly.

      Sounds like the approach was never going to work out - so they are taking time to rethink it.

    • Re: (Score:1)

      by narcc ( 412956 )

      Honestly now ... did anybody believe this could be achieved?

      Pretty much everyone believed that. Blackberry users have been running Android apps for ages. They even have Amazon's app store. If a much smaller company can do it, and do it well, there's no reason to believe that Microsoft couldn't.

    • Microsoft's current problem with Windows 10 Phone is that there are few applications. And it doesn't look like there will be many in the future unless Microsoft does something. One reason is the classic chicken-and-egg problem of customers and application: There aren't that many customers so few developers are interested in building applications; there are few applications so few customers are interested. The other is cost. By making it easier to port from Android, Microsoft would like to reduce the cost. I

      • At a binary level, there are plenty of applications for Windows 10 - both native Windows 8/10 apps as well as previous 64-bit Windows 7 apps. So for Windows 10, it's not an issue

        For Mobile, Microsoft needs to come up w/ a strategy so that the killer mobile apps are there. Some are - Fandango, Yelp! and so on. However, a lot of them ain't - Uber, Lyft, Vonage are some apps that could be a make/break decision of whether a phone gets used or not. Microsoft should identify the indispensable apps and do a

        • Not to contradict your point in any way, but Uber has been available on Windows Phone for months, possibly years. Lyft is not, though. It's a WP8 app, but will run fine on W10M.

    • Re: (Score:2)

      by gl4ss ( 559668 )

      some things that might be achievable would be things like the google play services location services and such.

      the payment api services however.. they would need the dev to do so much work they might just as well switch to ms apis anyways for those. they need to set the iap options on ms's servers anyways and switch the server side to do confirmations from ms. this is a task that I cannot see being automated.

      as to mapping the ui libraries? why the fuck. nothing good can come out of that, and with that I mean

  • Port? Really? (Score:3, Funny)

    by Anonymous Coward on Tuesday November 17, 2015 @01:02PM (#50949293)

    I thought all Android apps were just written in Java, you know, that language that is supposed to compile and run on any platform?

    • Re:Port? Really? (Score:5, Funny)

      by oakgrove ( 845019 ) on Tuesday November 17, 2015 @01:09PM (#50949345)

      Your knowledge and experience is truly a credit to the Slashdot community and part of what makes this site so great.

    • Re:Port? Really? (Score:5, Informative)

      by abies ( 607076 ) on Tuesday November 17, 2015 @01:09PM (#50949351)

      I think that you are confused about java-the-language, java-the-standard-library and java-the-platform. Android is java only as far as first one is concerned. And I don't think that this is giving any troubles with possible porting.

      Basic subset of C is quite portable, isn't it? Then according to your logic, game written for Xwindows+opengl should work against MSWindows+DirectX without any issues...

      • Android runs portable byte code unless you're using the NDK. It's not java bytecode. For example one big difference is that it's register based instead of stack based. Arm had a ton of registers. X86 only has a few general purpose ones.

        To get the integration that Microsoft seeks they would have to reimplement a good portion of the runtime, which heavily depends on Linux. For example android has a rather sophisticated IPC mechanism.

        It's unlikely this will get done without QEMU.

        In summary most android apps ar

      • I think that you are confused about a earnest question vs a rhetorical question.

        Seriously though, we software developers should never miss an opportunity to ask "how's that platform-independent Java working out for ya?" so that the business guys remember why they need us.

        It's also not true that platform independence hasn't been achieved. It's just that we call it "open standards". There are many examples, but in terms of a full application stack, HTTP/HTML is probably the best. Sure, it took the w3c and bro

        • Re: (Score:2)

          by bondsbw ( 888959 )

          The only remaining question is why Apple, Google and Microsoft all insisted on making smart phones and tablets entirely new beasts, incompatible with each other and with the modular, cohesive, loosely coupled web-based application stack that is obviously the clear winner for just about everything else (sorry embedded device guys).

          But, Microsoft didn't. UWP/WinRT apps can be built using HTML/JS/CSS. (Or C#/XAML, VB/XAML, C++/XAML, or C++/DirectX if that's what you prefer.) Additional APIs can be accessed for platform and device capabilities like notifications, live tiles, persistence, 3D printing, etc. And you get the same security sandbox guarantees.

        • The only remaining question is why Apple, Google and Microsoft all insisted on making smart phones and tablets entirely new beasts, incompatible with each other and with the modular, cohesive, loosely coupled web-based application stack that is obviously the clear winner for just about everything else (sorry embedded device guys).

          Originally, only Apple could write actual apps for iPhone. The Apple line then was to write web apps that will run on Mobile Safari. After they made such programming available,

    • The good stuff uses native code. There is an NDK = "native development kit"

      I write hybrid apps, using the Rhodes cross-device platform. So, UI is a webview. The platform uses some Java on Android, but mostly C and C++, because it can use the same code used on iOS and Windows CE/Mobile.

      So, Rhodes uses Java on Android where it uses Objective-C on iOS - to interface to native APIs.

    • Why not port the Java Virtual Machine, then using the MS widget set/chrome? E.g. RoboVM [robovm.com] uses this to run Android Apps on IOS.

  • Running android on my phone, I notice that there are a lot of very buggy apps. Even assuming the apps all worked perfectly, I imagine it'd be way hard, but with buggy ones...

  • All they have to do is license GenyMotion.

    It's meant for Android developers, but could work for this with a new skin. It runs X86 Android in VirtualBox So, you build your project for X86. I build for dual X86/ARM and use the same executable on physical devices and GenyMotion.

    I run it on OSX. It really is the only practical solution for Android simulation on desktop. The Google-supplied emulator is dog-slow to the point of total uselessness, and Intel Haxm isn't much better. GenyMotion is a joy.

    Don't work

    • Re:GenyMotion (Score:5, Insightful)

      by fhage ( 596871 ) on Tuesday November 17, 2015 @01:37PM (#50949597)

      All they have to do is license GenyMotion.

      It's meant for Android developers, but could work for this with a new skin. It runs X86 Android in VirtualBox So, you build your project for X86.

      Microsoft would never do this because It's not in their interest to build something which connects a customer to Google's services.

      They want to replace the entire Google cloud services infrastructure with Microsoft services.

      • They want to replace the entire Google cloud services infrastructure with Microsoft services.
        You hit the nail on the head there, and I think that is one of the main reasons for the delay/abandonment of this project. Even if they could get an approximation of Googles services up and running they would probably run into a wall of lawyers, so even if it was technically feasible (albeit extremely complicated) would it be legally feasible?

  • All they have to do is license GenyMotion.

    It's meant for Android developers, but could work for this with a new skin. It runs X86 Android in VirtualBox So, you build your project for X86. I build for dual X86/ARM and use the same executable on physical devices and GenyMotion.

    I run it on OSX. It really is the only practical solution for Android simulation on desktop. The Google-supplied emulator is dog-slow to the point of total uselessness, and Intel Haxm isn't much better. GenyMotion is a joy.

    Don't work

    • Re: (Score:1)

      by jtara ( 133429 )

      OK, /. is totally wacky now. I guess it was /. that made the subject "Score:?" That's what happens when the "professionals" take over!

      • You're blaming slashcode for your double post?

        Ok, fine, that's actually quite credible. But still, a craftsman doesn't blame his tools.

  • Microsoft has an amazing history of backwards compatibility. I mean, the SimCity hack is just my favorite, but they go on and on. If anyone can overcome the delays (not failure) in porting over Android programs, it's Microsoft.

    And that's without taking into account their EEE mehtodology. Excel took off the same way, being 100% compatible with 1-2-3.

    I don't understand why the GUI would even be difficult. There are a finite number of calls. All they have to do is be slavishly followed. If you want to mak

    • > Microsoft has an amazing history of backwards compatibility. I mean, the SimCity hack is just my favorite,

      Ah, you're referring to How Microsoft Lost the API War [joelonsoftware.com]

      I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application rig

    • I don't understand why the GUI would even be difficult. There are a finite number of calls. All they have to do is be slavishly followed

      There may be a finite number of them (vast but still finite), they're sitting in a sea of asynchronous execution while maintaining internal state. If MS don't just clone Android source, manually reproducing all the subtle interactions adds a huge level of complexity to the task.

      Get that all working and you still have to replace the rendering layer or accept the graphics won

  • ARC Welder (Score:3)

    by JigJag ( 2046772 ) on Tuesday November 17, 2015 @01:19PM (#50949427)

    Yes with ARC welder [chrome.com] from Google, I can run Android apps on my Linux machine and possibly others [arstechnica.com].

  • Actually, the original poster is wrong, automated conversation from one platform to another has been done at least one time in the past, check out Project Odin which could on the fly automatically convert a Win32 binary into a native OS/2 binary.

  • Is this not a plan to create a derived work without permission of the copyright holder? Android apps are proprietary, not free software. How did Microsoft think it would get by with this legally?

    Google would enjoy suing MS for a gazillion dollars! It could not happen to a nicer company.

  • This partly demonstrates why "separation of content from presentation" is an overrated concept that often complicates designs by making unnecessary "busy work" layers.

    How features are presented and grouped are largely interrelated to the function of the application itself. On different devices or gizmos one may design or group features entirely different. The UI is not just a "skin", it's an integral part of the overall product. It's what the users and customers see and largely what they judge you on, fair

    • Clarifications and further details:

      Re: "to support and wade through even if you never change UI methods"

      Change: "to support and wade through even if you never change UI frameworks or platforms"

      Re: "For big projects, multiple viewing, searching, and grouping angles becomes more useful."

      Change: "For big projects, multiple viewing, searching, and grouping angles becomes more valuable to help deal with the volume of (UI) code."

      Re: "UI-related code doesn't necessarily have to "run" in the table, for compiled lan

  • Or something like VMWare? Or did they really want the apps to look like native apps? That I'd get. I wish I could run many of my iPad apps on my MacBook...there already is a simulator, so it must be close.

    • It's not a virtual machine, it's a tool that would hypothetically allow developers to compile their native Android code to a Windows app and keep all functionality intact. Basically a super easy way to port their apps to Windows phone.

    • The reality is, they were trying to do FAR more than port apps:

      Microsoft complicated the project by orders of magnitude when it linked the porting of Android apps to Windows 10 with replacing Google's cloud services. Microsoft wrote an app interoperability library that traps and converts Google cloud APIs for things like payments and advertising to Microsoft's APIs. Microsoft's anemic smartphone market share, 2.6% according to IDC, gave the company no choice but to do all the heavy lifting to acquire Androi

  • This reminds me (Score:3)

    by tkrotchko ( 124118 ) on Tuesday November 17, 2015 @01:41PM (#50949631) Homepage

    This reminds me of when IBM had the mistaken notion that if they added Windows 3.x compatibility to OS/2 they'd be the platform of choice.

    You'd think Microsoft of all companies would remember that logical fallacy of that plan.

    • Loosing... an arrow? Loosing the dogs of war? "Loosing" as in releasing, a reference to the way Windows 10 Mobile is being released imminently?

  • Blackberry did it (Score:3, Insightful)

    by Ed Tice ( 3732157 ) on Tuesday November 17, 2015 @03:00PM (#50950239)
    BB10 QNX phones run Android apps just about as well as they run natively from what I can tell.

    • Yeah. Good phone. Poor marketing. Few will listen. One must have the Correct Brand(tm) else one will not be deemed a valid hipster.

      • Forget being deemed a hipster, companies like Mobile Iron have sold their crap to large organizations. And now if you don't have iOS or Android, the mail server won't let you sync!

  • There is no such thing as too complex especially when you have the resources of Microsoft. All you have to do is to emulate the Android API at a high level. The only problems are those application that have native Linux binary code.

  • Their existing developers were none too happy about all the time they spent on native apps being made worthless under a deluge of quick and dirty ports.

  • Automated conversion of a UI from one platform to another has never been successfully demonstrated.

    Isn't this the definition of an emulator?

    • Emulators are run-time, this is compile-time. The closest thing I'm aware of it WineLib, which lets people compile Win32 code for Linux or OS X, and takes care of stuff like translating DirectX calls to OpenGL ones. It's reasonably "successful" in terms of usage, but far from complete or bug-free. A lot of apps just won't work through it, and many others will exhibit new and exciting bugs.

      • These days, all libraries are bound at run-time. That's true for .NET, Android SDK, even Win32. You can write your own version of Shell32.dll, drop it in place, and as long as you implemented all of the entry points, your application would never know what happens on the back end.

        Maybe an emulator is "thicker" than a bridge, a little less seamlessly part of the host OS, but it certainly does convert (or implement) the entire UI of the client to the host platform. The emulator has to implement every single

Slashdot Top Deals

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Close