Android Apps will ONLY run on ARM-based systems


Recommended Posts

The issue is that some (not all) Android apps and games ARE coded specifically to use ARM.  Worse, there has been a deliberate attempt by ARM evangelist Peter Watt to encourage the practice.

 

The very reason that Watt encourages this is to keep Intel from becoming a factor when it comes to Android.

 

However, whenever I spot such software, I look for alternatives I can recommend instead, as I find such deliberate "CPU tying" fitting Google's definition of "evil".

 

If an Android app or game won't run on BlueStacks, for example, I won't recommend it - period.  (BlueStacks is my Android emulator of choice, because it simply works, and with a minimum of muss or fuss, on almost any PC running Windows 7 or later - this includes 10.)

  • Like 2
Link to comment
Share on other sites

They specifically mentioned that android apps will work only on phones.

Then there's absolutely no reason to port them in the first place. At least with the desktop you could make a case (however questionable) that Microsoft has a big existing market. Without that, I don't see how anything has changed. WP is still at 3%, and Android apps won't run without modification. I don't see many takers.
Link to comment
Share on other sites

Then there's absolutely no reason to port them in the first place. At least with the desktop you could make a case (however questionable) that Microsoft has a big existing market. Without that, I don't see how anything has changed. WP is still at 3%, and Android apps won't run without modification. I don't see many takers.

Well, the reasoning is sound because no one wants to use phone apps on a PC.

I wouldn't get into arguing market share numbers in this thread because this is not the thread meant for it.

Link to comment
Share on other sites

Then there's absolutely no reason to port them in the first place. At least with the desktop you could make a case (however questionable) that Microsoft has a big existing market. Without that, I don't see how anything has changed. WP is still at 3%, and Android apps won't run without modification. I don't see many takers.

It makes perfect sense. How do you cure the app gapp when your market share is tiny? Use other platform's apps.

 

Every developer I work with saw that writing on the wall immediately.

 

Android apps would blow on the desktop.

Link to comment
Share on other sites

Surely ARM commands can be emulated on x86 CPUs without a big performance hit (if any)?

Ever used the Android emulator? Its miserable.

  • Like 2
Link to comment
Share on other sites

Surely ARM commands can be emulated on x86 CPUs without a big performance hit (if any)?

GBA, NDS emulator just did that, but NDS emulator tend to choose dynarec path of better performance.

Link to comment
Share on other sites

Surely ARM commands can be emulated on x86 CPUs without a big performance hit (if any)?

 

That's what Intel does on Android to support apps that don't natively support x86, the performance hit is tangible but not huge. But Intel can write their own emulator specifically optimized for Android and the peculiarities of each and every individual processor they support on Android. Intel knows their own processor architecture much better then Microsoft, and have undoubtedly have years of experience studying typical Android code though. Even then Intel's emulator doesn't have perfect compatibility.

Microsoft probably hasn't devoted anywhere close to the same amount of time on it and would be forced to write a single emulator that would cover all use cases on all available x86 hardware... and as we've seen with Google's own x86/ARM emulator, that's no easy job as it's close to 2.5x slower then Intel's emulator with far greater power consumption as well. And that's running directly on Android without having to worry about the additional overhead of running Windows itself as well.

it's just not practical even if they could somehow convince Intel and AMD to dedicate significant time and effort into hand tuning the emulator for each and every one of their architectures.

Link to comment
Share on other sites

Most Android apps are written in Java and interpreted by the Android Runtime (previously Dalvic Virtual Machine). So they can run on x86 or ARM just fine unless they are native apps.

Link to comment
Share on other sites

Then there's absolutely no reason to port them in the first place. At least with the desktop you could make a case (however questionable) that Microsoft has a big existing market. Without that, I don't see how anything has changed. WP is still at 3%, and Android apps won't run without modification. I don't see many takers.

That is ALSO false.  Mom has a ton of apps that are cross-compatible, and she has both an Android smartphone and an Android tablet - most of those SAME apps also work in BlueStacks; and all her GAMES do.  Coding to specific hardware will get such an app bounced from Google Play, in fact - which is why OEM-specific apps aren't found there.  As much as Peter Watt would love for otherwise to be the case, why would a developer deliberately "step on the crank with the golf shoes" and write ARM-specific code needlessly?

 

