Conversation

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
Is it surprising to you I am hitting the chk issue at CMake-minSdkVersion 23, given I now know (because I get the duplicate symbol error) that __ANDROID_API__ is being set properly to the minSdkVersion?
1
It should be fine if it's actually set to the same value that you end up having for minSdkVersion at runtime. If it's 26 for the native code and 23 at runtime, it'll break. If you set minSdkVersion to 26 so it matched it wouldn't break, since it'd match what it's using to build.
1
Replying to and
Hey so, I really appreciate your help on this and I'm sorry about all these minor questions… I do have one more question. Is _chk something that would appear on all functions, or only socket functions such as sendto?
2
Replying to
Okay, that's extremely interesting. But this does still imply that if I could compile out the socket code, I'd sidestep this issue? (I'm not sure I *can* get rid of it because maybe it uses sockets for IPC, but I legitimately don't want my audio subsystem talking to TCP/IP!)
1
Replying to
You should really just get __ANDROID_API__ actually set to 23 (if minSdkVersion is 23). It's not the only thing that's going to break. It's also possible the compiler/linker use stuff that's not available for lower API levels, etc. since higher API levels are a diff target.
2
Show replies