Skip to main content

Short explanation on Gradle, minSdkVersion, maxSdkVersion, compileSdkVersion and targetSdkVersion in Android

Gradle:

The Android build system compiles app resources and source code, and packages them into APKs that you can test, deploy, sign, and distribute. Android Studio uses Gradle.
The Android plugin for Gradle works with the build toolkit to provide processes and configurable settings that are specific to building and testing Android applications.Gradle and the Android plugin run independent of Android Studio. Gradle architecture is shown below.




Example:
android {
  compileSdkVersion 27
  buildToolsVersion “26.0.2”

  defaultConfig {
    applicationId “com.example.checkyourtargetsdk"
    minSdkVersion 15
    targetSdkVersion 27
    versionCode 1
    versionName “1.0”
  }
}


minSdkVersion:

minSdkVersion is the lower bound for your app. The minSdkVersion is one of the signals the Google Play Store uses to determine which of a user’s devices an app can be installed on.

 your app’s minSdkVersion must be at least as high as your dependencies’ minSdkVersion

When deciding on a minSdkVersion, you should consider the stats on theDashboards, which give you a global look on all devices that visited the Google Play Store in the prior 7 days — that’s your potential audience when putting an app on Google Play .

compileSdkVersion:

compileSdkVersion is your way to tell Gradle what version of the Android SDK to compile your app with.

Therefore it is strongly recommended that you always compile with the latest SDK. You’ll get all the benefits of new compilation checks on existing code, avoid newly deprecated APIs, and be ready to use new APIs.

App can run on device with lower API level if code execution paths do not attempt to invoke any unavailable APIs (except constans which will be simply copied into an app). Value should be always set to the highest stable API level, even if app does not use any API from it. This is due to the fact that some API may be deprecated, stop working. 

targetSdkVersion:

targetSdkVersion is the main way Android provides forward compatibility by not applying behavior changes unless the targetSdkVersion is updated. This allows you to use new APIs prior to working through the behavior changes.
targetSdkVersion is a hint for system on which app is running, indicating which API level is app designed for.

maxSdkVersion:

In docs they stated that they are not effective from 2.1 and also in warning they stated that "declaring the attribute can result in your application being removed from users' devices after a system update to a higher API Level.
An integer designating the maximum API Level on which the application is designed to run.
From Doc: In Android 1.5, 1.6, 2.0, and 2.0.1, the system checks the value of this attribute when installing an application and when re-validating the application after a system update. In either case, if the application's maxSdkVersion attribute is lower than the API Level used by the system itself, then the system will not allow the application to be installed. In the case of re-validation after system update, this effectively removes your application from the device.

Conditions when using the Android SDK Version in build.gradle


- There is also a restriction that minSdkVersion of given module cannot be lower than the value in any dependent module 
eg:  you cannot use version 7.5.0 of Google Play Services library (which minSdkVersion is 9) in an app which has that value set to 8

targetSdkVersion should not be set to value higher than compileSdkVersion 

relationship between the three values
minSdkVersion <= targetSdkVersion <= compileSdkVersion

Also,
minSdkVersion (lowest possible) <= targetSdkVersion == compileSdkVersion (latest SDK) 

This intuitively makes sense — if compileSdkVersion is your ‘maximum’ and minSdkVersion is your ‘minimum’ then your maximum must be at least as high as your minimum and the target must be somewhere in between.


You’ll hit the biggest audience with a low minSdkVersion and look and act the best by targeting and compiling with the latest SDK — a great way to better apps.

AndroidManifest.xml, you’d see a tag such as:

<uses-sdk android:targetSdkVersion=”27" android:minSdkVersion=”7" />

it’ll be ignored when you build with Gradle (although other build systems might certainly rely on it being there).

Reference:



Comments

Post a Comment

Popular posts from this blog

  Mastering Per-App Language Preferences: From Android 10 to Android 13+ One of the most requested features by users is the ability to use an app in a language different from the system language. While Android 13 (API 33) introduced "Per-App Language" settings at the system level, implementing this backward-compatibly for older devices like Android 10 (API 29) used to be a challenge involving manual configuration wrapping. Today, thanks to AppCompat 1.6.0+ , we have a unified, standard way to handle this. Here is the modern guide to implementing seamless language switching. The Architecture: How it Works On Android 13 and above, the system handles the storage and application of your app's locale. On older versions, the AppCompat library manages this behavior by storing your preference in an internal XML file and injecting the resources during the activity lifecycle. Step 1: The Locale Helper Utility Instead of scattering logic across your app, use a clean LocaleHelper o...

Beyond Scanning: Meet the All-in-One AI Document Assistant by Digitify Vision Technology

In an era where efficiency is the ultimate currency, information is scattered everywhere—on physical paper, within QR codes, and inside lengthy digital documents. The challenge isn't just capturing this data; it’s making it work for you. At Digitify Vision Technology , we believe your smartphone should be more than just a camera—it should be a high-performance engine for your daily workflow. Today, we are proud to unveil our most powerful update yet: a total evolution in AI-driven document management. 💡 Key Features of the New Update We’ve bridged the gap between physical information and digital action by integrating advanced vision and audio intelligence into a single, seamless experience. 🔍 Precision Scanning for Everything Our advanced vision engine is now more versatile than ever. Intelligent Document Scanning: Capture crisp, professional-grade scans of physical papers, contracts, or handwritten notes. QR Code Extraction: Instantly scan any QR code to extract text, read URL...
  Optimising Android Launch: Mastering App Startup & The Modern Splash Screen The first few seconds of an app’s life determine a user's first impression. A slow start or a flickering white screen can lead to immediate uninstalls. In this guide, we’ll look at how to streamline your initialisation using the App Startup Library and ensure a seamless visual transition with the Android 12 Splash Screen API (with full backward compatibility for API 29). Part 1: The App Startup Library Traditionally, apps initialised multiple components using separate content providers. This adds overhead and slows down launch time. The Jetpack App Startup library allows all components to share a single content provider, significantly improving performance. Why use it? Performance: Shared content provider reduces overhead. Order: Explicitly set the initialisation sequence. Simplicity: Both library creators and app developers use a unified interface. Part 2: The Modern Splash Screen API Starting ...