Quote:
Originally Posted by New Thought View Post
Could somebody explain why Magic Code is necessary, please?

My understanding is that Android applications are compiled to bytecode, which is then run on the Dalvik VM. If there is a VM available for the MIPS processor, then I would expect most applications could run on a computer with a MIPS processor. I would expect it to be like Java - where most applications will run on any computer under any OS, as long as a VM is available.
It *is* like Java. And like in Java, there is support for native interface (JNI). The native interface allows a developer to intermingle the "main" java development with bits written in device-specific code. While the java code is compiled into bytecode and then interpreted (and therefore portable to all architectures featuring a compatible interpreter), the native code isn't, and will run only on the targeted device.

The use of JNI is not unheard of in the "desktop" java development world, but it is relatively more common in embedded device, perhaps because of the higher performance achievable this way in embedded devices. In the desktop world it's mainly used in order to incorporate legacy or proprietary libraries.

The android framework features an "ndk", a "native development kit" to embed native code in the application. IMO this practice should have been discouraged in order to benefit portability, but as most of the devices feature the same architecture (or compatible), there wasn't much concern in producing architecture-specific software. If you download an .apk and unpack it, chances are you'll find a 'lib' folder, holding .so files (compiled natively for an architecture). For example, the AdobeReader apk includes among the rest:

-- a classes.dex file, the Dalvik bytecode
-- a lib/armeabi/libAdobeReader.so file, an arm-compiled library used by the application.

If you "readelf -A lib/armeabi/libAdobeReader.so" you get:

Attribute Section: aeabi
File Attributes
Tag_CPU_name: "5TE"
Tag_CPU_arch: v5TE
Tag_ARM_ISA_use: Yes
...

etc. This file is compiled for armv5.

Another example are those video players (e.g. mx video player) that have you download, after the main application, a deveice-specific codec library. That's because, for efficiency, the codec library was compiled and optimized specifically for the various devices (in the case of mx video, the various classes of arm processors from v5 to v7 or whatever).

In a nutshell, it is perfectly possible to write portable apps for Android when sticking to the standard sdk, but for various reasons many developers don't, and include architecture-specific code in the app which, in the case of mips, means that the application is unlikely to run. Most of the times, all it would take is for the developers to include mips-targeted binaries, which wouldn't be too difficult for them given that a mips ndk is available, hence the "crusade" to make developers aware that there's an alternative to arm.

In the meantime, magiccode does a good job at "interpreting" those .so... I'm not sure how it does it, or how good and "complete" we can hope for it to get, but it is the case that many apps, that way, work.