TomR
TomR

Reputation: 3056

Is it safe (what could go wrong?) to falsely provide higher Android target SDK API version for app (in case I have no higher compile SDK)?

I am using Delphi 10.4 (but my question is general enough to be relevant to any development environment - including ADS Jetpack Compose, React Native, etc.) which comes with installed Android SDK 29/NDK 21. From the one side, there is no way to ask Delphi 10.4 to use higher SDK (Trying to install Android SDK 31 and NDK 25 for Delphi 10.4 - what to provide in Delphi SDK manager wizards? is the description of my unsuccessful attempt). From the other side Google Play required all apps to target SDK 31 as of 2022.12.

So, I have the option (and some Delphi developers are constantly suggesting it) to manually edit AndroidManifest.xml and false state that app targets API 31 and at the same time I can continue compile it with SDK 29. My question is - can I falsely state higher target SDK API level and what could go wrong if I do this?

I did research what target SDK means exactly and https://proandroiddev.com/compilesdkversion-and-targetsdkversion-what-is-the-difference-b4227c663ba8 is the very fine explanation. Let me extract, summarize and adapt this article here.

So - there are 2 kind of features of Android apps. One kind of features target specific Android API versions. That means: if my app has min-SDK and target-SDK settings, then compilation includes all the SDK-specific implementations of this feature starting from the min-SDK and up to target-SDK. If compile-SDK < target-SDK (which is not advised, compile-SDK > target-SDK is advised), then the final apk includes the implementations for the interval [min-SDK, compile-SDK] only, compiler have no knwoledge about implementations (compile-SDK, target-SDK]. During the execution time the device OS determine the actual SDK of the device and the device OS can extract form the APK those version of the feature, that is the most closest to the actual device SDK.

Another kind of features have no such SDK-dependent implementations.

So - essentially. If I have the following values:

   min-SDK: 23
   compile-SDK: 29
   target-SDK: 31

Then there can be feature X which have SDK-dependent implementations v23, v24, ..., v29, v30, v31. And compile-SDK-29 can compile only v23-v29 implementations in the final APK.

So - my question essentially boils down to the question how Android OS will handle the APK that states target-SDK=31, but which has implementations v23-v29 only?

I can imagine that Android OS has consistent protocol (all the targeted features) how to handle such situation and there can be 2 options only (assuming that actual device SDK is 30 or 31):

  1. Android OS tries to read v30/v31 implementation of the feature and if it can not find the v30/v31 implementation of the feature then Android OS immediately reports the error about unsupported feature.
  2. Android OS tries to read v30/v31 implementation of the feature and if it can not find the v30/v31 implementation of the feature then Android OS tries to read v29, v28, ..., min-SDK implementation of the feature and, of course, it finds some older implementation version and uses it. Android OS can report warning in logcat, uses sees the outdated behavior, of course, but otherwise the app is working and there is no any error message of interruption.

So, which scenario is true? I guess that 2nd scenario is true, because I have never seen any incompatibility messages during runtime, if app installs on the phone or tablet, then it certainly runs.

I can not find the reference, but it seems to me that I have seen one article which stated that there are well maintained code bases that uses compile-SDK < target-SDK, if the app vendor consciously decides to continue to use the behavior and functionality of the features as implemented for the previous SDK API versions. And such vendors set higher target-SDK just to get their apps accepted in Google Play.

Upvotes: -1

Views: 126

Answers (1)

Dan Baruch
Dan Baruch

Reputation: 1093

, if app installs on the phone or tablet, then it certainly runs.

that's very not true. I have several cases where I have apps compiling with 32bit libs causing the app to instantly crash unless I specifically tell adb to install the app as 64bit.

What I assume is that it might not even compile if you have target SDK higher than compile SDK but even if it does compile, I think the app will simply crash on devices that runs SDK which has no definitions for the required functions. That's why when you write code you can check the SDK running on the device and apply the needed functions / functionality required for that SDK and if you fail to do that the app will crash. As in, say you have minSDK - 10 and targetSDK 30. If I'll run a function that has API X for SDK 10~20 but that API was changed to API Y from SDK 20~30 the app will compile and will be installed on all the devices. If I'll use API X only (that is, only for SDK 10~20) on a SDK 25 device, the app will simply crash when it will try to use that function.

Upvotes: 1

Related Questions