I'm new to Android developing, and I would like to know what is the connection or difference between the version and the API level. What is each one referring to? And what does it mean when I decide to develop some app for API 14 or for android version 4.0?
Or is one a subset of the other? I simply didn't get the difference, and why are there two counters?
Thanks
Well, API is for development, so the changes in new API version are more "inside". But new version of Android usually adds more features for users, that are "visible".
Check this page http://developer.android.com/guide/appendix/api-levels.html, there is a table that shows relations between versions and API levels.
Multiple versions of Android can have the same API level but the API as an integer allows developers to more easily target devices. The chart below will give you an idea of their relationship but only the documentation contains exhaustive listings of the API levels and how they differ from each other.
Source: developer.android.com.
Because this data is gathered from the new Google Play Store app, which supports Android 2.2 and above, devices running older versions are not included. However, in August, 2013, versions older than Android 2.2 accounted for about 1% of devices that checked in to Google servers (not those that actually visited Google Play Store).
In addition to the answers provided, there is a detailed explanation of the Android Platform usage on Wikipedia (permalink).
This table will give you a highlight of Android API vs Version.
API Level is an integer value that uniquely identifies the framework API revision offered by a version of the Android platform.
You can have a new Android version with the same API release as the previous version.
Check out https://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels
A device running Android with version X will usually support applications written for API X and below.
This means if you want your app to support API 8, devices ver 8 will be able to run it, but also devices of ver 9, 10, 11, etc.
Here is the table which explains the ties between the numbers:
http://developer.android.com/guide/appendix/api-levels.html
In a short note:
Main difference between them is that API level for android application development framework API on the other hand android version is maintained to mention new features to user level.
In details:
API Level is an integer value that uniquely identifies the framework API revision offered by a version of the Android platform.
The Android platform provides a framework API that applications can use to interact with the underlying Android system. The framework API consists of:
A core set of packages and classes
A set of XML elements and attributes for declaring a manifest file
A set of XML elements and attributes for declaring and accessing resources
A set of Intents
A set of permissions that applications can request, as well as permission enforcements
included in the system
For more details you can visit this link:
https://developer.android.com/guide/topics/manifest/uses-sdk-element#ApiLevels
API = a set of functions and procedures allowing the creation of applications that access the features or data of an operating system, application, or other service.
Android = Android is a mobile operating system developed by Google.
So if we develop new API with new features they can be not supported in old android operation system, so we take old operation system , ++ version add support for new API and there we go (:
on the other hand if we have new operation system with new features we want to upgrade old API to support it, so we ++ version of the API.
Sound weird yeah ?
In simple words:
Android Version : Android is basically a mobile operating system developed by a consortium of developers known as the Open Handset Alliance and commercially sponsored by Google and they keep on updating Android by adding new features. So every new version of android have a version number known as Android version
API Level : API Level allow us to specify an app's/application's compatibility with one or more versions of Android, by means of an integer. Each versions of Android is associated with an API Level. So on a device the API Level expressed by an app/application is compared to the API Level associated with the version of the Android installed on the device.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
When you download an APP, the layout was fine regardless of what API the phone has. When I was making an APP for a school project, I used a different API to what my phone has in development , the layout was so messed up. Does the programmer release different versions for different APIs and when you download the APK, the app store determines which API you have and provides you with the corresponding version?
"When I was making an APP for a school course last semester, I used a
different API to what my phone has in development , the layout was so
messed up."
even the apk is compiled against certain api version the difference could be a result of:
implementation eg of components per os version (the implementation on device is different than the one the developer has compiled the app against)
mixing and usage of different support library version the app is compiled against - to maintain compatibility developer could use a support library or newest framework called androidx
each vendor/oem (original equipment manufacture) may alter the aosp but it need to maintain CDD [difference for altered framework / res / theming - vary by device oem] eg. deprecated overlays
usage of JIT
result of bugs
constantly changing android/gradle build tools altering the result of newly compiled the same source code of apk
the dev could use a custom class loader which may produce a different result each time the app is launched - eg like google uses its own network class loader in the account manager to create on device google accounts
the app could be an instant app or module app
mostly is a result of theming [styleables, attributes, even produced by os drawables]
for more info please refer to:
https://developer.android.com/topic/libraries/support-library/
https://source.android.com/compatibility/overview
https://source.android.com/devices/architecture/
"Does the programmer release different versions for different APIs and
when you download the APK, the app store determines which API you have
and provides you with the corresponding version?"
MOSTLY NO but the dev could make per configuration or architecture apk's so the play store could serve different one based on device type
see:
https://developer.android.com/google/play/publishing/multiple-apks
The same version of APK is used for every versions of android supported by the app. The fact that the app looks identical across different versions of Android is most of the time due to the usage of Android Support Libraries (or android x).
Nevertheless, with the new Android Bundles , the developer can define portions of the app which are available only to specific versions of Android.
As said in the Android documentation:
"Platform version
Different devices may run different versions of the Android platform, such as Android 4.0 or Android 4.4. Each successive platform version often adds new APIs not available in the previous version. To indicate which set of APIs are available, each platform version specifies an API level. For instance, Android 1.0 is API level 1 and Android 4.4 is API level 19.
The API level allows you to declare the minimum version with which your app is compatible, using the manifest tag and its minSdkVersion attribute. For example, the Calendar Provider APIs were added in Android 4.0 (API level 14). If your app cannot function without these APIs, you should declare API level 14 as your app's minimum supported version.
The minSdkVersion attribute declares the minimum version with which your app is compatible and the targetSdkVersion attribute declares the highest version on which you've optimized your app"
In your build.gradle (Module: app) file you always have something like:
android {
defaultConfig {
applicationId 'com.example.myapp'
// Defines the minimum API level required to run the app.
minSdkVersion 15
// Specifies the API level used to test the app.
targetSdkVersion 28
...
}
}
"Each successive version of Android provides compatibility for apps that were built using the APIs from previous platform versions, so your app should always be compatible with future versions of Android while using the documented Android APIs"
I think it is also very nice the note in the same link:
Note: The targetSdkVersion attribute does not prevent your app from
being installed on platform versions that are higher than the
specified value, but it is important because it indicates to the
system whether your app should inherit behavior changes in newer
versions. If you don't update the targetSdkVersion to the latest
version, the system assumes that your app requires some
backward-compatibility behaviors when running on the latest version.
For example, among the behavior changes in Android 4.4, alarms created
with the AlarmManager APIs are now inexact by default so the system
can batch app alarms and preserve system power, but the system will
retain the previous API behavior for your app if your target API level
is lower than "19"
More details on the setup of the Android Support Libraries needed to guarantee the Backward Compatibility for newer APIs can be found here
With regard to fixing the minSdkVersion the documentation comes to help again:
"If your app uses APIs added in a more recent platform version, but does not require them for its primary functionality, you should check the API level at runtime and gracefully degrade the corresponding features when the API level is too low. In this case, set the minSdkVersion to the lowest value possible for your app's primary functionality, then compare the current system's version, SDK_INT, to one the codename constants in Build.VERSION_CODES that corresponds to the API level you want to check. For example:"
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
// Running on something older than API level 11, so disable
// the drag/drop features that use <code>ClipboardManager</code> APIs
disableDragAndDrop();
}
Another very important point that not reported yet in that link is that "Starting on the dates listed below, the Play Console will require that APK uploads target at least Android 8.0 (API level 26)" source
so to be compliant you have to set up the preceding build.gradle file with nothing less than:
targetSdkVersion 26
This one is another very good link that tells more about the "Google Play's target API level requirement", outlining all the suggestions to update your app
Finally, if you can't manage to deploy the app with a single apk this link provides you directions to "Create multiple APKs for different API levels". Please note that in the same link they do NOT recommend this solution, unless strictly necessary
It may seem at the outset as though multiple APK support is the best solution, but this often isn’t the case
After going through the Android Documentation for Max SDK version i am unclear with effectiveness from 2.1 onward.
Two Statements from Docs :
1)
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.
2) WARNING:
note that in some cases, declaring the attribute can result in your application being
removed from users' devices after a system update to a higher API Level. Most devices on which your >application is likely to be installed will receive periodic system updates over
the air, so you should consider their effect on your application before setting this attribute.
Can some one make me clear the above two statements.
Reference : http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
After version Android 2.0.1, maxSdkVersion will not be used to check and re-validate apk after apk upgrade or system upgrade, however Google play still use this tag to do some filter and present to user according to their device system version. Here is a more detailed description.
The TARGET SDK version serves to acknowledge that the application was verified and tested by the developers for at most that API level.
Of course it can and should work with compatibility mode in new APIs, but it might not.
So it is always important to update to new API levels to assure that it is fully working in those new APIs.
EDIT: The max SDK serves for making the application only run at a maximum SDK and not devices with higher SDK level. It is not recommended because it takes out the possibility of users with higher SDK levels in which the app could run very well in their devices because they are fully backward compatible.
I am trying to decide what target API should I choose to build my next android app. I know that Gingerbread was a major upgrade over Froyo and thus I want to use API 10(2.3.3). Also the report from Google tells me that Gingerbread 2.3.3 now has 61.5% of market share(http://developer.android.com/resources/dashboard/platform-versions.html).
The thing is at this point of my project I am not very sure if the LocationManager and other API enchancement in Gingerbread will if of use, though my app will definitely use them. If I use 2.2 for development then I can target a greater audience.
My question is, will it be possible for 2.2(Froyo) users to install and run my 2.3.3(gingerbread) app if I dont use any new API's introduced in 2.3 SDK?
Edit : If the answer is no, what would you guys suggest me to do, being it March 2012 now and the pace with which updates are coming? Should developers start with minimum 2.3.3 now, seeing the bugfixes and enhancements been introduced in it, not to mention the top market shareholder.
You could target 10 as API level, but define a minSdkVersion of 8 or so in your manifest. This will enable users of Froyo devices to install your app. But you have to ensure, that you don't use any API calls which are exclusive to API level 10. If you need to use functions introduced in API level 10 you should use them via reflection and either reimplement the missing functionality for pre API level 10 or notify the user of the missing functionaltiy.
If you target your application at API 10, 2.2 users won't be able to install it, even if you don't use any new API methods.
If you keep your application at Android 2.2, 2.3 users will still be able to install and use it. See the documentation for more.
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.
I have a mildly successful app that targets Android 1.6 and am looking to upgrade the target API to 2.1 in order to include more features.
What will happen to those still using android 1.6? Will they just not see the update? I'd love to be able to check which api the user is using and implement code based on that within the same app.
It's a paid app so making a new separate version is out of the question.
Hey Dom Read this question it's the exact answer:
What if I want to release an update with higher minSDK than the one on the market?
Yes you can check the API code and use reflection to only allow methods to work for 2.1, see above link
Depends on how you write the new version of your app.
If the new features have equivalents in 1.6, just that new APIs are used, you may be in the "old Contacts vs new Contacts API" boat. See Using the Contacts API and search for 'legacy'.
Search the above link for Supporting the old and new APIs in the same application for sample code to select APIs based on current OS version.
If you can code your app so it still runs on 1.6 and newer OSes even though you use new APIs, then you'll need to modify the uses-sdk element in the AndroidManifest.xml to tell Android you can handle the older OSes. See AndroidManifest.xml uses-sdk element.