Build for Android (32 and 64-bit) and upload as workflow artifacts

[ThreeDeeJay]

Context: #1010 and #824
This builds 32-bit/armeabi-v7a and 64-bit/arm64-v8a libopenal.so for Android that can replace older/generic OpenAL library from Android apps/games (if using root to access /data/app/*hash*/*package*/lib/...), or just include it in an android app/game rebuilt from source. Tested in sView (32-bit) and IdTech4A/Quake4 (64-bit).

Though apparently an update in android or something on my end broke apps' ability to load /etc/openal/alsoftrc.config (the only location that worked for me to load external MHRs) so I wonder if it would be possible to force HRTF on by default without relying on a config file since it doesn't even load the config or MHR from the supposed executable/working directory (/system/bin/ like it does on Windows. 🤔

[kcat]

Out of curiosity, where does the SDK and version number come from? It doesn't look like anything's installing it, and that version looks like it's prone to change. And are any of the apt packages needed for the Android build?

[ThreeDeeJay]

GitHub actions runners come with NDK pre-installed, but its directory variable wasn't defined so I had to hardcode the path after finding it by recursively listing all files in the drive. Kinda hacky, I know lol
But I'll see if I can find a way to set/get the proper variable for a cleaner/relative path. 👌

As for the packages, I'm not sure if they're all needed. I just used the linux build settings as a template since that's technically what Android is based on and what the runner uses, but I'll try building without them, though I'm not sure it'd inadvertently break something so let me know if there's any packages that are probably needed for core functions.

[kcat]

I don't think any of the packages should be needed. I don't think they'd work anyway since they're for the system it's compiling on, which wouldn't work for the Android target (though it looks like it may be picking up the pipewire and dbus pkg-configs, which it shouldn't because Android doesn't have them as far as I know; luckily it doesn't cause a build failure since they're optional at runtime).

[ThreeDeeJay]

I just looked at the log and both indeed fail to load/initialize so I'll go ahead and remove the whole deps_cmdline chunk and see how it goes. 🤞

[ThreeDeeJay]

btw just found the proper NDK path variable 6538bff 👌

[kcat]

Though apparently an update in android or something on my end broke apps' ability to load /etc/openal/alsoftrc.config (the only location that #824 (comment)) so I wonder if it would be possible to force HRTF on by default without relying on a config file since it doesn't even load the config or MHR from the supposed executable/working directory (/system/bin/ like it does on Windows. 🤔

HRTF being on by default would cause a problem for people using speakers, reducing the quality and increasing CPU load. If it can't detect the device as being headphones, then it needs either a config file or the app to enable it (or a modified build that uses HRTF by default).

[ThreeDeeJay]

Yeah, just like we were discussing on #1008 about Windows, it doesn't seem to be able to detect output device as headphones reliably (I know it's probably hard to tell whether the 3.5mm jack is being used for headphones or speakers, but in sView, I still need to force HRTF in the app settings even when using my bluetooth headphones which are recognized as headphones by Android).

So perhaps it might be handy to offer a separate HRTF build since that's probably the main reason why people would probably want to replace games/apps' OpenAL library. Or do you think it'd be possible to make OpenAL Soft load the config file from a path accessible by the app, like its data folder/s?
I just checked and it seems the stock file manager can read and write to /Android/data/packagename/ without needing root.

Also any idea if it would be possible to swap a compiled app's library on Android without having to root, like we do on Windows?
If I understand correctly the license requires being able to replace it, but most people don't bother rooting their phones so I wonder if there's an easier way 🤔

[kcat]

Yeah, just like we were discussing on #1008 about Windows, it doesn't seem to be able to detect output device as headphones reliably (I know it's probably hard to tell whether the 3.5mm jack is being used for headphones or speakers, but in sView, I still need to force HRTF in the app settings even when using my bluetooth headphones which are recognized as headphones by Android).

There's possibly a query to get the formfactor of the audio device that I don't know about, which could be added since the OpenSL and Oboe backends can't currently detect that. It might be an issue if the query can only be made via the Java API, instead of OpenSL, Oboe, or some other C or C++ API, since even though Java can be called from C/C++ with appropriate wrappers, it typically relies on some app handle given to the Java code (which at best would need a new extension function for the app to pass it in to OpenAL Soft, as it's not directly accessible).

Or do you think it'd be possible to make OpenAL Soft load the config file from a path accessible by the app, like its data folder/s? I just checked and it seems the stock file manager can read and write to /Android/data/packagename/ without needing root.

Loading config files and data files from extra Android-specific paths is certainly an option, if there's some way to get that path (or at least the packagename to construct the path).

Also any idea if it would be possible to swap a compiled app's library on Android without having to root, like we do on Windows? If I understand correctly the license requires being able to replace it, but most people don't bother rooting their phones so I wonder if there's an easier way 🤔

I don't think so. One of the complaints people have with phones is that they're more locked down than PCs, that they make it harder (though not impossible, and Android being less draconian) to access and replace files. At the very least, I think developer mode would need to be enabled to connect it to a PC as a storage device to access and transfer files, but it's not something I've messed around with very much.

[ThreeDeeJay]

There's possibly a query to get the formfactor of the audio device that I don't know about, which could be added since the OpenSL and Oboe backends can't currently detect that. It might be an issue if the query can only be made via the Java API, instead of OpenSL, Oboe, or some other C or C++ API, since even though Java can be called from C/C++ with appropriate wrappers, it typically relies on some app handle given to the Java code (which at best would need a new extension function for the app to pass it in to OpenAL Soft, as it's not directly accessible).

Perhaps something like AudioDeviceInfo?

Loading config files and data files from extra Android-specific paths is certainly an option, if there's some way to get that path (or at least the packagename to construct the path).

getExternalFilesDirs seems like what we need.

I don't think so. One of the complaints people have with phones is that they're more locked down than PCs, that they make it harder (though not impossible, and Android being less draconian) to access and replace files. At the very least, I think developer mode would need to be enabled to connect it to a PC as a storage device to access and transfer files, but it's not something I've messed around with very much.

Ohh that's right. I've taken root for granted for so long that I keep completely forgetting (rooted) ADB is a thing.
ADB Explorer is a fairly user-friendly way to modify system/app data files.



The only tricky part is finding the app folder hash after /data/app/ which I only know how to get in AppManager.
Also there are apps that use a Wireless debugging loopback to run adb commands from the same device, though I'm not sure if they allow root or if there's a GUI/file manager that can do what ADB Explorer does. 🤔

[kcat]

Perhaps something like AudioDeviceInfo?

Yeah, but I don't know how to get that info in C++. Doesn't even look like the AAudio API has anything for that (which Oboe sits on top of, alongside OpenSL).

getExternalFilesDirs seems like what we need.

Possibly, but that's also through Java.