Remove dependency of Oboe on AAudio.h

[philburk]

Some folks are trying to build Oboe on old NDKs that do not have AAudio. We do not link with any libraries so it should be doable. We just need to remove the header dependency. For example:

enum class StreamState : aaudio_stream_state_t {
Uninitialized = AAUDIO_STREAM_STATE_UNINITIALIZED,

...becomes...

enum class StreamState : int32_t {
Uninitialized = 0, // AAUDIO_STREAM_STATE_UNINITIALIZED

[mnaganov]

I don't understand what are they trying to achieve. It's definitely possible to build with a new NDK but still target older platforms, this is what we do for the Loopback app.

Just copying all the values into a header file creates a "compatibility by a chance" approach. It's effectively the same thing as looking up and using an unpublished system function.

[dturner]

Isn't "compatibility by chance" what we're already doing with the dlsym lookups? Don Turner | Developer Advocate | donturner@google.com | +44 7939 287199

…

On 10 January 2018 at 18:49, Mikhail Naganov ***@***.***> wrote: I don't understand what are they trying to achieve. It's definitely possible to build with a new NDK but still target older platforms, this is what we do for the Loopback app. Just copying all the values into a header file creates a "compatibility by a chance" approach. It's effectively the same thing as looking up and using an unpublished system function. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA1S_A8IDTay8Vw27zxdYWPChY3DXZDWks5tJQZEgaJpZM4RZs8Q> .

[philburk]

Mikhail - some folks have imported Oboe into google3 as an external. But it does not build because they have an old NDK in google3. This would allow them to build.

But I share your concern about the values being accurate. Maybe we could add some static asserts in the oboe/aaudio code that would only be compiled on later NDKs. Then we would catch any errors. Something like:

Note
#ifndef __NDK_MAJOR__
#define __NDK_MAJOR__ 0
#endif
#if __NDK_MAJOR__ >= 15
#include <aaudio/AAudio.h>
static_assert(oboe::Format::Float == AAUDIO_FORMAT_PCM_FLOAT, "PCM_FLOAT mismatch");
et cetera
#endif

__NDK__MAJOR__ was only recently defined so not usable before when?
android/ndk#407
https://android-review.googlesource.com/c/platform/ndk/+/445108/1/checkbuild.py

BTW, here is a handy place to look for the AAUDIO constant values.
https://cs.corp.google.com/android/cts/tests/tests/nativemedia/aaudio/jni/test_aaudio_misc.cpp

[mikhail]

@mnaganov != @mikhail :)

[mnaganov]

I see. I think, the ideal solution would be to update NDK (or provide different versions of it) in google3 then.

As far as I can see, if we only plan to extend the enums in AAudio, and never override values (and that means, we must never introduce enum values that constitute 'count' or any combination of flag masks), then duplicating enums in a "third-party" header is fine.

@dturner Don, yes I'm not very excited with the current approach of looking up symbols either. Remember that hilarious bug in AAudioLoader where we have found that 2 functions with the same signature were swapped while importing them.

There is actually a linker mechanism called "weak symbols" (https://en.wikipedia.org/wiki/Weak_symbol) which, as I understand, allows an executable to provide its own symbols, but they can be overridden by an .so library, if it's present. But I don't know whether it's supported on Android.

[dturner]

If we want to do this it's probably an hour of work to copy AAudio.h into AAudioForOboe.h

[dturner]

Phil to check internal bug on whether NDK version has been updated

[philburk]

This may be needed for internal bug b/71872740

[philburk]

Ricardo needs this ASAP. So I bumped the priority. We can define the Oboe constants using hard coded numbers. Then we can use static asserts when we build on a new system to make sure that the Oboe definitions are accurate.