minSdk Upgrade Guide
Introduction
Increasing the minSdkVersion of your Android app brings many technical benefits, by enabling a simpler development process along with security advantages. With each increase to the minSdkVersion, fewer users will be able to use your app, so it is important to weigh the technical benefits against the drawback of losing users. It’s also worth checking this segmentation for your app specifically, as the distribution of Android versions can vary by region.
Cleaning up your codebase
After increasing the minSdkVersion
in your build.gradle
, the first step is in cleaning your codebase is to identify and remove all obsolete code and resources. This can be done automatically by running Gradle lint, either locally or as part of a CI build. The lint check ObsoleteSdkInt
should find any cases of code and resources rendered obsolete by the increased minSdk version. Alternatively, you could check manually:
- Search your codebase for usages of
BUILD.VERSION_CODES
,Build.VERSION.SDK_INT
,@RequiresApi
,@TargetApi
, andtools:targetApi
to check for spots where your code branches depending on the SDK version. - Check for qualified resources; for example, if raising your minSdkVersion from 22 to 23, the file
v23/styles.xml
could be removed. Remember that the OS will choose which resource to use by selecting the highest numbered directory compatible with the device’s SDK level. So thev23/styles.xml
file, in this example, should be merged into the mainstyles.xml
file rather than simply deleted. - Search for instances of
tools:ignore="UnusedAttribute"
in XML files; they might be possible to remove, e.g. for the intent filter attributeandroid:autoVerify
with an minSdk of 23 or higher.
This rest of this blog post will focus mostly on new SDK features that become usable with a minSdk increase, as well as common hacks that become obsolete with an increased minSdk, but may not be guarded by an SDK level check that is easily searched for. Each section in the list below lists the cleanups enabled by an increase to the respective minSdkVersion or higher.
14 (Ice Cream Sandwich)
VectorDrawableCompat
is supported from SDK 14 and up - you can replace your PNG files with vector assets.
19 (4.4 - 4.4.4 / KitKat)
- Make use of the latest AndroidX library versions after their minSdk was increased from October 2023 onwards.
21 (5.0 / Lollipop)
- TLS 1.2 is supported. In case you added a workaround to support TLS on older Android versions, it can be removed.
- The multidex library can be removed.
- You can use Jetpack Compose in your project.
23 (6.0 / Marshmallow)
- App links are enabled from Android 6.0 and up - so with minSdk of 23 or higher, you can assume that all target devices will handle verified links without showing the disambiguation interface.
24 (7.0 / Nougat)
- Full support for vector drawable features, without using backward compatibility:
- You can remove
vectorDrawables.useSupportLibrary = true
from yourbuild.gradle
file. - You can switch usages of
app:srcCompat
toandroid:src
. - Resource references can be used inside vector drawables (e.g. setting
fillColor="?attr/colorOnPrimary"
).
- You can remove
- Support for the Vulkan 3D APIs.
- The ICU4J libraries (which provide Unicode and internationalization support) are available from the
android.icu
package. In case your app imports fromcom.java.icu
, you can migrate toandroid.icu
to reduce the .apk size. - If your app is using a custom
X509TrustManager
(e.g., to trust an unsigned certificate for test servers in debug builds), you should migrate it to use a declarative Network Security Config, reducing the possibility of programmatic errors.
25 (7.1 / Nougat)
- SDK 25 added support for shortcuts. In case your app uses them, make sure to merge the code into the main source set, e.g., from
xml-25/shortcuts.xml
.
26 (8.0 / Oreo)
- Support for Java APIs
java.time
is enabled - this means that you may no longer need to use a backward compatibility solution for this API, e.g., desugaring or ThreeTen