Currently, I tend to target all my app development to API 8, so that I can hit the largest number of devices 'out there', basically from Android 2.2 upwards.
Do any experienced Android developers reading this have a perspective on what features, as a developer am I 'missing out' on, and more importantly, what are my users missing out on? In this day and age, what API is the 'best' one for my apps to target? Or is there no such thing, and each app should be targeted for a given API on its merits?
I'm not looking for pointers such as read the android developer docs (I have, or at least what I consider the salient parts), I'm more interested in the views of experienced developers as to how they decide which API to target.
Thanks.
if you set your target and minSdkVersion to 7 and use support (compatibility) library v4, then your app will support nearly 95% of all android phones, and still you are able to use modern features of newer APIs (by using support library).
I usually target the minimum API required by the apps functionality. If there is a minor feature needing a higher API, I make it optional instead of increasing the minimum for the whole app. In addition to using ActionBarSherlock and the compatibility libraries, I occasionally back port a few things from later APIs to keep the current basis.
While I decide the minimum on a per app basis, most of my apps target 2.1, as they were written almost one and a half years ago. Now days, I have new apps target 2.2, though I plan to change it to 2.3 very soon.
I guess my point is that there is no defined minimum API target. You should choose the one which offers maximum user reach, along with as much major functionality as possible. UI elements like the action bar and ViewPager can be used via libraries, and the ones not available in libraries can sometimes be back ported. However, it is usually not worth it to sacrifice users running a lower API version just for a better UI.
Related
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.
When I created my application, I chose 1.0 for the minimum SDK and 4.3 for the target SDK, so my application works on all phones.
But why would we choose (for example) a minimum SDK of 2.2?
Is it about performance, or something like that?
First of all i'd like to clear,
android:minSdkVersion="integer"
Despite its name, this element is used to specify the API Level, not the version number of the SDK (software development kit) or Android platform. The API Level is always a single integer. You cannot derive the API Level from its associated Android version number (for example, it is not the same as the major version or the sum of the major and minor versions).
find more detail
we choose minimum and maximum version for our app because , some of the feature which are not supported in lower/higher versions of android are used in app . The Android system will prevent the user from installing the application if the system's API Level is lower/higher than the value specified in this attribute.Hence preventing unwanted force close.
Most of the features of higher versions of android will not work in api level 1 .thwn why will you put level 1 as minimum sdk.
Android is a system that is everytime changing, and that implements new features in each new version.
When you develop an app, you will have to deal with :
Compliance for the user
Nice features for your application
For example, animations of clickable elements are not well implemented in Android 2.3. So when you will have to develop an application, you will have to choose :
Compliance with a maximum users including 2.3 compliance
Develop a lot of nice animations, including on clickable elements
It's why sometimes you decide to develop an applications, you may decide to not include some versions of the SDK.
And for having a clear view on how much users you would loose, you may want to go to :
Dashboards
99,9% of phones use SDK 2.2 and later and all cool features that you can use are avaliable on later SDK versions than 1.1. That is the main reason, but you can use earlier version of SDK for minimum but in has no efect because you are covering all devices with 2.2 SDK.
I am using a textbook which uses android V2.0. Can you tell me which version of android can run apps for version 2.0 without any problems ?
If you are going for just running the app, then any device with API level 5 (Android 2.0) and up (that includes Jelly Bean and any future versions) will be able to run your app without any problems. The developer docs have an API level guide here.
However, you should familiarize yourself with subsequent versions of Android so that you can make an informed decision on what version you should use, and what features you will be unable to use.
For example, you can see on the Supporting Multiple Screen Sizes page that Android 3.2 (API level 13) introduced new features for supporting multiple screen sizes. If you use API level 5, your application may not scale correctly on some devices (namely tablets).
Though it is tempting to try to support as many devices as possible, there is a definite trade off involved with using a lower API level. For some apps, it doesn't really matter if it scales correctly, but it is something that you need to take into consideration when choosing a target or minimum API level.
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
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.