What exactly is targetSdkVersion? [duplicate] - android

This question already has answers here:
What is the difference between compileSdkVersion and targetSdkVersion?
(11 answers)
Closed 5 years ago.
I know that targetSdkVersion is the "highest SDK version, your app is known to work with", but what is the point? I set my targetSdkVersion 22, and my app runs fine on an api 25 device. Is it not meant to prevent installation on further api versions? If no, then what is it meant for?

android:targetSdkVersion An integer designating the API Level that the
application targets. If not set, the default value equals that given
to minSdkVersion. This attribute informs the system that you have
tested against the target version and the system should not enable any
compatibility behaviors to maintain your app's forward-compatibility
with the target version. The application is still able to run on older
versions (down to minSdkVersion).
As Android evolves with each new version, some behaviors and even
appearances might change. However, if the API level of the platform is
higher than the version declared by your app's targetSdkVersion, the
system may enable compatibility behaviors to ensure that your app
continues to work the way you expect. You can disable such
compatibility behaviors by specifying targetSdkVersion to match the
API level of the platform on which it's running. For example, setting
this value to "11" or higher allows the system to apply a new default
theme (Holo) to your app when running on Android 3.0 or higher and
also disables screen compatibility mode when running on larger screens
(because support for API level 11 implicitly supports larger screens).
There are many compatibility behaviors that the system may enable
based on the value you set for this attribute. Several of these
behaviors are described by the corresponding platform versions in the
Build.VERSION_CODES reference.
To maintain your application along with each Android release, you
should increase the value of this attribute to match the latest API
level, then thoroughly test your application on the corresponding
platform version.
Introduced in: API Level 4
Sorry for just posting straight from Android.com but it gives a clear signal of what it does.

It is the one you are developing for. App can work on higher API as well. But it is the one used for rendering layout etc.

Related

Regarding the new requirements for updated Android apps in Google Play

Google Play recently issued a heads up to Android developers to update their apps with three new changes : https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html
I have a question regarding updating the targeted SDK to version 26. When I made this change for one of my apps, the Developer console showed me a warning saying that this new APK would not support an x number of devices, since it does not fall into some SDK version criteria. Since the app did not have too many active installs, I went ahead with it.
Now I need to do this for another app of mine which has quite a good number of active users. Would making this change of targeted SDK version have any impact on user having low end Android OS or older device models?
Could somebody please explain what might be the problems one might face while making such a change, from perspective of existing and new users?
Would love some clarification from anyone who has some info, but particularly from android app developers who have already made these changes.
From a user perspective: no problems, because changing the target SDK does not mean changing the minSDK.
For you as a developer: depending on the gap between current and future target SDK, there may be quite a lot of work to do because the runtime will handle things differently under the hood depending on the target SDK (e.g. permission handling, use of certain libraries, rendering of UI components).
Quoting from documentation for <uses-sdk>
As Android evolves with each new version, some behaviors and even appearances might change. However, if the API level of the platform is higher than the version declared by your app's targetSdkVersion, the system may enable compatibility behaviors to ensure that your app continues to work the way you expect. You can disable such compatibility behaviors by specifying targetSdkVersion to match the API level of the platform on which it's running. For example, setting this value to "11" or higher allows the system to apply a new default theme (Holo) to your app when running on Android 3.0 or higher and also disables screen compatibility mode when running on larger screens (because support for API level 11 implicitly supports larger screens).
There are many compatibility behaviors that the system may enable based on the value you set for this attribute. Several of these behaviors are described by the corresponding platform versions in the Build.VERSION_CODES reference.

Google Developer Console optimization tips(minSdkVersion) for tablet design

Find below what google has to say for making an application tablet optimized in its latest Google IO-13 initiatives. My question is :- Why do my app has to have min sdk version greater than 11 to make it tablet optimized? This means my application is not for tablets if I am supporting gingerbread phones which is still active in lot of devices.
At a minimum, check the element to make sure that:
targetSdkVersion is declared with value 11 or higher (14 or higher is recommended), OR
minSdkVersion is declared with value 11 or higher.
If a maxSdkVersion attribute is declared, it must have a value of 11 or higher. Note that, in general, the use of maxSdkVersion is not recommended.
From the <uses-sdk> documentation:
[...] setting [the targetSdkVersion] value to "11" or higher allows the
system to apply a new default theme (Holo) to your app when running on
Android 3.0 or higher and also disables screen compatibility mode when
running on larger screens (because support for API level 11 implicitly
supports larger screens).
There are a few key things to note here.
You don't need to set minSdkVersion to 11. They suggest setting either minSdkVersion OR targetSdkVersion to 11. Doing either will have the same effect for tablets.
You can have an application that runs on tablets just fine without doing this. It simply will use screen compatibility mode, which is not optimal.
If you aren't targeting a higher API version (or implicitly doing so with minSdkVersion), then your app will also not use Holo (without a library), which is a standard UI expectation for apps on newer (3.0+) devices.

targetSdkVersion vs. minSdkVersion: configChanges

