My app requires that devices are running at least Android 2.0 OS. Would it make more sense for me to compile my project with the 2.0 SDK or does it make more sense to always compile my project using the latest SDK, even if it's well beyond 2.0...?
The problem with compiling against 2.1 for example would be that I don't know if an Android 2.0 device would even run an app compiled with 2.1...?
You can target a later SDK version using android:targetSdkVersion while still permitting your app to be run on earlier versions (since apps are filtered out based on the android:minSdkVersion). If you use API's that aren't supported, your app will force close. So, you'll have to pay attention to the API level annotations in the documentation for all functions, and test your app on an emulator set to use the minimum SDK version.
However, the Android Developer's Blog has some good advice on how to write applications that support earlier SDK versions - at a cost of some added work, of course. Whether it's worth it depends on whom you want to reach, obviously.
Related
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):
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.
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.
, 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.
I changed the build target from 7 to 16, with the only reason that I want to compile with the newest SDK. I still want to target versions starting at 7.
My project compiles and ran without problems on 2 devices. But I'm not sure if this is safe. I don't want to realease and that it crashes on some devices, because some things I'm not aware of.
Does it anyways make sense to upgrade the build target, without any specific reason?
Edit: Just to make it clear - I'm not doing it to target newer versions or support new features (I'm already using the compatibility library). It's just, because, maybe with newer build targets the internals have been improved - like performance, etc.?
If you do not use any functionality of the new SDK version(s) it does not make sense to update this requirement 'just for upgrading it'.
When running your application on a device, it will use that version, so it already makes use of the newest internals.
The android library is backwards compatible (meaning it is compatible with older version). The support library provides forward compatibility (meaning it adds functionality to match the newest android library version), the support library is provided with the application (in the APK), so it is available when required. The application first tries to use the android library (so it always uses the newest internals for that device) and if functionality is not present, it tries the support library.
If you require some new functionality then you should upgrade to that SDK version. And (eventually) add code to check the running version and provide an alternative for devices with a lower SDK version.
To find out the SDK version at run-time, for providing alternatives, use android.os.Build.VERSION.
I'm trying to scale my app to all screen sizes and I read that if I compile the app against android 3.2 then I'll be able to use the new qualifiers etc....But my question is - if I do compile it at this version, does that mean that mobile phones that have a lesser platform won't be able to download or run the app? Will I be excluding the majority of phones for the sake of including a very small percentage of phones that the tablets currently comprise?
You may compile your app using the newest SDK version of Android, or in your case 3.2, and the app should continue to run on older versions of Android. The only thing to be careful of here is to ensure that the API methods you use are still compatible with the older versions. These newer qualifiers that you mention would not be allowed for the older versions of your app, but there are some compatibility libraries that you may use for them found here:
http://developer.android.com/tools/extras/support-library.html
To ensure that your app is compatible with older versions of Android, you can install the newest ADT and also run Android Lint. Lint will point out functions that may not be available on different versions of Android, based on your manifest file. Your manifest file allows you to determine the minimum version of android that can use your app, as well as the ideal version of Android that your app is made for. Please refer to the following link for more details about versioning your app, and some backwards compatibility:
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
Google Admob requires that I have to compile my project with API-13 or later. To be able to use admob sdk.
My application is meant for mobiles with api-8 or later.
Does it mean if I compile my app with Api-13 or later I have to abandon my app support for older phones before Api-13 ?
My understanding is that since admob requires minimum api-13 to compile , it means it calls functions which are not available on old phones, so I am confused that potentially It won't be able to run my app for Api-8 to Api-12 and probably crash ?
Please advise me on this,
Does it mean if I compile my app with Api-13 or later I have to abandon my app support for older phones before Api-13 ?
No. If you read the AdMob documentation, "The Google AdMob Ads SDK for Android requires a run-time of Android 1.5 or later (set android:minSdkVersion to at least 3 in your AndroidManifest.xml). This means you can develop with the latest version of the Android SDK and your app will still run on an earlier Android version (1.5 minimum)."
My understanding is that since admob requires minimum api-13 to compile , it means it calls functions which are not available on old phones
It conditionally "calls function which are not available on old phones". This is fairly commonplace in Android development -- you use Build.VERSION.SDK_INT to determine if you are on a newer device and do one thing with newer APIs, but do something else on older devices.
in the android manifest i left the mini sdk as 8 . I then used ADT .. right click on project went to properties and set the target API to 13. tested on both devices with different API, works.
I want my Android app to have maximum reach, and hence want to support all versions V1.5 onwards. I find some features lacking in V1.5 that are available in V2.0 or V2.1. Could I compile on V2.1, and then set minSDK for the app to run on 1.5?
Plain logic says 2.1 specific features would not work, but let me know your thoughts.
Also, what are some other workarounds? What would "you" normally do in such a situation?
This is definitely possible; some of the techniques for backwards compatibility such as reflection and wrapper classes are documented in this article:
Backwards Compatibility for Applications
Also, I'd recommend compiling against the 1.5 or 1.6 SDK, otherwise you may end up accidentally using classes/methods from later SDKs and running into runtime errors on 1.5 devices due to those APIs not being available.
I would think there are two ways to handle this. In both cases you can develop against the 2.1 SDK and on startup check out what version of Android you're running with. Then you can either swap out whole classes based on the version or you can just block certain calls to methods that don't exist in 1.5.