Peter Watt's problem is that ARM has no fabs itself - it depends on licensees.  Intel, on the other hand, IS "Chipzilla"; because x86 is ALSO supported by Android, how much effort does it take for developers to write x86-specific code if they absolutely had to?  (Worse, all developers have to do is change targets - x86 is a valid target in the Android SDK, and has been for years.  That means you don't even need to change development tools.)

 

ARM needs Android to become either semi-exclusive OR exclusive - however, Google does not need ARM THAT badly to risk doing "evil" by their own definition; in fact, Google only "needs" ARM if it wants to continue to have a backdoor in case it needs to escape Microsoft.

 

AMD, on the other hand, is in an interesting position.  (Remember, AMD IS an ARM licensee, and their existing CPUs are getting mauled rather badly by Intel.)  Does AMD want to risk Intel REALLY declaring business on it by dropping x86?

Link to comment
Share on other sites

That's what Intel does on Android to support apps that don't natively support x86, the performance hit is tangible but not huge. But Intel can write their own emulator specifically optimized for Android and the peculiarities of each and every individual processor they support on Android. Intel knows their own processor architecture much better then Microsoft, and have undoubtedly have years of experience studying typical Android code though. Even then Intel's emulator doesn't have perfect compatibility.

Microsoft probably hasn't devoted anywhere close to the same amount of time on it and would be forced to write a single emulator that would cover all use cases on all available x86 hardware... and as we've seen with Google's own x86/ARM emulator, that's no easy job as it's close to 2.5x slower then Intel's emulator with far greater power consumption as well. And that's running directly on Android without having to worry about the additional overhead of running Windows itself as well.

it's just not practical even if they could somehow convince Intel and AMD to dedicate significant time and effort into hand tuning the emulator for each and every one of their architectures.

No - the performance hit is not that hard - even all the way back to Core 2, and it's less going forward.  (BlueStacks, my own emulator of choice, is plenty of evidence and hard data in and of itself - it will even run - albeit with a greater performance penalty - on Big Pavilion, my AMD Turion x64 widescreen notebook that dates back to Vista.)  Microsoft's emulator requires Hyper-V - however, that requirement in and of itself obviates the need for HAXM - which IS required to get decent performance out of the Google ARM Translator in the Android SDK.  (While HAXM is Intel-specific, Hyper-V isn't - consider that Turion II supports Hyper-V, for example.  While Turion II would not be suitable for large-application development, you don't need all that horsepower for MOBILE development - not Android OR even Windows 10 for phones.)  That is why Baby Pavilion won't be used for desktop-application development whatever - not enough horsepower for that.  However, it IS suitable for mobile software development - the fact that the platform is mobile itself means that it is second only to having actual Android hardware (or Windows 10 for phones hardware) to test apps on.

 

And the cost of software development for Android AND Windows - including Windows 10 for phones - is now zero.  Visual Studio 2015 Community - now in Release Candidate form - is all a developer needs, and it is available today. (And yes - it includes all three SDKs.)

Link to comment
Share on other sites

Well, the reasoning is sound because no one wants to use phone apps on a PC.

I wouldn't get into arguing market share numbers in this thread because this is not the thread meant for it.

That's funny - explain all the Android emulators, then - not JUST BlueStacks.  The attraction there is that there are Android apps that exist nowhere else - including Windows desktop, let alone ModernUI or Windows Phone, let alone Windows 10 for phones.  (That is especially true of games - more so than even apps; how many GAMES are specific to mobile platforms - let alone specific to Android?)

 

Also, how many Android or mobile developers don't do non-mobile development?  (There are MANY reasons why such developers stick to mobile - including an aversion to desktop development as a whole.)

 

You are letting your user-bias cloud your thinking - that comment dismissing mobile apps as "phone apps" gives the bias away.  Mobile developers can't think that way - not with mobile as a platform; if anything, their bias is, more often than not, decidedly AWAY from desktop development - for any platform.

Link to comment
Share on other sites

That's funny - explain all the Android emulators, then - not JUST BlueStacks.  The attraction there is that there are Android apps that exist nowhere else - including Windows desktop, let alone ModernUI or Windows Phone, let alone Windows 10 for phones.  (That is especially true of games - more so than even apps; how many GAMES are specific to mobile platforms - let alone specific to Android?)

 

Also, how many Android or mobile developers don't do non-mobile development?  (There are MANY reasons why such developers stick to mobile - including an aversion to desktop development as a whole.)

 

You are letting your user-bias cloud your thinking - that comment dismissing mobile apps as "phone apps" gives the bias away.  Mobile developers can't think that way - not with mobile as a platform; if anything, their bias is, more often than not, decidedly AWAY from desktop development - for any platform.