I want to avoid Activity restarts when screen orientation changes. In older sdk versions it was done by configChanges="orientation" (in the manifest). In newer versions screenSize was added.
My minSdk is 8, the targetSdk is 17 and I find myself in a weird situation: I cannot put screenSize into configChanges (because of the minSdk) but my phone (4.1) will then destroy any activity on orientation change (because of the targetSdk).
Is there any way out? Can I somehow prevent this destruction without having to target an outdated Sdk (but still keeping it as an option in the minSdk)?
You may leave your android:minSdkVersion and android:targetSdkVersion as you currently have them (8 and 17 in your example).
In order to be able to put screenSize into configChanges, change this line
target=android-someapinumber
in the project.properties file. Choose someapinumber as the android version where screenSize first appeared (e.g., API 13).
Although you asked for a specific "screenSize" problem, this solution applies to all similar situations where you want to support older devices, but at the same time you must use newer features. In this particular case, "screenSize" will be ignored by older devices that do not know this property, so you don't have to worry about backward compatibility. In other cases, you may have to add conditions in your source code like shown below to ensure in runtime that your app will not use features that are not available in a given (older) android version.
if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.LOLLIPOP)
{
// Code that uses features available in LOLLIPOP and newer
// versions of android, while the app also runs on older versions
// and supports them because of android:minSdkVersion.
}
Ah I finally figured out solution:
As far as we cant affect "known suggested solution" with screenSize property as eclipse fires xml parse error on screenSize when we specify android:configChanges="screenSize", if we specify in targetSdkVersion 12 or less android os will not restart activity on orientation change. (Also I did now know and was using targetSdkVersion for identifying maximum supported sdk version. But as I researched again for this there is maxSdkVersion.)
So by this settings:
uses-sdk android:minSdkVersion="10" android:targetSdkVersion="12"
android:maxSdkVersion="17"
...
android:configChanges="orientation|..."
Os will not restart activity on orientation change and application will still support minimum and maximum sdk versions but will run in compatibility mode with sdk 12 which is highest version of sdk not restarting activity which will solve the problem above.

How to decide what will be the target android version?

I'm new in the android developing.
I need to write some simple application - and i need to decide what will be the target version.
I don't know how to decide this - because i want to support the most newer version with all the new abilities - but i also want to support the maximum devices ( there are few devices that have old versions )
So, How to decide what will be the target version ?
In the Android Manifest.
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
Set your android:targetSdkVersion to whatever is the last Android SDK version.
Quote from Bruno Oliveira at Google IO:
targetSdkVersion does not affect the minimum SDK level required to run your application. It should always be the latest version that you are aware of.
The only reason you could have to use a lower version would be to detect incompatibilities, but that is not a good reason because Lint does this better.
BUT set your android:minSdkVersion to as low as your app will run on. That's the important one.
For instance, my app uses very new features, but I set android:minSdkVersion to 3 (which means Android 1.5). My code detects Android 1.5 devices, and uses less-shiny controls on them, but still runs correctly.
Detection code sample:
if (android.os.Build.VERSION.SDK_INT > 4) {
ActivityTransitionAnimation.slide(this, ActivityTransitionAnimation.UP);
}
So, here is my suggestion:
Set android:minSdkVersion to 3
Everytime you discover an API is not present at that level, ponder whether the loss of potential users associated with increasing this number is worse than spending the time to implement a workaround.
I would say just start off with the lowest possible target and then as you encounter stuff that you can only do with a higher target you will have to change the target to the higher one. Using APIs that only work on for example 2.3 will show errors if your target is lower (because the APIs won't exist there).
Also you should consider the current state of the "fragmentation" to se what targets are actually being used out there. Looking at this chart (from October 5) maybe it could be worth just starting with 2.1 and se if it is high enough for all the things you want to do:
http://cdn.devilsworkshop.org/files/2011/09/android-OS-fragmentation-report.jpg

Ensure Android project doesn't call APIs with newer-than-intended API level

When developing an Android app, let's say I want it to be compatible with 1.6 (API Level 4) devices, but still enabling 2.2 (API Level 8) features such as adding android:installLocation to enable moving app to SD card. Therefore I set Eclipse to compile against 2.2 SDK instead of 1.6 SDK.
Adding unknown attribute like android:installLocation doesn't crash the app when running in 1.6 device, but in case when coding I call some API that is unavailable in 1.6, such as android.util.Pair or Base64, the app will crash when running in 1.6.
Is it possible (e.g. via an Eclipse plugin) in build-time (not in run-time!) to check whether the project is still compatible with 1.6, in other words, check whether there is any API calls to any of the methods/classes requiring more than 1.6 (API Level 4)?
The best way to check if your app uses a non-existing API on older handsets is to change the target to the old version (starting from the minimal one you support) and seeing if you have any compilation errors... This will point you to non-compatible API calls.
At least that's the way I do it.
This is a tough problem to handle gracefully in code. I asked a very similar question here.
It seems to me that you may be asking the wrong question. Checking for calls to new API features is reasonable, but if you want to make your app work well over multiple versions, you will have to have code that makes calls to old and new API levels as appropriate. There are many ways to do this and it's considered a best practice.
In that case, you may want to downgrade your target version and check that all the errors that come up in Eclipse are handled well in your code (and of course try it in the right emulator versions).
I know this question is ancient, but there is a "holy grail" solution to this issue (at least from your users' point of view):
You can publish two versions of your app, one requiring API level 8 and another requiring API level 4. Then, use versionCode 100, 101, 102, 103, ... for your level 4 version and versionCode 200, 201, 202, 203, ... for your level 8 version.
That way, if a user has API level 8 available, they get offered only the level 8 version of your app as it has the higher versionCode. And users that only have API level 4 through 7 available, get offered only the other version as the other one is incompatible.
It's a little bit more of a pain to maintain, but it has the (potentially huge) advantage that you can customize the reduced-features version to still provide a complete experience (no grayed-out buttons, etc.), and you can even keep the APK size smaller for that version as you don't even need to ship the code or related resources for the unavailable features.
You can find more details in Android's Multiple APK Support documentation.

Categories

Resources