I have defined in my manifest android:targetSdkVersion="15" and I would like to test with a device with API level equal to 17.
The minSdkVersion is set to 15.
<uses-sdk
android:minSdkVersion="15"
android:targetSdkVersion="15" />
I know it will work since minSdkVersion is set to a lower version than the device's one but my question is should I change the targetVersion whenever I change the device ? Isn't the targetSdkVersion supposed to be always equal to the one of the device I am testing with as it is said in the reference
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html ?
You shouldn't change the target version with every device, but with every new API level that is released.
As the webpage that you've already posted states:
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.
and a few lines further:
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.
Every new API contains new features, but will also deprecate old ones; some may even get removed completely! So devices running with a higher API level might not support the same features anymore that you used in your app, which forces them to enable compatibility mode to once again be able to run the app properly.
In short, no, your targetSdkVersion should just be as high as the highest API goes. The minSdkVersion should of course be as low as possible, and you should try to avoid using maxSdkVersion, as that one will decrease the mobility of your app over time.
Even if your minSdkVersion is 1 and the targetSdkVersion is 19, new devices won't have to enable compatibility mode to run the app.
Related
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.
Update: Adding this to manifest solved it:
<uses-sdk android:minSdkVersion="8" android:targetSdkVersion="14"/>
<supports-screens android:smallScreens="true" android:normalScreens="true" android:largeScreens="true" android:xlargeScreens="true" android:anyDensity="true"/>
Looks like google silently stopped listing newly submitted apps in tablet market that don't meet their "optimization tips".
One of those "tips" is setting minSdkVersion="11", which means losing 40% of their whole userbase who still run sdk 10 (hilarious).
Can someone please suggest the least painful solution that would let me target both pre 11 SDK users and tablets, preferably without getting into multiple APK business.
If multiple APK is the way to go, then what is the best criteria to separate users on, so I can have a single version code at least.
(the app is fully compatible with all screen sizes and densities, currently targets minSdkVersion="8")
You are reading it wrong..
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.
I put 'or' in bold to make sure you read it...It was already in upper case, but was not enough ;-)
Use targetSdkVersion to 17 and Support library as other people said.
Use the Android Support Library provided by Google. You can download it through the SDK manager. It requires a few changes to existing code (like using getSupportFragmentManager() instead of getFragmentManager(), but it works just fine.
Looks like google silently stopped listing newly submitted apps in tablet market that don't meet their "optimization tips".
I'd be interested to know of any proof you have which supports that statement.
One of those "tips" is setting minSdkVersion="11"
That is partially correct. Quoting the Target Android versions properly section which you linked to in your comment to Waza_Be ...
At a minimum, check the element to make sure that:
a. targetSdkVersion is declared with value 11 or higher (14 or higher is recommended), OR
b. minSdkVersion is declared with value 11 or higher.
c. 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.
Note at the end of 'a' there is the word OR in capitals making 'b' unnecessary if 'a' is true (and we all know we can ignore 'c').
You need to use the support library which has most of the functionality (if not more) of all sdk's > 11
The support library can be used on any device 2.2 and up
Google play is a unified market place for both phones and tablets. When a device visits the Google Play, it reports api version and capabilities (hardware), so the market only shows apps matching the provided criteria. If your app is not compatible with a device it will not show up.
Up to version 2.x (api 10) the same code was used for both tablets and phones. Then version 3.x (api 11-13) was just for tablets and then version 4.x (api 14) was again unified.
So we have 2.x tablets, 3.x tablets and 4.x tablets. Use minSdkVersion to declare up to which version your app supports.
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.
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.
I am currently developing an android app, testing it on my Nexus S. If I am running it, using minSdkVersion="7", targetSdkVersion="7" it performs well, but if I set targetSdkVersion (or both variables) to something higher than 13, the app starts to perform very bad.
After my custom views finished to draw, the GUI of the app hangs (no ANR is shown) for about 5 seconds, then it works perfectly.
Any ideas?
EDIT:
I would like to develop my app on API 16, but being downwards compatible to API level 7, so I thought of testing it on API 16 as well as API 7. But on level 16 it performs poorly.
IMO this does not make sense, because if my phone uses Android 4.1, apps targeting level 16 should perform better than once targeting 7.
What are the main differences between API 13 and 14 when drawing Views?
I am using some custom views, the SherlockActionbar and ViewPager from the support package.
Thanks
I had the same issue.
When you switch to targetSdkVersion=14, android:hardwareAccelerated will default to "true" instead of "false"
This will allow you to target 14 and not suffer from performance issues:
<uses-sdk android:minSdkVersion="8" android:targetSdkVersion="14" />
<application android:hardwareAccelerated="false" >
if you set the targeted version higher than your min version, then you are allowed to use commands that the min version does not know. Its meant for things where you know that higher versions have better variants of code, so you would check what version the device runs on and then use code nr1 or code nr2.
You should only use different api versions if you are sure about how to handle it.