Android progress, some problems remain

First the good news, with elias' help I got one of my games running on the android emulator. Yay!


The bad news is that I had to disable some functionality to get it going. Here is what I discovered:

  • al_open_directory() fails reading the APK file system. I can't load all files from the assets directory like I usually do, I had to manually list each file in the code.

  • al_load_font() fails to load a ttf font that's in my APK.

  • al_load_audio_stream() fails to load a .xm file that's in my APK.

The latter two make me think perhaps FreeType and Dumb were not included in the build. But then again, it could be a problem with the APK file system.

Trying to debug these issues, I discovered that I can step through my C++ code using the androidStudio debugger, but I can't step into allegro functions. I discovered that the allegro debug libraries don't contain source listings, as in:

allegro5-debug-$ gdb
(gdb) l al_load_ttf_font_f
820  in /home/allefant/allegro/git/addons/ttf/ttf.c

So the debug library just refers to files on elias' harddrive. Is that how it's supposed to be?


al_open_directory is broken for me as well. But so easy to work around I never bothered to try and fix it.

al_load_font works for me, loading a .ttf from the .apk. So yes, will be good to debug that.

I never used dumb (and my Android builds do not include dumb), but al_load_audio_stream with an .ogg file does work for me, loading from the .apk. I can rather easily add dumb to my script creating the .aar file [1], all I need is a link to the source code of dumb, and instructions how to compile it for Android, and I'd make the script download and compile it.

I have no idea about the debug settings of those .so files, they are created by Allegro's CMakeLists.txt [2]

This is the complete commands I used to create the debug libraries:

cmake /home/allefant/allegro/git -DCMAKE_TOOLCHAIN_FILE=/home/allefant/allegro/git/cmake/Toolchain-android.cmake -DARM_TARGETS=armeabi-v7a -DCMAKE_BUILD_TYPE=Debug -DANDROID_TARGET=android-24 -DWANT_DEMO=off -DWANT_EXAMPLES=off -DWANT_TESTS=off -DWANT_DOCS=off -DPKG_CONFIG_EXECUTABLE=/usr/bin/pkg-config -DOGG_LIBRARY=/home/allefant/android/toolchain-armeabi-v7a/lib/libogg.a -DOGG_INCLUDE_DIR=/home/allefant/android/toolchain-armeabi-v7a/include -DVORBIS_LIBRARY=/home/allefant/android/toolchain-armeabi-v7a/lib/libvorbis.a -DVORBISFILE_LIBRARY=/home/allefant/android/toolchain-armeabi-v7a/lib/libvorbisfile.a -DVORBIS_INCLUDE_DIR=/home/allefant/android/toolchain-armeabi-v7a/include -DSUPPORT_VORBIS=true -DFREETYPE_LIBRARY=/home/allefant/android/toolchain-armeabi-v7a/lib/libfreetype.a -DFREETYPE_INCLUDE_DIRS=/home/allefant/android/toolchain-armeabi-v7a/include;/home/allefant/android/toolchain-armeabi-v7a/include/freetype2
make -j4
make install

Reading though that CMakeLists.txt there is no Android specific settings. But it might be cmake messing things up once again, adding special flags when it detects Android. Alternatively, maybe that's how a debugger works on all platforms? I don't think I ever used the debug library of something I did not compile myself (and therefore had the path to the sources). Can you see if you maybe can tell your debugger the location of the source code?

Otherwise another option is to compile Allegro yourself (using the above commands), then it should hardcode the correct paths to your local sources.

[Edit:] This [3] has a section called "Symbol Directories", maybe you can try that?

Neil Roy

al_load_font() fails to load a ttf font that's in my APK.

This sounds familiar. I had a similar problem with my game on the PC, loading a TTF with Physfs from a ZIP. I don't know if that's similar on the Android.


I got a little bit further. I discovered that in android studio, in the Debug panel there is an LLDB tab where you can send commands to LLDB.

For example, this will make it possible to step into libraries even if there are no debug symbols:

(lldb) settings show target.process.thread.step-in-avoid-nodebug
target.process.thread.step-in-avoid-nodebug (boolean) = true
(lldb) settings set target.process.thread.step-in-avoid-nodebug false

With that I can actually step into al_load_font, even though it doesn't show source code. Using the 'dis' command in LLDB I can see the disassembly. That's not much, but it's something.

I tried this to make it find source code:

(lldb) settings show target.source-map
target.source-map (path-map) =
(lldb) settings set target.source-map /home/allefant/allegro/git/ /home/martijn/prg/alleg/allegro5-git/

But that doesn't work as of yet. LLDB doesn't give me any indication of even trying to open the allegro sources.

Thread #616904. Printed from