Is disabling an application for newer Android versions (e.g. 4.2 and higher) possible?
I've got an application that Google has rendered useless from 4.2; I don't want users use/install it when they are using Android 4.2 or higher.
It depends on what exactly you want. According to the documentation for the deprecated maxSdkVersion:
Future versions of Android (beyond Android 2.0.1) will no longer check or enforce the maxSdkVersion attribute during installation or re-validation. Google Play will continue to use the attribute as a filter, however, when presenting users with applications available for download.
So, users could still sideload the app, but it will not appear in Google Play for users above that level. That sounds like what you want. There is no way(since 2.0.1) to completely disable sideloads.
Regarding this note about compilation:
...and the SDK will not compile if maxSdkVersion is set in an app's manifest.
I had my doubts. After testing it just now, my Eclipse/ADT compiles just fine with maxSdkVersion=15 set. So I wouldn't worry about that.
The answers regarding targetSdkVersion are fine for some things, but if you're using something that was intentionally broken/changed in a newer API, they won't work at all. For example, no amount of compatibility mode will allow 4.2+ to turn airplane mode on/off programmatically from within a non-root app. It also won't change the new implementation of SecureRandom.
If the app really is just completely useless for 4.2 because a key feature was removed, try using maxSdkVersion. Using a deprecated method always leaves me with a bad taste, but if they don't offer any sort of functional replacement, sometimes it's the only choice.
However, if you can work around it by changing how you accomplish <whatever>, that is by far the best solution.
Previously you could have set android:maxSdkVersion="integer" to 17 but after 2.1 it has been deprecated.
You can specify android:targetSdkVersion="Max_api_version_which_supported_by_your_app" to API Level: 16(4.1) below than 4.2
Related
I'm facing [LinearAlloc exceeded capacity][1] error when I try to install our app on devices running Gingerbread. So we decided to break our app in two versions: a light one with just some of our features (targeting API 8+) and another one one with our full features (targeting minSdkVersion=11).
My question is: should I set the light version with maxSdkVersion=10 in this case? The problem is that the developer guide highly recommends to avoid using this property. But I also would like the user to see only the best version of our app for his device.
Our project is really complex and the performance on old devices is becoming bad.
I've found some workarounds for this error but all of them uses Ant, and we've already moved to Gradle. And we still have a considerable number of Gingerbread users, we must consider them.
Is this approach ok?
The downside to adding the maxSdkVersion is that should the device get upgraded in the future your app would be removed in the process.
You have to wonder if someone would bother upgrading a 2-3 year old device though or if there is even an update available.
However, to cover all scenarios you could simply add a check in the "light" version that notifies the user that they can install the full app on a device with SDK >= 11. You could also link to it directly in Google Play.
You may try bringing multiple APK support to your app.
http://developer.android.com/google/play/publishing/multiple-apks.html#HowItWorks
The answer to your question
Should I set the light version with maxSdkVersion=10 in this case?
is here:
You should avoid using android:maxSdkVersion in general, because as
long as you've properly developed your application with public APIs,
it is always compatible with future versions of Android. If you want
to publish a different APK for higher API levels, you still do not
need to specify the maximum version, because if the
android:minSdkVersion is "4" in one APK and "8" in another, devices
that support API level 8 or higher will always receive the second APK
(because it's version code is higher, as per the previous note).
So differentiating your APKs in their manifests by only specifying different android:minSdkVersion values should be enough.
As a newbie I am not sure how do I make sure my app works between certain android version range. According to latest statistics, it seems that 2.3.3 (gingerbread) is still heavily used out there (other than ICS and JB). But now that Kitkat has made its way, many apps are updated to support that as well while still keeping compatibility with older versions of android.
So essentially what are general guidelines to support latest version of android as well as specified minimum old version. For example, how do I make sure my app works starting from 2.3.3 (gingerbread) to latest 4.4 kitkat ?
Also can emulators be used to make sure app works in specified range?
P.S: I know that can be specified via app manifest file but that's not my question I am just looking for how to actually make app compatible between the two versions.
Thanks for your suggestions and helpful ideas :)
You have different approaches to reach that goal.
First thing:
Despite the min sdk you want to support you should always use the latest sdk to build your app.
At this point, choose the min sdk you want to support and declare it inside the manifest.
If you are using eclipse with lint enabled it will be very easy at this point to spot if you are using unsupported api for that platform level.
If you want to use a new api and make it only available on newer devices you have basically two approaches:
use reflection (discouraged)
use #TargetApi annotation on the methods that use new api and call
those methods only on devices on which those api are available
if(Integer.valueOf(android.os.Build.VERSION.SDK)>whatlevelyouwant){
callMethodWithNewAPI();
}
You can find a lot of information on Google's 'Support Different Versions' Site: http://developer.android.com/training/basics/supporting-devices/platforms.html
Generally it says that you should support 90% of the devices out there (which means you can leave out Android 2.2, but should start with 2.3).
However, some new apps don't start with 2.3 but start with 4.0. This makes life much easier in words of testing.
In ADT you can use the ADV to generate differents emulators, one for each Android version you want to support and test.
It´s not as good as a real device but a useful starting point
You can define MinSdk and maxSdk in your manifest file.. This will define which Android Versions will be supported by your application.
android:minSdkVersion
An integer designating the minimum API Level required for the application to run.
android:maxSdkVersion
An integer designating the maximum API Level on which the application is designed to run.
So if you want your app to be compatible with 2.3 to the latest version you can define in your manifest file :
<uses-sdk
android:minSdkVersion="8" />
If you don't specify maxSdkVersion, it will take the latest released android version. So this line impllies your application is compatible with all devices having android 2.3 or above ..
I have an app which I want to install on ICS only . So i have set the min and max sdk versions as below.
<uses-sdk android:minSdkVersion="14" android:maxSdkVersion="15" />
Ideally this should work. But some how it is able to install on Jellybean version also.
ICS(API 14-15)
JellBean (API 16-18)
What am I Missing here? Please help
According to the documentation:
Future versions of Android (beyond Android 2.0.1) will no longer check
or enforce the maxSdkVersion attribute during installation or
re-validation. Google Play will continue to use the attribute as a
filter, however, when presenting users with applications available for
download.
The behaviour seen is expected. However, if you publish to Google Play, the application will be filtered.
Unless you have some feature that absolutely requires only older APIs (airplane mode comes to mind), then such a limitation does not serve much purpose.
If you're concerned about non Google Play sources or users sideloading the app, you can always do a runtime check for the Android version and either restrict features or close the app.
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLYBEAN){
//do something about the Android version being too new
}
Keep in mind that if you want your app to reach the largest userbase, you will have to address the issues caused by the new Android versions at some point.
Per the maxSdkVersion documentation:
Future versions of Android (beyond Android 2.0.1) will no longer check or enforce the maxSdkVersion attribute during installation or re-validation. Google Play will continue to use the attribute as a filter, however, when presenting users with applications available for download.
Filtering will still work from Google Play, but you can sideload the app onto any device with a higher SDK version than the minimum.
First, my english is not very well. I have a question:
"If i have an phone with Android 4.0 and i'm looking for a specific app. However, in the Android manifest of that app stands: maxsdkversion:"8". Will the app be displayed on thed android 4.0 phone?
No, it will not be displayed.
Per the docs http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
Google Play will continue to use the attribute as a filter, however,
when presenting users with applications available for download.
That's why, again per the docs:
Warning: Declaring this attribute is not recommended. First, there is
no need to set the attribute as means of blocking deployment of your
application onto new versions of the Android platform as they are
released.
Is there a way to prevent an app from being installed on Android Honeycomb?
I am looking for either a market filter or a manifest option.
According to this discussion on google groups (android-developers list), setting maxSdkVersion="10" will block Honeycomb; however it won't stop a device upgrading to Honeycomb (or force app uninstall) once your app is installed.
In your Android Manifest file, set the uses-sdk tag. Android 3.0 is level 11. Also note, however, that Google explicitly states that they make their code backwards compatible so you don't have to do this. If you have a good reason to, go ahead, but be aware that Google thinks most people should never have to.