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.
Related
I'm currently involved in an open source project which I regulary release in the Google PlayStore. As the statistics of android-usages show that less than 10% of my users use android 3 or lower I started to wonder if I should switch to Android 4.X. This gives me some more functionality which I can't include at the moment (SettingsFragment for example, which isn't even inside of the support library).
When I release a newer version with higher requirements in the PlayStore - what will happen to my users which don't fulfill this requirements? What about users who want to install my app with low android-versions? Is my app hidden for them as soon as I upgrade the app? Is there any chance that my current version of my app can still be found by lower devices and the newer version is available for newer devices? I would like to avoid having two seperate apps in the playstore as I would lose a few people.
I couldn't find anything in the Google-Docs so I needed to ask for help in this glory community ;)
You can target multiple different APIs using multiple APK's. Just use your current version for old versions and create a new APK for everyone else. More here: http://developer.android.com/google/play/publishing/multiple-apks.html
Hope this helps, let me know if you need more info.
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
If I target my Android app for version x, will it have any problems if the user uses an Android version above x?
What will I have to watch out for?
Yes, it's should work.
Updates to the framework API are designed so that the new API remains
compatible with earlier versions of the API. That is, most changes in
the API are additive and introduce new or replacement functionality.
As parts of the API are upgraded, the older replaced parts are
deprecated but are not removed, so that existing applications can
still use them. In a very small number of cases, parts of the API may
be modified or removed, although typically such changes are only
needed to ensure API robustness and application or system security.
All other API parts from earlier revisions are carried forward without
modification.
Take a look at this
Yes! It should work on upper versions of the sdk without error. But you should carefully read the release notes
We are planning to create an android application for our web application. I have noticed that the latest android sdk is 4.0 but many mobiles on market just run on lower versions. If creating an app in lower version is supported in higher versions, which would be the most advisable version of android to start working with?
I advice you to target your application for Android 2.1.
This statistics can give you answer why.
Yes apps created for lower versions run on newer ones.
Which one to pick as the lowest version depends on your needs.
I like to start with 1.6. as a basic version¹ and increase it depending on what features I need. You can get an idea of the version distribution here. For a list of changes between each android version check out the API levels site and click on a level.
Keep in mind that 1% or 2% of a certain android version still represent a lot of customers when you consider how many devices are out there (wikipedia claims 190 million in october 2011). But on the other hand, many of these device owners may not expect that new apps support their version and don't look into the market at all. So it's a bit of a personal decision in the end.
¹ support for 1.5. and lower is a lot of work for a minority of users, it doesn't support different screen sizes for example
Indeed, almost all apps for older version will work with newer a android as well.
In the android developer guid it says:
Updates to the framework API are designed so that the new API remains compatible with earlier versions of the API. That is, most changes in the API are additive and introduce new or replacement functionality. As parts of the API are upgraded, the older replaced parts are deprecated but are not removed, so that existing applications can still use them
When creating your app, try setting the "minSDKlevel" to the lowest value where it still works. Like that you can make sure many people can use your app.
Here you can find two useful articles on different API levels and compatibility:
http://developer.android.com/guide/appendix/api-levels.html
http://developer.android.com/resources/articles/backward-compatibility.html
Yes, it will work on future versions.
How should I make the choice ? What are the parameters I should take into account ?
First of all you should take into account relative number of devices running a given version of the Android platform
Have a look at Android versions market share. I would develop for 1.6+. If you will realize in the middle of development that you want some API feature from newer version, you will have 3 choices:
Don't use that feature
Detect Android version from the app and then decide what to do
Change required Android version in your manifest file and project settings
If possible, you should support the oldest Android version still in widespread use. That would be 1.5. If you need features from later versions, you might consider requiring newer versions, but if you can do your work on the oldest version still available, you should to increase the number of people who are able to use your app.
The Oldest version that supports all the functionality your application requires.
For example: Your app needs multitouch? Target version 2.1
My application doesn't need any functionality introduced in newer versions, so I target 1.5
I agree with the answers posted above, and I would add that on the android API reference site, most of the time the minimum API level is specified (http://developer.android.com/reference/android/package-summary.html).
You can have a look at this page to identify the Android version associated with a given API level: http://developer.android.com/guide/appendix/api-levels.html
Personally, I develop everything for 2.1. There are only a handful of devices that still run <2.0 and most of those people have already put custom roms on them already. I know it kind of screws people with older phones, but I don't like the idea of crippling my app just to make it backwards compatible.
Also I feel like developing for >2.0 encourages people to upgrade their phones =P
#Falmarri: I see some flaws in your logic. Usually I'd tend to follow the same path as you if I'd be developing on another Plattform, like Windows. I do my C# applications always against the latest (non-beta) version available, as the .NET Framework is freely available for everyone (take out the new releases not being available for Win2k, which is almost 10 years old now).
With Android this attempt don't work. A majority of the devices which run 1.5 and 1.6 do it because there is no update for this device, as the manufacturer stopped developing new versions for this phone (either to motivate users to get a new upgraded one) or because it's to time intensive to make backports to this "old" devices.
So this uses don't have the "free choice" of upgrading their phones. Technically it's possible of course with rooted/custom ROMs, however most users do not have the technical knowledge to root/flash their devices with custom ROMs or don't want to lose their warranty.
So if you want to offer your App to as much people as possible, you have to develop it in mind with a much older OS version. In Android case, against 1.5.
And this is basically what I do. I've done my Apps with 1.5 in mind.
If you are developing using Android Studio:
1. Go to Tools --> Android --> AVD Manager
2. Click the Create Virtual Device... button of the AVD Manager dialog.
3. Select a Device on the "Select Hardware" wizard page of the dialog and click Next.
4. In the bottom right of the "System Image" wizard page you will see the following:
If you click the "API level distribution chart" link, it will provide you a summary of cumulative distribution by API level. I assume the information is kept up-to-date with each release. From there you can click on an API level to get specific information about that API level. Based on the information presented there, you need to use API level 18 or lower in order for about 75% of the current Android Market to be able to use you application.
Perhaps this is the type of information you are looking for. Hope it helps!
This is a direct quote from the Android Docs:
Generally, it’s a good practice to support about 90% of the active devices, while targeting your app to the latest version.
In a practical sense, this is impossible unless you had an unlimited budget.
Even Android themselves are only releasing security updates from version 8 onward.
As of right now, I recommend supporting Android 7 onward. This should cover 57.9% of market share.
If you scroll to the bottom of this page, there is a table that shows Android support information.
It will be updated monthly as the figures I quote above will change with time.