AMD deal brings Android apps to Windows 8 | Hacker News Reader

AMD deal brings Android apps to Windows 8

bbc.co.uk

37 pointsHarveyKandola23 comments

I downloaded and installed the application yesterday and got caught playing some silly tower defense game for an hour when I should have been working.

From the time I was playing around with it, it seems to work really well. I didn't notice any weirdness with the applications. They provide their own "store", so my guess is that they've vetted certain apps to make sure they work properly.

Once thing that I did notice is that the application is using the default program icon from Visual Studio (the one with the three colored boxes). All that work and they can't put in their own application icon?

What all these announcements forget to mention, is that they only work with DalvikVM pure applications.

NDK based applicatons need to be recompiled, as any native code language making use of it. So forget about most games.

I think games are pretty much covered on a Windows machine.

The point wasn't about games in general, rather about ports of Android games.

They don't mention it because they do handle NDK games.

How do you know that?

How are they handling NDK games that were only compiled for ARM cpus?

Do they JIT translate assembly code, like Sun used to do in the 90's in their SPARC stations?

If AMD is optimizing their processors for the purpose, they could well put a full ARM core (since they don't take up much die area), or just add specialized instructions to make it easier to translate ARM assembly.

It seems like they are adding an ARM A5 core to some chips. This article speculates it's just for security, but it's a few months old: http://semiaccurate.com/2012/06/13/amd-puts-arm-cortex-a5-co...

The very first releases of the NDK only supported ARMv6, but now it also supports ARMv7, x86, and MIPS. I actually compile my code for all 4 architectures, and end up with .so binaries in my APK:

lib/armeabi/libpuddle_drops.so

lib/armeabi-v7a/libpuddle_drops.so

lib/mips/libpuddle_drops.so

lib/x86/libpuddle_drops.so

This really takes no effort on my part, except to specify APP_ABI := all in one of the build files.

The system where the app is installed picks the preferred (or compatible) library automatically, which usually means ARMv7 with a fall-back to ARMv6 on low-end phones.

Yes, same with my NDK based apps though in my case I have only compiled for x86 and ARMv7-A. About MIPS, is there any MIPS based hardware with Play store access out there that we need to worry about?

Btw you may want to know that there is a bug in 4.0.3 that sometimes loads armeabi code instead of armv7-a code on some ARMv7 systems like HTC One S.

I haven't seen any MIPS-based devices yet, but I also added x86 support before I saw any evidence that it was needed at the time. I try to make the app as widely compatible as possible without creating undue work for myself.

I did not know about that bug, but thanks for telling me! I have had a few reports of the app running slowly on the One S, which didn't make sense at the time. I'm not sure if only supplying the ARMv7 code would cause the device to pick the correct library, or just exclude a lot of (half decent) ARMv6 devices I'd still like to support for now.

This requires effort on your part, specially if you happen to take advantage of CPU specific opcodes like NEON.

If you happen to compile just for ARM, then it won't with AMD CPU out of the box.

This is what I mean, when journalists talk about technology without explaining how compatible is AMDs solution with Android apps.

Well, I have to say that a lot of work goes into explicitly taking advantage of NEON, and even Google states in their docs that you must check at runtime whether NEON is supported (and not just ARMv7). So if you're using NEON, you're already spending effort, and should be aware that you will need to support different architectures (even if only ARM variants).

All things considered, the NDK offers a lot of cross-platform interoperability for very little effort. Recompiling really isn't the issue, unless you live in 1995 and you're still hoping Java will save the world.

Also, many apps don't need any native libraries at all. AMD will be able to support a large portion of Android apps without doing any binary translation, and can use the same market filtering mechanism that Google uses to avoid apps that would require an ARM architecture.

No, I live in a world where Java and .NET are kings of the hill. The consulting world of Fortune 500 corporate development.

But I do Android development on the side for friends, mostly NDK based games.

So I am well aware how the NDK works.

Again, the way these things get announced in the press trick the normal joe six-pack to think he will have access to all apps, when it will depend on how the app was developed.

I believe they use binary translation for NDK-based applications, though I may be wrong.

Why do all these articles only mention Windows 8? I believe AMD said it works on Windows 7, too. Does it make the headline more compelling if it just says Windows 8?

Also, I imagine that if this is happening, most developers who already have an Android app won't bother to create a Windows 8 one, too.

Most Windows 8 devices will have Intel, not AMD chips. Another chunk will ship with ARM, also not AMD. I seriously doubt that this will have any significant effect on Windows 8 app development (unless Intel also gets on board with this).

As for why they mention Windows 8, that's because so few people have touchscreens for their a Windows 7 devices. Fruit Ninja with a mouse is probably not too fun.

I never found BlueStacks very compelling on my desktop or laptop. Tablets or NetBooks might make it more than a fun tech demo, though. Windows 8 is trying to cover more of those, especially the WinRT version.

Would the apps be able to run as background processes? It's a really good move by AMD. One that RIM probably should have at least considered (I couldn't resist bringing them up)

As far as I'm aware BB10 is compatible with a large subset of Android applications.

This is somewhat true. An Android app won't install and run on BB10 but developers can repackage an Android app fairly easily and offer it in the BB store.

RIM tried to let Android apps run on BB. They had a lot of restrictions though, and I think the project ended up a flop. Not sure, though, is it still active? They had a lot a restrictions on which apps could be run, which Android features could be used, etc, IIRC.

Is the implication that Bluestack won't work on Intel chips, if only at a lesser efficiency?

It looks like AMD is just putting a pretty wrapper around Bluestacks and shipping that. The wrapper is possibly going to be limited to AMD / Win8 systems, but Bluestacks certainly isn't.

Reply on news.ycombinator.com