Doesn't work on non-arm devices

[paladine]

The words binary is arm only, meaning it doesn't work on x86 or other CPU architecture devices. x86 is probably the most useful, as most people use x86 emulators on their x86 development machines.

I imagine the work consists of building an x86 binary, and checking the CPU architecture to determine which binary to invoke.

[paladine]

Feel free to assign me - I'm planning on working on it

[ids1024]

I've considered this. However, there is a problem: the binary data files are architecture specific (or so I've read; I'm not sure if I've tested it myself). I opened mk270/whitakers-words#68 in relation to this.

Solutions:

• Separate apks per architecture. I'm not sure if this is possible (particularly since Android's build system doesn't work with Ada natively).
• Package the text-based files and the executables that build the binary format, and generate on the device.
• Submit patches the the Words fork I linked to above using a different format (plain text or sql). This is probably the best solution, but the most difficult.

This is not a huge priority, since nearly all Android devices are ARM based. It is perhaps more useful now, though, with Chrombooks now (or soon? I don't have one) supporting Android apps from Google Play.

[paladine]

It should be easy enough to package x86 + matching binary files in addition to arm + matching binary files. The copyFiles routine would only copy the folder that matches the CPU target.

Though before this - I'm going to try to spend a bit of time to see if I can bundle words into the APK itself as a JNI library. I'll have to make some C/ada bindings, and it might fail miserably, but I think I'll give it a go.

[ids1024]

Calling words as a library would also be a good improvement, but is not easy. I think you would need to either hack Ada's IO to write to some string instead of stdout, or you would need a substantially refactored version of words that is callable as a library. The fork of words at mk270/whitakers-words aims to make it callable as a library, but it still seems to be a little ways away from working as such.

Although, if I'm missing something and you can get it to work, feel free to implement it.

[ids1024]

I've been working on this app recently, and got it to build with a proper toolchain targeting Android. Earlier, it was using an arm binary statically linked against glibc.

I do think a split APK is the best way to do this. According to the NDK documentation, r17 of the NDK removed MIPS support (which very few devices were using). So the only architecture to support other than ARM is x86. I suppose ideally there should be separate binaries for 32 vs 64 bit on both as well.

[ids1024]

Ugh: https://stackoverflow.com/questions/30498776/position-independent-executables-and-android-lollipop

PIE executables don't run on Android 4.0 and earlier. Non-PIE executables don't run in android 5.0 or later. A statically linked binary will work in either.

So I may stick with static linking. But the words binary in the current release actually was failing in the emulator for 4.0 since the static glibc it was using required a later kernel. So this is a bit of an improvement anyway.