Talk:Specific android device testing

Non-ARM Android devices

I looked into the market share of non-ARM Android devices and couldn't find good data, but apparently Intel Atom CPUs are used almost exclusively in tablets rather than smartphones, and 40 million Atom Android tablets were sold in 2014, out of a projected 220 million total Android tablets. So that's a large fraction. I think CPU architectures aside from ARM and Intel are very rare.

However, what I did not know is that on Atom devices, apps containing code compiled only for ARM are translated to x86 code. This translator is called Houdini. (AFAIK it's exclusive to x86 Android). It doesn't work for quite a few apps, and the result is slow, but it seems it's the norm that people use the NDK and don't provide x86 builds. Here's an interesting pie chart. We don't care about performance too much, since those Atom tablets aren't the slowest anyway, so the question is just whether Houdini works for us.

It would be easy to modify the sdl-android build script to build for any other architecture. I'm confident that x86 builds they will work out of box. I think it unlikely that ARM64 would work, and there's no need because ARM64 CPUs support the 32 bit instruction set as well.

I don't know how to include binaries (.so files) for multiple architectures in the .apk. Since it would bloat the size a bit, it would be more efficient to use Google Play's ability to serve different .apks to different phones... except that I saw someone say (a year or two ago) that that wasn't possible. --TMC (talk) 00:40, 5 January 2016 (PST)

Ah! That explains a lot! So I realized that the NuVision tablet I tested yesterday is actually an Intel Atom tablet, running a ia64 x86_64 Android kernel, and the ohrrpgce seemed to be working perfectly on it. -- Bob the Hamster (talk) 07:53, 5 January 2016 (PST)

Good to hear!

BTW, x86_64 is also known as AMD64 (because AMD created it), while IA-64 is completely different: it's Intel's pretty-much dead Itanium architecture, which isn't x86 compatible. IA-32 on the other hand, 'Intel Architecture, 32-bit', is the x86 aka i386. --TMC (talk) 18:37, 7 January 2016 (PST)

Have you heard of the Samsung Remote Test Lab? You cam remotely test apps on a range of real devices. There's no charge, free to register, and if I read it right, you get 5 hours of testing per day. I've just registered and will try it out next time I touch the Android port. My own Android phone no longer accepts micro sd cards, which makes it hard to install anything.

Also, I've realised that if we use LuaJIT, the ARM-to-x86 translation definitely will not work with the JIT enabled I wouldn't be too surprised if it doesn't run even with JIT disabled, but I can't any information about that. Otherwise, we could hopefully detect whether the CPU is a not an ARM and if so disable the JIT. I also wonder whether it's possible to include both x86 and ARM builds of libluajit2.so in the .apk, without including x86 builds of the rest of the engine and SDL, which would add an extra ~3MB. Houdini would have to handle changes in CPU architecture when calling between different .so files anyway, when calling into standard libraries, and the dynamic linker should select the most appropriate .so file, so I suspect it would work. --TMC (talk) 19:37, 11 January 2016 (PST)

Sweet! I just tried it out, and the Samsung remote test lab works great for me. It was indeed free, and seems to work well. I couldn't tell if any of the available devices had x86_64 processors... it kinda seemed like Samsung doesn't use those. I tested four devices. OHR worked great on 3 of them, but the very oldest one in the lab (Galaxy S II) had some issues -- Bob the Hamster (talk) 08:24, 12 January 2016 (PST)

Slow script interpreter

I tried playing Paladin Traducer on my netbook, which has an atom N455 CPU (turns out I only had FB 0.21 on it, yikes). Comparing the N455 and Z2580 I see the N455 is only single instead of dual core (which makes no difference), about a third slower per-core, but supports x86_64 (which I don't use and again makes no difference). Well for a start it took 4 minutes to compile :P

First I tried compiling with debug=0. I noticed no pauses at all, and the FPS, which would dip every time you made a move, never dipped below 25 from its usual 32.2. That corresponds to a maximum pause (if it happened all at once) of about 230ms. The script interpreter doesn't become interruptable until it's run for 1.1 seconds (and only when a user does something - which is good, I guess that shows the touchscreen to interrupt is working).

Then I tried with the default debug=2. The game was pretty slow; even when doing nothing it only ran at 25 FPS, making a move makes it dip below 10 FPS for a moment, and I saw it read as low as 2 FPS.

So I wonder, do we compile Android builds with debug=0? But it could just be that the ARM-to-x86 translation produces code that is that much slower, especially if this only happens on Atom devices.

I always expected that script-heavy games would not really work with our current script interpreter. Thank goodness I have a solution to that.

--- When I compile for android, I do it like this:

 scons fbc=$FBCARM android-source=1 game

So I will try again using debug=0 and rebuilt Paladin Traducer, and see if I can get AloneKeybi to re-test. -- Bob the Hamster (talk) 07:22, 19 January 2016 (PST)