Android platform versions in use

Supporting Different Platform Versions

This lesson teaches you to

You should also read

While the latest versions of Android often provide great APIs for your app, you should continue to support older versions of Android until more devices get updated. This lesson shows you how to take advantage of the latest APIs while continuing to support older versions as well.

The dashboard for Platform Versions is updated regularly to show the distribution of active devices running each version of Android, based on the number of devices that visit the Google Play Store. Generally, it’s a good practice to support about 90% of the active devices, while targeting your app to the latest version.

Tip: In order to provide the best features and functionality across several Android versions, you should use the Android Support Library in your app, which allows you to use several recent platform APIs on older versions.

Specify Minimum and Target API Levels

The AndroidManifest.xml file describes details about your app and identifies which versions of Android it supports. Specifically, the minSdkVersion and targetSdkVersion attributes for the element identify the lowest API level with which your app is compatible and the highest API level against which you’ve designed and tested your app.

As new versions of Android are released, some style and behaviors may change. To allow your app to take advantage of these changes and ensure that your app fits the style of each user’s device, you should set the targetSdkVersion value to match the latest Android version available.

Check System Version at Runtime

Android provides a unique code for each platform version in the Build constants class. Use these codes within your app to build conditions that ensure the code that depends on higher API levels is executed only when those APIs are available on the system.

Note: When parsing XML resources, Android ignores XML attributes that aren’t supported by the current device. So you can safely use XML attributes that are only supported by newer versions without worrying about older versions breaking when they encounter that code. For example, if you set the targetSdkVersion=»11″ , your app includes the ActionBar by default on Android 3.0 and higher. To then add menu items to the action bar, you need to set android:showAsAction=»ifRoom» in your menu resource XML. It’s safe to do this in a cross-version XML file, because the older versions of Android simply ignore the showAsAction attribute (that is, you do not need a separate version in res/menu-v11/ ).

Use Platform Styles and Themes

Android provides user experience themes that give apps the look and feel of the underlying operating system. These themes can be applied to your app within the manifest file. By using these built in styles and themes, your app will naturally follow the latest look and feel of Android with each new release.

To make your activity look like a dialog box:

To make your activity have a transparent background:

To apply your own custom theme defined in /res/values/styles.xml :

To apply a theme to your entire app (all activities), add the android:theme attribute to the element:

For more about creating and using themes, read the Styles and Themes guide.

Источник

Android Version Distribution statistics will now only be available in Android Studio

For the longest time, Google would publish Android version distribution statistics on a dedicated webpage. However, the chart hasn’t been updated since May of 2019, and even then, May’s update happened 6 months after the last update. It’s clear by now that Google no longer plans to update that chart, but today we’ve learned that Google has another place where they show the version distribution statistics: Android Studio (via 9to5Google).

Developers can find the latest Android Platform/API Version Distribution statistics by creating a new project in Android Studio and then selecting “help me choose” under the minimum SDK dropdown.

The chart will help developers decide the right minimum SDK version for their application. For example, if you select “Android 6.0 Marshmallow” as the minimum SDK version, then Android Studio will inform you that your app will run on 84.9% of all devices. Similarly, if you select “Android 8.0 Oreo” as the minimum SDK version, then Android Studio will inform you that your app can run on 60.8% of all devices.

Based on this data, we can construct a table showing the distribution of Android OS versions.

Android Platform Version (API Level)	Distribution (as of April 10, 2020)
Android 4.0 “Ice Cream Sandwich” (15)	0.2%
Android 4.1 “Jelly Bean” (16)	0.6%
Android 4.2 “Jelly Bean” (17)	0.8%
Android 4.3 “Jelly Bean” (18)	0.3%
Android 4.4 “KitKat” (19)	4%
Android 5.0 “Lollipop” (21)	1.8%
Android 5.1 “Lollipop” (22)	7.4%
Android 6.0 “Marshmallow” (23)	11.2%
Android 7.0 “Nougat” (24)	7.5%
Android 7.1 “Nougat” (25)	5.4%
Android 8.0 “Oreo” (26)	7.3%
Android 8.1 “Oreo” (27)	14%
Android 9 “Pie” (28)	31.3%
Android 10 (29)	8.2%

