Android developers need to keep their apps updated with the latest Android API requirements if they want to publish new apps and app updates on Google Play. One of the important requirements developers need to understand is the requirement to target Android 16, which corresponds to API level 36.
If you are seeing a message that your app must target Android 16 (API level 36) or higher, it means your Android project is using an older target SDK version. Updating the target SDK helps your application meet current Google Play requirements and prepares it for behavior changes introduced in newer versions of Android.
What Does 'App Must Target Android 16 (API Level 36)' Mean?
Android uses API levels to identify platform versions and their available APIs. Android 16 is associated with API level 36. When an app targets API level 36, the developer is telling Android and Google Play that the application has been built and tested with Android 16 behavior and APIs in mind.
The target SDK version is different from the minimum SDK version. The minimum SDK determines the oldest Android version on which your app can run, while the target SDK indicates the Android version your application is designed to target.
| Setting | Meaning |
|---|---|
| minSdk | The oldest Android version supported by your app |
| targetSdk | The Android API level your app is designed and tested to target |
| compileSdk | The Android API level used to compile your application |
Android 16 API Level 36 at a Glance
| Item | Value |
|---|---|
| Android version | Android 16 |
| API level | 36 |
| Target SDK property | targetSdk = 36 |
| Build SDK property | compileSdk = 36 or newer |
| Minimum SDK | Can remain lower depending on your app's compatibility requirements |
Why Is Google Play Requiring Apps to Target Newer Android Versions?
Google regularly increases target API requirements for apps distributed through Google Play. These requirements encourage developers to adopt newer Android security protections, privacy behavior, platform APIs and compatibility changes.
Targeting an older Android API level for a long time can leave an application using outdated platform behavior. Requiring newer target SDK versions helps keep applications aligned with the current Android platform.
- Encourages developers to adopt newer Android platform behavior.
- Helps applications use current security and privacy protections.
- Improves compatibility with newer Android versions.
- Reduces the number of applications targeting very old Android releases.
- Keeps apps distributed through Google Play aligned with current platform requirements.
Does targetSdk 36 Mean My App Only Works on Android 16?
No. Setting targetSdk to 36 does not automatically mean that your application can only run on Android 16. The Android versions supported by your application are primarily determined by minSdk and the APIs and compatibility logic used by your code.
For example, an application can target API level 36 while supporting older Android versions if its minSdk is lower and the application handles version-specific APIs correctly.
How to Check Your App's Target SDK Version
If you use Android Studio with a Gradle-based Android project, you can check the module-level build.gradle or build.gradle.kts file. Look for the targetSdk configuration inside the Android configuration block.
android {
compileSdk = 36
defaultConfig {
applicationId = "com.example.myapp"
minSdk = 23
targetSdk = 36
}
}If your project uses the older Groovy Gradle syntax, the configuration may look slightly different. The important value is the target SDK level used by your application module.
android {
compileSdk 36
defaultConfig {
applicationId "com.example.myapp"
minSdk 23
targetSdk 36
}
}How to Update an Android App to Target API Level 36
Updating an application to Android 16 is more than changing a single number. You should update the SDK configuration, make sure the required Android SDK is installed, rebuild the project and test the application on newer Android versions.
Step 1: Install Android 16 SDK
Open Android Studio and use the SDK Manager to make sure the Android 16 SDK platform and required build tools are available. The exact Android Studio interface can vary between versions, but the SDK Manager is normally available from the Android Studio settings or tools menu.
- Open Android Studio.
- Open the SDK Manager.
- Find the Android 16 SDK Platform.
- Install API level 36 if it is not already installed.
- Apply the changes and allow Android Studio to finish the installation.
Step 2: Set compileSdk to 36 or Newer
Update compileSdk in your Android application module so that your project can compile against the required Android APIs. A typical modern Gradle configuration can use compileSdk = 36.
android {
compileSdk = 36
}Using a newer compile SDK than the minimum required target can also be appropriate when your Android Gradle Plugin and project configuration support it. Always make sure the SDK version is compatible with the rest of your build environment.
Step 3: Set targetSdk to 36
The key change for an Android 16 target requirement is updating the target SDK. In a Kotlin DSL Gradle file, this commonly looks like targetSdk = 36.
defaultConfig {
targetSdk = 36
}After changing targetSdk, do not assume that the application is finished. New target SDK versions can activate behavior changes, so the application should be tested carefully before release.
Step 4: Update Android Gradle Plugin and Dependencies if Necessary
Older Android projects may not be ready to compile against API level 36. If Android Studio reports Gradle, Android Gradle Plugin or dependency compatibility problems, you may need to update your build tools and libraries.
- Check the Android Gradle Plugin version used by your project.
- Check the Gradle wrapper version required by that plugin.
- Update outdated AndroidX libraries when necessary.
- Check third-party SDKs for Android 16 compatibility.
- Resolve compiler and build errors before creating the release bundle.
Step 5: Review Android 16 Behavior Changes
Changing targetSdk can cause your application to opt into behavior changes associated with the newer Android release. These changes can affect areas such as edge-to-edge layouts, permissions, background behavior, security, notifications, screen and window handling, and other platform functionality.
This is why simply changing targetSdk from an older value to 36 and uploading the app without testing can create unexpected UI or runtime problems.
Step 6: Test the App on Android 16
After updating your project, test the application on an Android 16 device or emulator. Pay particular attention to areas of the app that interact directly with the operating system.
- Install the debug build on an Android 16 emulator or physical device.
- Test the application startup and main navigation.
- Check permissions and runtime permission flows.
- Test notifications and background operations.
- Check edge-to-edge layouts and system bars.
- Test camera, storage, location or other device features used by the app.
- Test WebViews and external links if your app uses them.
- Check crashes and Logcat errors.
- Test important flows on older Android versions supported by your minSdk.
Check Your Other Play Console Tracks
Updating the target SDK in your Android project is only part of the process. You should also check the release tracks in Google Play Console. Internal testing, closed testing, open testing and production can each have releases or active versions that were created with an older target SDK.
If an active release in one of these tracks still uses a target SDK below the required level, Google Play Console may continue to report the target API requirement or prevent you from moving forward with certain releases. In some situations, you need to deactivate or pause the affected track release and create a new compliant release targeting the required API level.
- Open Google Play Console and select your application.
- Check the Production track for releases targeting an older API level.
- Check the Open testing track if you use it.
- Check the Closed testing tracks and their active releases.
- Check Internal testing tracks and their active releases.
- Identify releases that were built with a target SDK below the current requirement.
- Create and upload a new Android App Bundle targeting the required API level.
- Deactivate or replace affected older releases where Play Console requires it.
- Review the target API warning again after the changes are processed.
Why You Should Check Internal and Testing Tracks
A common mistake is to update the production build but forget about an older internal or closed testing release. Developers may still have old APKs or app bundles active in testing tracks from earlier development. These releases can cause confusion when Play Console reports that an app or track still has a version targeting an outdated API level.
For example, you might have a production release targeting API 36 while an internal testing track still contains an older release targeting API 35 or below. In that situation, review the affected track and move it to a compliant release or deactivate the old release if it is no longer needed.
| Play Console track | What to check |
|---|---|
| Production | Check the currently distributed production release and rollout versions |
| Open testing | Check active releases targeting an older API level |
| Closed testing | Check every active closed-testing track for outdated releases |
| Internal testing | Check internal releases that may still use an older target SDK |
What Happens If You Do Not Update targetSdk?
If your application does not meet the current Google Play target API requirement, you may encounter restrictions when publishing new applications or updates. Google Play displays target API warnings and requirements in Play Console when an app needs to be updated.
The exact enforcement date and scope can depend on whether you are publishing a new app or updating an existing app, so developers should always check the current Google Play target API requirements for the latest policy information.
Will Updating targetSdk Break My Existing App?
It can expose compatibility problems, but changing targetSdk does not automatically mean your application will break. The main risk comes from behavior changes introduced by newer Android releases that your application has not previously opted into or tested against.
Older applications can contain assumptions about system bars, permissions, background execution, storage, notifications or other Android behaviors. Updating the target SDK is therefore a good opportunity to review those areas.
Common Problems After Updating to API Level 36
| Problem | What to Check |
|---|---|
| UI layout changes | Review edge-to-edge behavior, insets and system bar handling |
| Permission problems | Review runtime permissions and Android version-specific behavior |
| Notification issues | Check notification permissions, channels and background behavior |
| Build errors | Check Android Gradle Plugin, Gradle and dependency compatibility |
| Third-party SDK errors | Update SDKs and check their Android 16 support |
| Background task problems | Review Android background execution restrictions |
| WebView issues | Test WebView pages, JavaScript, storage and navigation |
targetSdk vs compileSdk vs minSdk
One of the most common sources of confusion for Android developers is the difference between compileSdk, targetSdk and minSdk. These three values serve different purposes.
| Property | Purpose | Example |
|---|---|---|
| minSdk | Defines the oldest Android version your app supports | minSdk = 23 |
| targetSdk | Defines the Android behavior your app targets | targetSdk = 36 |
| compileSdk | Defines the Android API used to compile the app | compileSdk = 36 |
For example, you could have minSdk 23, compileSdk 36 and targetSdk 36. In that configuration, the app targets Android 16 while still supporting Android versions back to API level 23, provided the application code and dependencies remain compatible.
Do I Need to Increase minSdk to 36?
No. A requirement to target Android 16 does not normally mean that your minSdk must also be 36. The target API requirement and minimum supported Android version are separate settings.
You can keep a lower minSdk when your application needs to support older Android devices. However, your application must handle API differences correctly and avoid calling newer APIs on older Android versions without appropriate version checks.
Example Android 16 Configuration
A simple modern Android application targeting API level 36 could contain a configuration similar to the following:
android {
namespace = "com.example.myapp"
compileSdk = 36
defaultConfig {
applicationId = "com.example.myapp"
minSdk = 23
targetSdk = 36
versionCode = 1
versionName = "1.0"
}
}Checklist Before Publishing an Android 16 Targeted App
- Install the Android 16 API level 36 SDK.
- Set compileSdk to 36 or a newer supported version.
- Set targetSdk to 36 or a newer supported version.
- Check Android Gradle Plugin and Gradle compatibility.
- Update outdated AndroidX and third-party dependencies.
- Review Android 16 behavior changes.
- Test the app on Android 16.
- Test the app on older Android versions supported by minSdk.
- Check permissions, notifications and background tasks.
- Check edge-to-edge layouts and system bar handling.
- Review Production, Open testing, Closed testing and Internal testing tracks in Google Play Console.
- Replace or deactivate affected releases that use a target SDK below the required level.
- Build a signed Android App Bundle targeting the required API level.
- Upload the bundle to Google Play Console and review the policy status.
Frequently Asked Questions
What API level is Android 16?
Android 16 is API level 36. Developers can use API level 36 when targeting Android 16 in their Android projects.
What is targetSdk 36?
targetSdk 36 tells Android that the application is targeting API level 36 behavior. It is the target SDK value associated with Android 16.
Does targetSdk 36 mean Android 16 is required to install my app?
No. targetSdk 36 does not by itself make Android 16 the minimum supported Android version. The minimum supported version is controlled separately by minSdk.
Can I use compileSdk 36 with a lower minSdk?
Yes. compileSdk and minSdk have different purposes. An application can compile against API level 36 while supporting older Android versions, provided its code and dependencies are compatible with those versions.
Why does Google Play say my app must target Android 16?
Google Play periodically raises target API requirements for applications distributed through the store. If your app targets an older API level than the current requirement, Play Console can ask you to update the target SDK before publishing certain new releases or updates.
Is changing targetSdk to 36 enough?
Changing targetSdk is an important part of the update, but it should not be the only step. You should also compile with a supported SDK, update incompatible dependencies, review Android 16 behavior changes and thoroughly test the application before publishing.
Final Thoughts
The requirement to target Android 16, API level 36, is an important consideration for Android developers publishing applications through Google Play. Understanding the difference between minSdk, targetSdk and compileSdk makes the migration much easier.
If your app currently targets an older Android API level, update the project to a supported target SDK, review Android 16 behavior changes and test the complete application before releasing it. Do not treat the targetSdk change as only a number change because newer Android versions can introduce platform behavior that affects existing applications.
Keeping your Android project updated not only helps satisfy Google Play requirements but also makes it easier to maintain compatibility with newer Android devices and platform features.