Migrate from "oboe" to "ndk::audio"

[WilledgeR]

This pull request drops Oboe and uses ndk::audio (thin safe binding of native AAudio) for android platforms.

Pros:

✅ Pure rust implementation, so libc++_shared.so is not required anymore. Fixes #900, Fixes #815
✅ Stream now could be Send and move between threads safely. Fixes #793, Fixes #818
✅ Stream can accept wider range of SampleFormat { I16, F32, I32, ... }. (in the future, See: #497 )
✅ Supported since ANDROID_API >= 26 witch is %95 of devices as android distibution dashboard reports.

Cons:

❌ not supported in ANDROID_API < 26 witch is %5 of devices world wide :(

[WilledgeR]

I need help to configure cargo-apk test to use android26 toolchain not android23

[est31]

I need help to configure cargo-apk test to use android26 toolchain not android23

strange, I've thought we use android 30 in CI since commit 802073d.

[est31]

Thanks for filing this! I wonder, could you rename the whole oboe directory to android maybe? or android-ndk?

[WilledgeR]

@est31 what about aaudio? it looks nicer and keeps harmony with coreaudio

[est31]

note: ld.lld: error: unable to find library -laaudio

hmm I wonder how one can fix this error.

[WilledgeR]

@est31
this is very similar to Linker error in Android Studio while compiling NDK project witch got fixed by changing min_sdk_version to 26 (as expected). but here we have cargo-apk that seems not reading cargo.toml/min_sdk_version

[WilledgeR]

@est31 moving android example to a dedicated crate with some apk metadata solved that problm

[est31]

thank you ❤️

[Frando]

Thanks, I will try this in the next days, and also see if #959 is still needed.

❌ not supported in ANDROID_API < 26 witch is %5 of devices world wide :(

So this is raising minimum supported Android version to Android 8/Oreo. We are currently adding audio functionality to an open-source Android app with several hundred thousands active users, and are seriously considering using cpal, as the app is cross-platform and uses a shared Rust core between all platforms (Linux, Windows, macOS, iOS, Android). The app currently works on all versions from Android 5.0 Lollipop, and has a significant amount of users on old, outdated Android devices. AAudio was only added in Android 8.0 Oreo, and it is currently most likely not feasable in the short term for this app to do this change, because it would force several thousand users to either buy new devices or stop using the app. Therefore, this change would mean we'd either have to not use cpal or fork cpal to still include the oboe API.

Is there a significant downside to leaving the current oboe backend intact, and adding the AAudio-only backend as a seperate host, with feature flags to select between the two? The easier-to-build AAudio could be enabled by default, whereas oboe could be behind a feature flag.

[est31]

Thanks for this feedback. I understand that if there is 3.2 billion Android devices, then 5% of that would be 115 million. For apps at your scale, it would still be thousands of devices.

I suppose we could continue maintaining the oboe backend upstream behind a feature flag, which would help with containing the issues of that backend to the app devs who really need it. A question would be however for how long.

@Frando would you be interested in becoming the maintainer of the oboe backend?