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, and tools: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 the v23/styles.xml file, in this example, should be merged into the main styles.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 attribute android: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 your build.gradle file.
  • You can switch usages of app:srcCompat to android:src.
  • Resource references can be used inside vector drawables (e.g. setting fillColor="?attr/colorOnPrimary").
• 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 from com.java.icu, you can migrate to android.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