Can't update because of a wrong target SDK found by the server

[p1gp1g]

For Sunup and NextPush, the upload of the new versions fails with error "Target SDK 32 is smaller than the minimum 34". The 2 applications target SDK 36.

If you want, I can try with an universal apks (it contains a single apk) which is extremely lightweight for the 2 apps, like 2-3 MB

[lberrymage]

Yikes, sorry I missed this. Are you able to share the .apks file so I can test with it?

[p1gp1g]

Here it is: https://codeberg.org/Sunup/android/releases/download/1.2.3/sunup.apks

[t895]

Same issue here on DNSNet

https://github.com/t895/DNSNet/releases/tag/1.3.13

[p1gp1g]

Universal APKS works, it defeats the purpose of APKS, but at least users can update their app

[lberrymage]

The bug is here:

parcelo/apksparser/src/main/kotlin/app/accrescent/parcelo/apksparser/ApkSet.kt

Lines 209 to 212 in 792fe71

	// Target SDK
	apk.manifest.usesSdk?.let {
	targetSdk = it.targetSdkVersion ?: it.minSdkVersion
	}

Instead of updating the calculated target SDK for each APK if it's present like the preceding code comment says, the server updates it if the uses-sdk element is present. If an app doesn't have a target SDK, the effective target SDK should fall back to the min SDK as per the targetSdkVersion docs. However, under certain conditions (explained in a moment), non-master split APKs have a uses-sdk element with a min SDK and no target SDK, causing target SDK evaluation to fall back to the min SDK.

I think the reason this behavior wasn't showing up before was that the "certain conditions" are when bundletool's "inject min SDK" setting is true, which happens by default in bundletool 1.18.3. So far, all of the APK sets I've been provided which trigger the target SDK issue were indeed built with bundletool 1.18.3, while the ones which don't trigger the issue used bundletool 1.18.2.

So the issue is twofold: Parcelo's target SDK evaluation logic is wrong, and new defaults in bundletool 1.18.3 make Parcelo's behavior result in incorrect target SDK evaluations.

As mentioned by @p1gp1g, the workaround for now is to build universal APK sets by passing --mode=universal to bundletool's build-apks command as described in bundletool's documentation.

I think the correct fix would be to update the target SDK evaluation logic to update the effective target SDK only on master splits (splits whose split value is null) since, presumably, those are the only ones which have an effect on the target SDK the OS sees. I would prefer to double check this in AOSP though.