cargo-apk: Use min_sdk_version to select compiler target

[MarijnS95]

Fixes #193, cc @hrydgard

According to 1 minSdkVersion is used to determine the compiler target and ultimately limit what API is available at compile-time. This is most likely because using/linking newer API will result in runtime linker errors on these older platforms.

---

I think we still have a couple things to do here:

• Now that min_sdk_version is mandatory (see the unwrap), perhaps we should default it to the minimum SDK level available in the NDK (the min() of default_platform())?;
  (obviously reword the defaults in the cargo-apk docs);
• Remove the "arbitrary" default of minimum version 23? Does anyone recall why this was chosen? NDK r24 beta still ships with support for SDK level 21, which would then be the lowest;
• Is targetSdkVersion still mandatory? If so, does it still make sense to set it to the max available in the SDK?;
• when we have these defaults, should we remove the arbitrary overrides in ndk-examples?

[hrydgard]

targetSdkVersion is very important to be able to set separately from the others, because Android uses it to decide behavior at times. For example, the new Scoped Storage restrictions have completely different behavior in Android 11 depending on if you're targeting sdk version <= 29 or >= 30. Also, from August 2021, Google Play has prohibited uploading apps targeting lower than 30 to Google Play. See https://developer.android.com/distribute/best-practices/develop/target-sdk

minSdkVersion just restricts which devices you can install on. I think just for ease of maintenance something like 23 makes perfect sense, older devices are not really relevant anymore.

[MarijnS95]

targetSdkVersion is very important to be able to set separately from the others

Yes, merely checking if it still makes sense to set a default here, and if so, what. Not planning to remove/disallow the ability to override it from metadata in any way 😉

just for ease of maintenance

Here I have a hunch it's easier to use the minimum available in the NDK, as 23 will probably get removed from a future NDK at some point. On the other hand, this could cause minor variations in compilation depending on the environment. However, that's not an issue as long as it compiles fine (minSdkVersion should only have an effect on what's available during compile-time).
Not so much for targetSdkVersion which currently is dependent on the environment (only the default, though) and has the ability to cause much more havoc at runtime.

In other words, I think it should be safe to:

• Default minSdkVersion to whatever is at least available in the NDK (perhaps with a lower bound of 23, to not break existing builds);
• Default targetSdkVersion to the least required by Google Play as of writing, instead of being dependent on the maximum platform shipped with the SDK combined with what's in Android/Sdk/platforms/android-xx.

[MarijnS95]

@hrydgard This is ready now. I'll open a separate PR for target_sdk_version, which is a different issue that needs its own documentation. Thanks for bringing this all to my attention!

[hrydgard]

Awesome, thanks for taking care of this!