ANDROID: Missing Game Options only for ARMV7

[RogerW123]

Using the ARMv7 APK of the 2.9.0 release I've found that all the SCI specific game setting are missing. For example...When adding any of the SCI 16 color text based games such as Kings Quest IV, Space Quest III, Police Quest II, Quest for Glory II or the 256 Color games such as Kings Quest V, Space Quest IV, Police Quest III, Quest for Glory III, There should be game specific options like "Use RGB Rendering", "Enable Text to Speach" or "Use original Save/Load Screens". These option are all missing with a clean install.

If upgrading from 2.8.1 to 2.9.0 the options show up if the game was already added, but if any of the optoins are changed, then they all dissapear.

I tested this on 5 different devices all with the same results.

Only tested one device with the ARMv8 APK and it worked fine. No issues at all.

[antoniou79]

Hello, and thank you for submitting the report.

I am seeing this issue when testing with the v7a package for 2.9.0 (and 2.10.0git development build) in more games than just SCI games.

It's also present for AGI games (eg. KQ2), Blade Runner, Little Big Adventure (Twine engine), Ultima 8, and a few SCUMM games too (eg. Secret of the Monkey Island DOS EGA).

The issue is indeed not present in our v8a packages, and also as far as I can tell it's not present on Windows (even the 32bit builds).

I've done some investigating and I've found a potential issue that may be causing this in the getGameGUIOptionsDescription() method of common/gui_options.cpp:
​https://github.com/scummvm/scummvm/blob/5fdc6b67e9b28485e442b19b42428be75d1f0ea6/common/gui_options.cpp#L173

line:
​https://github.com/scummvm/scummvm/blob/5fdc6b67e9b28485e442b19b42428be75d1f0ea6/common/gui_options.cpp#L177

I have a tentative fix that seems to be working, but since this is common code I need to better understand why this does not work in v7a but works with all other builds and if my fix is indeed the correct one.

[antoniou79]

The above code ultimately calls this line:
​https://github.com/scummvm/scummvm/blob/4c3db038488e717268298eab88dd1811c91515b8/common/str-base.cpp#L1147

It seems that the implementation of the memchr() method for armeabi-v7a is not doing well when searching for (signed) char values which are "negative", ie. larger than 127.

A tentative fix that works is to change the above line (and probably the similar line in the previous method as well) to:

return static_cast<char *>(memchr(ptr, 0xff & c, count));

However, we have many other (direct) calls to memchr() in our codebase which may also get the bug but won't get the fix, and also I am unsure that the fix is portable/future proof.

So, I am not sure how to proceed with this.

[lephilousophe]

This should be fixed by PR ​#6402.
Thanks for the investigation.

[lephilousophe]

RogerW123, can you tell us the Android version of the devices where you experienced the bug?

[RogerW123]

Here is a list of the devices I tested the current 2.9.0 ARMv7a APK with...
Samsung Galaxy S2 - Android 4.1.2
Samsung Galaxy S5 - Android 4.4.4
Samsung Galaxy S5 - Android 5.0
Samsung Galaxy S5 - Android 6.0.1
Samsung Galaxy Note Edge - Android 5.0.1
Samsung Galaxy Sol - Android 6.0.1
Samsung Galaxy Tab 7 - Android 4.4.4
LG G3 - Android 5.0.1
LG LGL34 - Android 4.4
ZTE N9130 - Android 4.4.4

[lephilousophe]

Thank you.
The fixed has landed in the latest daily builds (master and 2.9.x).
You can find them at ​https://buildbot.scummvm.org/#/dailybuilds

I am a bit puzzled by your two Android 6.0.1 phones which should not have been impacted because the Bionic libc is supposed to be fixed.
If you want to make some tests to make sure the fix is good, these platforms could be first candidates.

[RogerW123]

You are 100% correct. The two 6.0.1 devices do indeed work properly.

Will the daily build with the fix overwrite the official 2.9.0 relase or will they co-exist? Will it cause trouble in the future when updating to any official future relase?

Does the issue only affect Android 4 and 5? To the best of my knowledge ScummVM doesn't work on anything below Android 4. But the oldest version of 4 I have to test with is the the Galaxy S2 with Android 4.1.2. Would ScummVM technically work with an Android 4.0 device?

I tested the 2.9.0 relase on an HTC Evo 4G. A device that officially only supports up to Android 2.3 but I have installed a 3rd party Android 4.4.4 OS in it and it works. I'm super impressed that it runs on such an older single core Android phone and so well. Thank you for all the work on this port

[antoniou79]

Replying to RogerW123:

Will the daily build with the fix overwrite the official 2.9.0 relase or will they co-exist? Will it cause trouble in the future when updating to any official future relase?

Since about ScummVM 2.8.1.1 (or maybe a bit earlier), ScummVM daily builds (now named "ScummVM debug") and ScummVM stable release builds use a different application id, so one will not overwrite the other on the same device and they can co-exist. They have their own congifuration file and will not share the added games list (you'll have to add games to each app separately).

Just to be safe, I would recommend that, at least for the saved games folder, you either leave the default setting (which is using each ScummVM app's storage space) or you set different external folders for them, since on some occasions developer builds may introduce incompatibilities in the saved game format with the format used by the last stable release and it could get messy having both saved game formats in the same folder.

Does the issue only affect Android 4 and 5? To the best of my knowledge ScummVM doesn't work on anything below Android 4. But the oldest version of 4 I have to test with is the the Galaxy S2 with Android 4.1.2. Would ScummVM technically work with an Android 4.0 device?

I don't think it would work. Our minimum SDK API setting is at 16 which corresponds to Android 4.1. So it makes sense to test on Android 4.1 and above. Personally, I can only easily test on Android 4.4.4 (unless I unearth some really old device from my storage that I am not quite sure if it would be functioning at this point).