I installed the Android RC2 version on my ZTE Axon running Android 5.1.1.

Opening the "Just for testing..." level set, I click on the level number. This brings up the menu of level names, but it only displays for an instant before "Unfortunately, Rocks 'n' Diamonds has stopped."

(It takes ~10 seconds to compute the menu. Even on desktop it takes what feels like a long time -- only ~1.5 seconds of realtime, but that feels like a long time to do a small task... Next time is fast on desktop, perhaps the delay is in opening 100 files? Well, `cat * >/dev/null` takes ~700ms 1st time, ~5ms second, so that's probably a big part of it...)

Device might need to have the developer option "show all ANRs" turned on to show the "stopped" dialog. Otherwise it flashes the menu for a second, then exits with no commentary.

Some other various observations -- these should probably be separate threads -- suggest you either create threads for whichever you want to reply to, or reply here telling me which ones you'd like forked...

- both sets of touch controls seem hard to learn + hard to use (BUT I don't play games on Android, maybe they are natural to long-time users)
- audio test level: MP3 and MOD play, MIDI is silent
- several places in the UI, I expected a touch-anywhere to go on to the next thing, but nothing happened. e.g. after dying (I think -- I'd have to go back and take detailed notes)
- player name "U0_A116" (%d according to app install order) is unlikely ever to be the player's desired name. Suggest, on Android, initially smashing this to e.g. "Player"...
- game startup is uncomfortably slow with just the default set of levels installed -- every startup. It looks like it would take half an hour with every possible levelset installed. Desktop does some sort of caching, is this not yet working on Android?

Opening the "Just for testing..." level set, I click on the level number. This brings up the menu of level names, but it only displays for an instant before "Unfortunately, Rocks 'n' Diamonds has stopped."

Indeed, I could reproduce this. Apparently this has something to do with the internal structure of this level set, which contains some symbolic links (from which one points to "nowhere"). Not sure how this is stored in the APK zip file exactly, but I'm sure that this is the cause for the crash. (Will run it again with console output to see in detail what happens.) The final release package won't contain such a set, so this should not happen with the final Android version.

(It takes ~10 seconds to compute the menu. Even on desktop it takes what feels like a long time -- only ~1.5 seconds of realtime, but that feels like a long time to do a small task... Next time is fast on desktop, perhaps the delay is in opening 100 files? Well, `cat * >/dev/null` takes ~700ms 1st time, ~5ms second, so that's probably a big part of it...)

Yes, that's the reason for this slowdown (which is not *that* heavy on my own test devices, but still noticeable). The problem is that apparently the APK is not "installed" as in "extracted and stored in the file system", but in "stored as-is", so R'n'D is always run from within the compressed APK. The first Android test version still contained all graphics in PCX format, and it took ages to load them at startup. This is because some "known" files (like PNG images) are stored uncompresssed inside the APK, while all others (like PCX files) are compressed. Loading and decompressing them on-the-fly from the APK each time is noticeably slower than either loading uncompressed files (like PNGs) from the APK, or than loading them from a file system (for non-Android platforms).

To display the level selection menu, the level name is read from each level file, which apparently makes things slow. This should be optimized by using some sort of caching mechanism. (BTW: Classic Supaplex on DOS apparently had a similar problem and solved it by adding a single file to each level set that contained the names of all levels in the set.)

The crash should only affect the "just for testing" level set. If you find other sets that crash, please let me know.

Some other various observations -- these should probably be separate threads -- suggest you either create threads for whichever you want to reply to, or reply here telling me which ones you'd like forked...

That's OK for now. I'll fork new threads if needed.

- both sets of touch controls seem hard to learn + hard to use (BUT I don't play games on Android, maybe they are natural to long-time users)

I totally agree. In my opinion, classic games like R'n'D (that were meant to be played with either a joystick or physical cursor keys) are more or less unplayable on touch devices due to limited precision (while the situation being a little bit better on a tablet than on a phone). Maybe people being younger than me don't have these problems.

Besides that, creating usable touch controls seems to be a bit tricky with SDL anyway, because the screen is proportionally resized to fit the screen, leaving blank areas depending on the form factor of the actual screen. These blank areas are unaccessible for drawing virtual game controller overlays, while they still accept touch events to be processed as game controller input.

A solution I haven't tried yet are third party game controller apps like "GamePad" (a free download from the Play Store, I think), which implement custom touch controls that are mapped to cursor keys (which the Android version of R'n'D still recognizes), optionally drawing a virtual button overlay (as far as I know). This might help here to improve playability.

- audio test level: MP3 and MOD play, MIDI is silent

Yes. As far as I can see, the Android version of SDL_mixer has no MIDI support. (This is especially unfortunate for BD2K3!)

- several places in the UI, I expected a touch-anywhere to go on to the next thing, but nothing happened. e.g. after dying (I think -- I'd have to go back and take detailed notes)

Yep, right. I should add some "click anywhere on the screen" events to be recognized like "joystick button clicks" or "pressing return/space on keyboard" events for certain game situations.

- player name "U0_A116" (%d according to app install order) is unlikely ever to be the player's desired name. Suggest, on Android, initially smashing this to e.g. "Player"...

Good idea. I wanted to set this to the forename of the owner of the device, but apparently this is not easily accessible for SDL/Android applicatons (or I'm too dumb to find out how).

- game startup is uncomfortably slow with just the default set of levels installed -- every startup. It looks like it would take half an hour with every possible levelset installed. Desktop does some sort of caching, is this not yet working on Android?

See above; this seems to be caused by loading directly from the APK. In addition, it currently looks like run-time application data (like scores and tapes) is not stored, so nothing is cached at all. (Not sure anymore what R'n'D caches at all; will have a look at this again). So maybe this can be fixed and caching will improve startup speed at least a little bit.

Does anybody know if Android apps can be installed in a way that the assets directory from the APK gets permanently extracted, so game data would be read without the zip decompression layer?

I think I've seen apps with their APKs burst onto the filesystem. You should have a private persistent data area something like /data/data/com.artsoft/...; if the system didn't extract the APK for you, maybe you can do it yourself.

Finally, I begin to wonder if it is really necessary for RnD to walk the entire level- and artwork- spaces at startup time. Certainly for levelset selection, the user is walking around in what is effectively a directory browser. All you need to know at first startup time is the names of the highest-level groupings ("BD-Dream" ... "Tutorials", in my /usr/share/games/rocksndiamonds/levels/). When starting up from within some leaf level ("/usr/share/games/rocksndiamonds/levels/Emerald Mine Club/emc_crazy_mine_03/" where I've just started my desktop game) -- maybe you don't even need to know the higher-level directories?