Uh...I specifically said phone apps and not mobile apps. I wouldn't mind tablet apps but how many good Android tablets are out there?
Link to comment
Share on other sites

Well they did mention it was for phones, and it was a presentation about phones.

 

No biggy really, there'll be an emulator at some point. The whole presentation was about how people can port Android and iOS apps to be used on the Windows system, not how they could be emulated there.

  • Like 1
Link to comment
Share on other sites

It's a shame, but it was to be expected. It still allows easier code transfer to the Windows ecosystem, which is what it was all about.

Link to comment
Share on other sites

After you easily port the app to Windows, be it phone only at first, then tweaking it to be a better universal app would be the next step, that gets you bigger tablets and the desktop.

 

You'd have to redo the UI for a bigger screen anyways, phone apps on my desktop sound nice but they need a UI to match the environment.  If you give me a phone UI on my monitor then you're not putting the work into it at all.

Link to comment
Share on other sites

After you easily port the app to Windows, be it phone only at first, then tweaking it to be a better universal app would be the next step, that gets you bigger tablets and the desktop.

 

You'd have to redo the UI for a bigger screen anyways, phone apps on my desktop sound nice but they need a UI to match the environment.  If you give me a phone UI on my monitor then you're not putting the work into it at all.

However, how MUCH work is it in reality in terms of the UI (I'm talking not just Android to Windows 10 for phones, but even Android to ModernUI)?

 

Developers who have actually done the work (in either case - let alone both cases) aren't talking.

 

Also, what are developers that refuse to do the work aren't saying?  Have they even tried?

 

Lastly, there has never been a single toolset that reaches both mobile AND desktop before VS 2013 came along - could part of the reason be because the tools weren't there? (It's a VERY fair question - VS 2013 Community isn't even a year old - and the successor is already a Release Candidate; and until VS (of any sort) came along, development merely for Android and Windows Phone required different tools - not just different SDKs.  Now, with VS Community, you have one IDE, and all three SDKs - Android, Windows for phones, and Windows 8+ - all for a cost of none.  Want to add Windows desktop (either Win32 or Win64) to the mix?  There is - literally - no extra cost; the SDK is - like the other three - a no-cost option.)

 

THAT is why VS Community really IS a game-changer - there hasn't been a toolset with this sort of range available at all - let alone at a cost of none.  Unless you are philosophically averse to either Windows OR Microsoft development tools, why aren't you at least considering it?

Link to comment
Share on other sites

Ars Technica's Peter Bright has written an (IMHO) excellent article explaining the Android (and native) application development model for Windows 10.

http://http//arstechnica.com/information-technology/2015/05/android-and-ios-apps-on-windows-what-is-microsoft-doing-and-will-it-work/''>Android and iOS apps on Windows: What is Microsoft doing

  • Like 1
Link to comment
Share on other sites

People who are native Windows developers don't need to worry about these two porting objects, seriously the goal here is to easily help devs bring their Android and iOS apps over, taking away the first issue which is development time and cost of doing a full port to a new platform.   With those reduced, in some cases completely, they can bring apps over and if, like King with Candy Crush, see success, they can then make it native.

 

It's all about getting the apps in, then if they see success the incentive to make a full native Windows app is there.

Link to comment
Share on other sites

I don't think this matters much. It's not the case that Android has a lot of tablet optimized apps anyway.

 

What is more important is that iOS apps can be converted into Universal Apps.

Link to comment
Share on other sites

People who are native Windows developers don't need to worry about these two porting objects, seriously the goal here is to easily help devs bring their Android and iOS apps over, taking away the first issue which is development time and cost of doing a full port to a new platform.   With those reduced, in some cases completely, they can bring apps over and if, like King with Candy Crush, see success, they can then make it native.

 

It's all about getting the apps in, then if they see success the incentive to make a full native Windows app is there.

Exactly.  And the entire set of options will be a part of the zero-cost VS 2015 Community (now in Release Candidate stage).  The cost of the tools (except Xamarin on the iOS side) will be zero completely.  And if you already have a Xamarin subscription, the cost atop of that will STILL be zero extra.  And I haven't heard about a developer yet that would turn down additional revenue - especially additional revenue earned at no additional cost to the developer.  (Additional revenue - and especially at no cost to the developer - can overcome all but the most philosophical aversions on the part of a developer.)

Link to comment
Share on other sites

This topic is now closed to further replies.