1) apk_file_interface has no way of writing files. Should I always switch back to standard_file_interface when I want to write a file (implicitly though al_save_config_file or explicitly through al_fopen), and then, once more, to apk_file_interface? This seem to complicate code a lot! Is there any way to avoid it?

2) Despite what comment in android_system.c says, Allegro does not return external storage dir (sdcard) for ALLEGRO_TEMP_PATH, ALLEGRO_USER_DATA_PATH, ALLEGRO_USER_HOME_PATH, ALLEGRO_USER_SETTINGS_PATH or ALLEGRO_USER_DOCUMENTS_PATH. Instead, it returns path to Internal Storage. Indeed, I see no way to get a path to External Storage, even though AllegroActivity prints it to log, and checks if it is mounted and writeable. Is this intentional?

And an unrelated question: why doesn't Allegro use AAssetManager_* functions directly instead of JNI calls to work with files?

It marked as API 1, so I guess it always was there, but who knows now. I only learned about it myself today, when I saw it in code at my new work

Yes, I think a separate type of path seems to be the way to go.

I'm only asking because these functions does not seem to have the same problems with compressed assets that Allegro's implementation has... But maybe I'm wrong.

I can't quite imagine it being useful on anything, but a mobile platform with SD card support. That being said, while iOS doesn't support them, Windows Phone does (if Allegro ever expands to it - and it may, what with the recently announced Android compatibility!), and I think Ubuntu Phones will have them too (I plan on getting Meizu MX4 Ubuntu as soon as it cames out, just to try something slightly different from the usual locked-down mobile OSes).

The call chain seem to end at Asset.cpp (https://github.com/android/platform_frameworks_base/blob/master/libs/androidfw/Asset.cpp) and various calls to libc functions. Though, there is a catch: when opening an asset from apk, this class likes to mmap it into memory, unless otherwise specified (I believe one needs to pass ACCESS_UNKNOWN as the mode argument to prevent this). Which may lead to crashes when reading really big files (at work, we have a single 200Mb file inside APK where all assets are stored in custom format, and opening it crashes on low-end devices with out of memory errors).

I fixed up a solution for compressed assets problem in my local copy of Allegro, because I needed it recently, but it's not very pretty. Allegro only want uncompressed assets to know their size beforehand, and the only way to know size of compressed/streaming assets is to read them to the end. But size of file isn't always needed. So, I made Allegro compute it lazily for compressed assets, only when it is requested. But then, Allegro does it the slow way, by reading to the end of stream and rewinding it to the starting position (in case someone asked a file size in the middle of reading it).