Since your code needs to link properly in an Android API 21 environment since minSdkVersion is 21. Stuff that varies based on targetSdkVersion has to be handled at runtime.
Conversation
So, I believe what is controlling this is -D ANDROID_NATIVE_API_LEVEL=26 , which is being passed to CMake (not clang) and is most likely being interpreted by the CMake toolchain file (script). Problem: If I set this to 21, I get this legitimate-looking error:
1
This is what the hardware vendor explicitly recommends when using their gradle-based build… I guess I'll try bumping to 23.
1
I guess part of the problem is
gradle/AndroidManifest.xml refer to these three things as minSdkVersion/targetSdkVersion/compileSdkVersion,
CLANG refers to them as __ANDROID__API__/__ANDROID_API_FUTURE__/?,
and CMake refers to them as ANDROID_NATIVE_API_LEVEL/?/?
2
There's a CMake doc but it defines only ANDROID_NATIVE_API_LEVEL and not the other things.
1
ANDROID_NATIVE_API_LEVEL seems to be for minSdkVersion since minSdkVersion is the only one that's truly fixed at compile time.
targetSdkVersion is essentially the max supported API level semantics, so if you have targetSdkVersion 30 and it's Android 10 then it's 29 at runtime.
1
> When using the Android Gradle Plugin, this value is automatically set to match the application's minSdkVersion and should not be set manually.
That seems to be why it worked before.
2
Do you know what compileSdkVersion means in practice?
If that determines the java toolchain you get when building with gradle-controlling-CMake, but I am getting the minSdkVersion java toolchain when using Cmake directly, that might explain the discrepancy
1
compileSdkVersion is the toolchain version and you're meant to always use the latest one. You should be ending up building everything (Java and native) with latest toolchain but with minSdkVersion set appropriately (__ANDROID_API__ for native) so it's backwards compatible.
1
No matter how old the API version that you support, you're meant to be using compileSdkVersion 30 and targetSdkVersion 30 (but in practice, targetSdkVersion 29 is normal right now, and it'll be almost a year before Play Store enforces 30).
1
compileSdkVersion 30 should pretty much just work.
targetSdkVersion 30 requires supporting the latest restrictions, changes, etc. for newer API levels while still having code to support the older API levels you support so that actually involves work and runtime code decisions.
I believe the idea is Oculus has never shipped an Android OS newer than 8. (Still confused if I can use AAudio or not!)
1
You should probably still use compileSdkVersion 30 to have newer tools with a bunch of bug fixes and improvements but might as well leave targetSdkVersion at 26 if they don't make you deal with the newer restrictions and wouldn't be able to properly test higher than 26 anyway.
1
Show replies