It makes sense for Android version distribution to be shown in Android Studio since this data is really only useful for developers anyway.

Источник

Android API Level, backward and forward compatibility

Jun 9, 2019 · 8 min read

If you get to read this article it might mean you are wondering things like:

• What is an API?
• What does API Level mean?
• How to use compileSdkVersion, minSdkVersionor targetSdkVersion?
• How can I ensure my app will work properly on devices with different versions of the OS?

All these concepts are related to each other and I will try to clarify them to you in this article in a simple but effective way.

In order to do so, we need to have in mind the difference between SDK and API in software development and the meaning of API Level in the Android ecosystem.

In Android, it’s true that th e re is a 1:1 relationship between the SDK and the API and often these two terms are used as synonymous, but it’s important to understand they are not the same thing.
But it’s correct to say that for each Android version there is an SDK and there is an equivalent API and API Level.

It stands for Software Development Kit. Think of the word “kit”… it is exactly a collection or a set of different tools, libraries, documentation, samples to help developers to build, debug and run Android apps. Along with an SDK, an API is provided.

Opening the SDK Manager in Android Studio shows much clearer what is part of an Android SDK.
The first tab SDK Platform lists the SDKs of each Android version.
As per example, shown in the picture below, Android 9.0 (aka Pie) SDK contains:

• Android SDK Platform 28 (that’s the framework API)
• Source code for Android 28 (that’s the implementation of the API, as you can see is optional… keep this in mind)
• and a bunch of other stuff… like different system images for the Android emulator.

The second tab SDK Tools shows a bunch of other tools which are still part of the SDK, but platform version independent, which means they might be released or updated separately.

It stands for Application Programming Interface. It is simply an interface, an abstraction layer that allows communications between two different “pieces” of software. It works as a contract between the provider (e.g. a library) and the consumer (e.g. an app)
It is a set of formal definitions such as classes, methods, functions, modules, constants that can be used by other developers to write their code. Also, an API does not include implementation.

API Level

API Level is an integer value that uniquely identifies the framework API revision offered by a version of the Android platform.
Usually, updates to the framework API are designed so that the new API remains compatible with earlier versions of the API, for this reason, most of the changes to the new API are additive and the old parts of API are deprecated but not removed.

But now someone could argue…

if an Android API doesn’t provide implementation and the SDK Manager offers an optional downloadable API source code as part of the SDK, where is the actual implementation?

The answer is easy. On the device.

Let’s go through this quickly…

From source code to an APK file

Generally, an Android project is composed by the code developers write using Android API (the application module), plus some other libraries/dependencies (.jar, AAR, local modules…etc) and some resources.
The compilation process converts Java/Kotlin code, dependencies included (one reason to shrink your code!), into DEX byte-code and then compressed everything into an APK file along with some resources. At this stage, the implementation of the API is not included in the resulting APK!

DEX files and Android Runtime

The Android Runtime is where all the dirty job is done and where DEX files are executed. It is made of two main components:

• a Virtual Machine in order to take advantages of code portability and platform independence. Starting from Android 5.0 (Lollipop) the old runtime environment, Dalvik Virtual Machine, has been totally replaced by the new Android RunTime (ART). Dalvik used a JIT compiler, whereas ART uses AOT (Ahead of time) compilation plus JIT for runtime code profiling.
• Core Libraries are standard Java libraries and Android libraries. In simple words, this is where the implementation of the API resides.
  The API version available at this level is the one offered by the version of the Android platform in which the app is running.
  For example, if the actual device has installed Android 9 (Pie), all the APIs until API Level 28 are available.

If the few key concepts of how the Android Runtime works and what is the role of the API is clear so far, then it should be quite easy to understand backward/forward compatibility and the usage of compileSdkVersion, minSdkVersion and targetSdkVersion.

