Should I build an app that targets Android 2.2 and release it on the Android Marketplace;
Would the app be available for download and use on devices running a version of Android OS lower than the targeted version of the app? - Let's say Android OS version 1.6.
What would happen if a user (with an Android OS version 1.6 powered device) were to attempt to run the app?
Would they be prompted to update their OS or just receive an error message?
It depends what you have in the minSdkVersion field in your AndroidManifest.xml. If it is set to 4 or lower, then it will be visible to people using 1.6.
There's a good explanation here.
The android SDK is completely backward compatible using the mechanism that #Graham mentions. The other question will be "how far should you go". Use this graph to see the population of users on each platform level.
http://developer.android.com/resources/dashboard/platform-versions.html
This is pure opinion, but I would advise starting your app at API levels 7 or 8. The benefits of the APIs in EClair+ are worth losing this 0.4% still on 1.x devices.
If you are targeting 2.2, users with earlier SDK will not be able to download it.
They will see: This app is Incompatible with your device XXXXXXX
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.
so I'm using QT to develop an app for Android, and according to Sophos Mobile Security this app is "Built for outdated Android versions: this app doesn't support recent android security features. the app was built for an older version of android"
in qt creator I have android-25 set as the android build sdk (which I wouldn't consider old after all, it's 7.1.1 nougat)
how can I make this warning go away? Is there a way to build my app for a newer version of android without excluding users from using it? (I have 7.1.1, and at least I want to use my app)
thank you for your response in advance.
EDIT:
seems like there are (at least?) 3 spots where I can set an SDK version:
minimum required sdk, as seen on the screenshot here: Qt for android: change the application icon
target SDK version, as seen on the screenshot above
this was the only one I was aware an hour ago: projects->build->build android apk->android build sdk
what they govern, how to set them? should they be the same or different?
Android suggests you use the latest sdk version for targetSdkVersion and for build-tools version (they have to match). In fact, Google Play now requires you to target at least SDK 26. This will not prevent older devices from running app. Actually it will be more problematic for newer devices, as you are stating that app has been fully tested and can run on newer devices, and does not need backward compatibility. See https://developer.android.com/distribute/best-practices/develop/target-sdk for more details.
As for minSdkVersion, that is what will determine the earliest devices supported, and you should try to keep it as low as you can, and as 95-99% of your users.
I use minimum sdk version 1.6 and run app on android device 4.0 but the app layout look likes devices with android 1.6. Is not it possible to use proper sdk based on device android version?
For clear my mean, suppose:
I use min sdk version 1.6 and target 8.0. I want when it runs on device version 4 it uses sdk 4, on device version 5 it uses sdk 5 and so on.
You can support different API levels creating multiple APKs taking advantage of this Google Play feature.
It’s essential to adopt some good practices from the get-go and prevent unnecessary headaches further into the development process.
Creating Multiple APKs for Different API Levels explains these steps in detail.
What do I need to consider before choosing the target android OS for app development?
This is my understanding of how to do it and any clarification would be appreciated:
Determine which OS version is currently in use the most. Look at distribution graphs etc.
Target that version.
that is what I read all the time, but I have some questions.
Suppose 4.0 is the version that is the most used among android phone consumers so I should target 4.0. Now, suppose that I don't use features that are unique to 4.0. will my app work with any version below 4.0 including 1.5, 2.3 etc.? Consider the reverse situation. If I target version 2.3 and if my app uses only features that are available to 2.3 will my app work on phones that are running version 4.0 even though I will not be using features that are unique to version 4.0?
thanks.
have a look at your AndroidManifest.xml
There is a targetSdkVersion and minSdkVersion if you want to support all devices running 2.2 and up then set minSdkVersion to api level 8 (android 2.2)
but in general, its a good practice to develop against the latest api as target (currently API 19, Android 4.4), so you can ensure it will work from your chosen min up to the newest OS api
so if you want to support at least Gingerbread up to KitKat do this in your manifest:
<uses-sdk android:minSdkVersion="9"
android:targetSdkVersion="19" />
and develop against api 19 :)
Suppose 4.0 is the version that is the most used among android phone consumers so I should target 4.0. Now, suppose that I don't use features that are new to 4.0. will my app work with any version below 4.0 including 1.5, 2.3 etc.?
Only if you don't use APIs that were introduced after the earliest version you want the app to run on.
If I target version 2.3 and if my app uses only features that are available to 2.3 will my app work on phones that are running version 4.0 even though I will not be using features that are unique to version 4.0?
Yes. Some functions get deprecated in newer OS versions, but most of them still work in newer releases for keeping compatibility.
I feel the thing to stress here is that Android is backwards compatible, so newer versions will almost be able to run apps developed for older OS versions.
The target version is the highest version you have tested it on. You should always target the absolute latest if you can. The min version is the lowest version that will be able to install the app.
So in the manifest, you would typically have something like this:
<uses-sdk android:minSdkVersion="9" android:targetSdkVersion="19" ...
Pick the minSdkVersion based on the features that are absolutely required for your app to function.
So you might wonder what the purpose of targetSdkVersion is. One reason is if your app has some optional features that are in later versions of the SDK. targetSdkVersion will allow you to use those later features, but you will need to protect those method calls with a check against the device's SDK with a call like
if (Build.VERSION.SDK_INT >= 11)
myMethodThatUsesFeaturesOnlyInHoneycombAndLater();
Another reason is that sometimes the Android team makes changes to some of the defaults in various settings on your classes, but to maintain compatibility for future versions on which you have not tested your app, they keep the old default if your app doesn't claim to target this later version.
For example, after Honeycomb, the menu is supposed to be integrated with the action bar. But old apps that were compiled with earlier SDKs have not been tested with Honeycomb or later, as proved by them having a targetSdkVersion of less than 11, so the OS knows to display the old style menu. Once this developer decides to test their app on a more recent targetSdkVersion, they update the value and the OS can trust that they have tested it on Honeycomb, so it can safely show the new style menu.
While creating a project using eclipse i have Minimum SDK required as Android 2.2(Froyo) and Target SDK as Android 4.2(Jelly Bean) compile with Android 4.3. I have used sqlitebrowser v2.ob1 for creating database. My app runs without any errors (few lines in red in logcat though) and meets my requirements when i run it in an emulator. I tried 3 different emulators and it works fine. But when i tried this app in a mobile device it shows force close whenever there is something to do with database. I mean to say that it shows force close when it has to retrieve from database or connect to database. By searching i learned that just the .apk file is enough for the app to run even if externally created database is used in it (copying to assets folder and then to the default location). My questions are
Shouldn't my app work fine in any device ranging from Android 2.2 to 4.2 ?
Should i try compiling the app with Android 4.2 instead?
Am not sure about the version of the device i tried it in but am sure its within 2.2 and 4.2 . (Probably gingerbread). Other than plugging the device to PC via USB and seeing logcat (bcoz i dont own an android mobile phone) what can i do to solve this?
How is the app's version, emulator and version of mobile or any other device related?
My app can run on what versions of devices?
This is my first android app so any help is appreciated. Thanks in advace
It's possible that you are using a feature in your application that isn't supported by a lower version of the SDK. It's difficult to tell you exactly what that might be without any source code or stacktrace, but I can clear up your understanding of minSdkVersion and targetSdkVersion.
Consider that with each new version of the Android SDK, additional features and APIs are introduced that did not exist in previous versions. Obviously, the older versions of Android don't support those features.
When you specify a targetSdkVersion you are specifying that you are using features that were introduced in that particular version of Android. You are also implying that you have tested your application at that particular API level, and that it works as it should.
When you specify a minSdkVersion that is lower than your targetSdkVersion, you are implying that your application will work properly on a lower API level because you have manually programmed tests or checks in your code to ensure that the current API level is compatible with a feature before running it.
For example, if I wanted to run a feature introduced in Jelly Bean but I want to retain support for a lower API level (e.g. Gingerbread), I might add the following check before I run the feature (see other version codes here):
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN) {
// run some code specific to API level 16
}
The Android SDK can automatically deal with code introduced in a lower API level, but it can't automatically deal with code specific to a higher API level.
So with that in mind, to answer your questions:
No, it's only guaranteed that your application will work properly on Android 4.2. It's up to you to ensure that it remains backwards compatible for earlier versions that you wish to support.
It shouldn't matter. Instead, you should first determine if your application runs on a device/emulator that is running the same API level as you are targeting (Android 4.2, API level 17), then run it on a device/emulator running a lower version and try to isolate the code that is causing it to crash (logcat will be helpful).
You can check the Android version of a device by going into Settings > About phone > Android version. If it is running Gingerbread, keep in mind that a lot of new features have been introduced since then and your application might be using some of those features. For the emulator, you can specify an API level when you create an emulator (you can download other versions to use from the SDK Manager).
I think my answer so far has made this relationship clear.
To reiterate, your application WILL run on any device running Android 2.2 or later, but it can crash if you are using features from a higher API level than the device is running.
If this is still not clear, you should read more about supporting multiple platform versions in the Android documentation: here.