compileSdkVersion

This value is used only to tell Gradle what version of the SDK to compile your app with. For developers, it allows accessing to all the APIs available up to API Level set to compileSdkVersion.

It is strongly recommended to compile against the latest SDK version:

• a high API Level allows developers to take advantages of the latest APIs and capabilities provided by new platforms.
• in order to use the latest SupportLibrary, compileSdkVersion has to match the SupportLibrary version too.
  For example, in order to use SupportLibrary-28.x.x, compileSdkVersion has to be set to 28 as well.
• for migrating to/using AndroidX, compileSdkVersion has to be set at 28 at least.
• getting ready to satisfy Google Play’s target API level requirement. As announced by Google, in order to spread new Android versions quicker out in the market, every year Google will enforce a minimum target API Level for new applications and updates. More info here and here.

Android applications are forward-compatible with new versions of the Android platform because API changes are generally additive and old APIs might be deprecated, but not removed.
That means forward compatibility is basically guaranteed by the platform and running an application on a device with a higher API Level than the one specified in compileSdkVersion does not have any runtime issue, the application runs as expected on newer platform versions too.

App + compileSdkVersion = 26 and using an API xyz() introduced in API Level 26 can run on a device with Android 8 Oreo (API Level 26).
The same app can run on a device with Android 9 Pie (API Level 28) since the API xyz() is still available in API Level 28 .

minSdkVersion

This value specifies the minimum API Level in which the application is able to run. It’s the minimum requirement. If not specified, the default value is 1.

It is developers responsibility to set a proper value and ensure the application runs properly down to this API Level. This is called backward compatibility.
During development, Lint will also warn developers when trying to use any API above the specified minSdkVersion. It is really important to not ignore these warnings and fix them!
In order to provide backward compatibility, developers can check at runtime the platform version and use a new API on newer versions of the platform and old API on older versions or, depending on the case, using some static libraries which offer backward compatibility.

It is also important to mention Google Play Store uses this value to determinate if an app can be installed on a specific device by matching the device platform version with the app minSdkVersion.
Developers should be really careful when picking this value since backward compatibility is not guaranteed by the platform.
Picking a “right” value for a project is also a business decision since it affects how big is the audience the application is made for. Have a look at the platform distribution.

For example:
App + compileSdkVersion = 26 + minSdkVersion = 22 and using an API xyz() introduced in API Level 26 can run on a device with Android 8 Oreo (API Level 26).

The same app can be installed and run on an older device with Android 5.1 Lollipop (API Level 22), where the API xyz() does not exist. If no backward compatibility has been provided by developers either with runtime checks or some sort of libraries, then the application will crash as soon as it tries to access the API xyz().

targetSdkVersion

This value specifies the API Level on which the application is designed to run.
It doesn’t have to be confused with compileSdkVersion. The latter is only used at compile time and it makes new APIs available to developers. The former, instead, is part of the APK (as well as the minSdkVersion) and changes runtime behavior. It is the way developers can control forward compatibility.
Sometimes there might be some API changes on the underlying system that can affect how an application behaves when is running on a new runtime environment.
Targeting an application to a specific version enables all of those system runtime behaviors, which are dependent on that specific version of the platform. If an app is not ready to support these runtime behavior changes it is likely going to crash.
A simple example is the Runtime Permission, which has been introduced with Android 6 Marshmallow (API Level 23).
It is possible for an application to compile against API Level 23, but targeting API Level 22 if it is not ready yet to adopt the new runtime permission model.
In this way, an application can still be forward compatible without enabling the new runtime behavior.

Anyway, as already mentioned Google is enforcing apps to satisfy new target API level requirements, so it should be a high priority to always update this value.

Putting all together at the end there is a clear relationship

Keep in mind it is highly recommended to compile against the latest API Level and try to have targetSdkVersion == compileSdkVersion.

Источник