Mukesh@gmail.com
Introduction
If you have started building an Android app recently, you have probably come across two settings in your project that mention SDK numbers — compileSdk and targetSdk. Most tutorials tell you to set them to the latest number and move on. But in 2026, that advice can actually cause problems if you do not understand what those numbers mean and what changes between versions.
The conversation around Target SDK 35 vs 36 is particularly important for developers who are either publishing their first app or updating an existing one for Google Play compliance. These two API levels are not just version numbers — they represent different sets of rules, behaviors, and requirements that Android enforces on your app at runtime.
This guide explains the Target SDK 35 vs 36 comparison clearly, without unnecessary technical jargon. You will learn what actually changed, how those changes affect a real Android app, what Google Play requires in 2026, and what you need to do to stay compliant. If you are a new developer trying to understand this before submitting your app, this is exactly the guide you need.
What targetSdkVersion Actually Means
Before comparing Target SDK 35 vs 36 specifically, it helps to understand what the targetSdkVersion setting is doing in the first place.
Every Android app has a file called build.gradle (or build.gradle.kts in newer projects) that contains a few version numbers. One of them is targetSdk. This number tells the Android operating system which version of Android your app was designed and tested for.
When you set a higher targetSdk, you are essentially telling Android to apply the behavior and security rules that were introduced in that version. Android uses this number to decide how strictly to enforce newer platform rules on your app.
Here is a real example to make this concrete. Imagine you are running your app on an Android 14 phone. If your app has targetSdk set to 28 (Android 9), Android will still run your app, but it gives it some older-style permissions and behaviors to stay compatible. The moment you raise targetSdk to 34 or higher, Android starts applying the newer, stricter rules to your app — even on the same device.
This is why the Target SDK 35 vs 36 comparison matters. Each step up in targetSdk brings behavioral changes that can affect how your app behaves, what permissions it needs to declare, and what APIs still work versus which ones are now restricted.
What Is Target SDK 35 (Android 15)
Target SDK 35 corresponds to Android 15, which was the stable release that arrived in late 2024. By 2026, it is well-established, widely documented, and required by Google Play for new app submissions and updates to existing apps.
When you set targetSdk to 35, your app opts into Android 15 behaviors. Here are the most significant ones for new developers to understand.
Edge-to-Edge Display Is Now Enforced
The biggest practical change in Target SDK 35 that affects most developers is edge-to-edge enforcement. On Android 15, apps targeting API 35 are required to draw their content behind the system bars — the status bar at the top and the navigation bar at the bottom.
What this means in practice: if you have a button near the bottom of your screen, it might end up hidden behind the navigation bar if your app is not handling window insets properly. This is a UI issue that affects real users on real devices.
The fix involves using WindowInsetsCompat in your layouts or applying proper padding so your UI elements do not overlap with system-drawn elements. In Jetpack Compose, the Scaffold component handles this automatically when configured correctly.
Health Connect and Health Permissions
Android 15 introduced changes to how apps interact with Health Connect, Google’s unified health data platform. If your app reads or writes health data — step counts, heart rate, sleep tracking — there are new permission declarations required when targeting SDK 35.
Most apps do not touch health data, so this change does not affect the majority of developers. But if you are building a fitness or wellness app, this is something to check carefully in the official documentation.
Predictive Back Gesture Changes
The predictive back gesture — where you can peek at the previous screen before fully swiping back — became more consistent and more strictly enforced in Android 15. Apps targeting SDK 35 need to properly implement OnBackPressedCallback or use the standard back navigation patterns.
If your app still uses the deprecated onBackPressed() method without migrating to the newer back handling API, you will see inconsistent or broken back navigation behavior on Android 15 devices.
What Is Target SDK 36 (Android 16)
Target SDK 36 corresponds to Android 16. In 2026, Android 16 is either newly released or in its final stages of stable rollout, depending on when exactly you are reading this. This is the newer of the two in the Target SDK 35 vs 36 comparison, and it brings additional changes on top of everything in API 35.
Google Play has announced that apps targeting SDK 36 will be required for new submissions and updates by a specific deadline in 2026. Staying ahead of this requirement is one of the main reasons new developers should understand what changes with API 36.
Large Screen and Foldable Adaptability
One of the defining themes of Android 16 is stronger enforcement around app adaptability for large screens, tablets, and foldable devices. The Android ecosystem in 2026 includes a significant and growing number of foldable phones and tablets.
Apps targeting SDK 36 are expected to properly handle multi-window mode, screen size changes, and different aspect ratios. Android 16 enforces display cutout handling more strictly, meaning apps that ignore the notch or camera cutout area may experience layout issues on newer devices.
The practical implication for new developers: test your app on at least one tablet-sized emulator before publishing. Use responsive layouts that use weight-based sizing or adaptive padding rather than fixed pixel dimensions.
Stricter Media Permission Handling
Android 16 continues the trend of restricting broad media access. Instead of requesting READ_EXTERNAL_STORAGE which allows reading all files, apps targeting SDK 36 are pushed further toward using the Photo Picker API for image selection and scoped storage for file access.
If your app allows users to select a profile photo or attach an image, you should be using Android’s built-in Photo Picker rather than a custom file browser. It requires no runtime permissions and works for users regardless of Android version through backward compatibility.
Health and Fitness Data API Updates
Building on the Health Connect changes in Android 15, Android 16 adds new data types and revises how certain health permissions are requested and granted. If health data is part of your app, the official Health Connect documentation is the authoritative source for what is new at API 36.
Java 21 Language Features
Android 16 expands support for Java 21 language features when building with AGP (Android Gradle Plugin) 8.5 or newer. This includes better virtual thread handling and more expressive language syntax. While this does not affect most beginner apps directly, it is a welcome improvement for developers coming from a Java background.
The Core Difference Between Target SDK 35 vs 36
When you look at Target SDK 35 vs 36 side by side, the overarching pattern is clear. API 35 focuses heavily on display and UI enforcement — particularly edge-to-edge layouts and predictive back navigation. API 36 focuses on broader ecosystem adaptability — large screens, foldables, and tighter permission boundaries.
Neither version removes APIs in a way that breaks most standard apps. The majority of new developers building straightforward apps — a to-do list, a recipe browser, a simple calculator — will find that upgrading from targetSdk 35 to 36 requires relatively minor changes.
The developers who need to pay closer attention are those building apps with:
Custom navigation implementations that override system back behavior. File access features that use legacy storage permissions. Layouts that use fixed sizes without considering different screen dimensions. Health, fitness, or sensor data features.
For everyone else, the upgrade path from 35 to 36 is manageable with a bit of testing.
Google Play Requirements: What You Actually Need to Submit in 2026
Understanding the Target SDK 35 vs 36 conversation is only fully useful when you understand what Google Play actually requires.
Google Play updates its target API level requirements annually. The general pattern has been consistent for several years now: new app submissions and updates to existing apps must target within one or two API levels of the latest stable Android release.
In 2026, for new app submissions, Google Play requires targeting at least SDK 35. By a deadline later in 2026, API 36 targeting will likely become mandatory for new apps and updates, based on Google’s established annual cycle.
For existing apps that have not been updated, Google Play may restrict their visibility in the store or prevent them from being installed on newer Android devices if they target an API level that is too far behind.
The practical advice: if you are submitting a new app in 2026, target API 35 at minimum right now. If you have time before your submission, evaluate what API 36 requires for your specific app and consider targeting it from the start. It is easier to start on a higher API level than to upgrade later.
For the most current and official Google Play target API level requirements, check the Google Play policy page which is updated whenever requirements change.
How to Update Your targetSdk in an Android Project
Changing the targetSdk value in an Android project is a simple edit. Open your app-level build.gradle file. It looks something like this:
android { compileSdk 35
defaultConfig {
applicationId "com.example.myapp"
minSdk 24
targetSdk 35
versionCode 1
versionName "1.0"
}
}
To target API 36, change both compileSdk and targetSdk to 36. You may also need to update your Android Gradle Plugin version and your SDK Platform. Install the API 36 platform through the SDK Manager by running:
sdkmanager “platforms;android-36”
After making the change, sync your project with Gradle files. Android Studio will show a Sync Now prompt at the top, or you can go to File and then Sync Project with Gradle Files.
Then run your app on an emulator or device running Android 16 and look for any warnings or visual issues. The lint tool in Android Studio also flags many Target SDK 35 vs 36 related compatibility issues automatically.
Practical Testing Advice for New Developers
One mistake many new developers make when dealing with Target SDK 35 vs 36 is updating the number and assuming everything is fine without actually testing.
The targetSdk number changes what Android enforces at runtime. Issues caused by a higher targetSdk often do not appear as build errors — they appear as visual glitches, crashes on specific devices, or permission dialogs that behave differently than expected.
Here is a practical testing routine for handling the Target SDK 35 vs 36 upgrade:
Create an emulator running Android 15 and test your app with targetSdk 35. Look specifically at the bottom of your screen — does anything overlap with the navigation bar? Does the back gesture work consistently throughout the app? Does any screen look cut off at the edges?
Then create an emulator running Android 16 and repeat the same tests with targetSdk 36. Pay attention to how your app looks in landscape orientation. Resize the emulator window to simulate a foldable device. Check any features that access files, images, or device sensors.
If you find issues, fix them before bumping the targetSdk value in production. It is better to ship at targetSdk 35 with a working app than to rush to 36 and have users experiencing crashes.
minSdk, compileSdk, and targetSdk: Clearing Up the Confusion
New developers often mix up three SDK-related settings in their Gradle files. Since we are already talking about Target SDK 35 vs 36, it is worth clarifying all three quickly.
minSdk is the minimum Android version your app supports. Set it to 24 or 26 for a reasonable balance between compatibility and access to modern APIs. This controls which devices can install your app at all.
compileSdk is the version of the Android framework your code is compiled against. It should always be the latest stable version. It does not affect which devices can run your app — only which APIs you can reference in your code.
targetSdk is what we have been discussing throughout this guide. It controls the behavioral rules Android applies to your app at runtime. This is the number that determines your Google Play compliance and determines which platform behaviors are active.
All three numbers are separate and serve different purposes. The most common mistake beginners make is thinking that raising minSdk to 35 means their app targets Android 15. It does not — that is what targetSdk is for. Raising minSdk to 35 would mean your app cannot install on any device running Android 14 or older, which would exclude a massive portion of users.
A Quick Summary of Changes by API Level
Here is a plain-language summary of the most relevant Target SDK 35 vs 36 differences for everyday app development:
Edge-to-edge display enforcement arrived in API 35. If your app’s UI is being clipped by system bars, this is why. Use WindowInsets padding in your layouts.
Predictive back gesture enforcement also landed in API 35. Migrate away from onBackPressed() to the newer back callback APIs.
Large screen and foldable adaptability requirements became stricter in API 36. Use flexible layouts that adapt to different screen sizes.
Media access and Photo Picker usage is pushed further in API 36. Avoid legacy storage permissions when handling images.
Java 21 language feature support improved in API 36 with AGP 8.5 and later.
For most simple apps, these changes require one to two hours of testing and minor adjustments. The edge-to-edge change in API 35 is the one that visually affects the most apps and deserves the most attention.
Final Conclusion
The Target SDK 35 vs 36 comparison comes down to two different waves of enforcement in the evolving Android platform. API 35 drew a firm line on UI behavior — specifically making edge-to-edge layouts and modern back gesture handling non-negotiable. API 36 extended that enforcement outward, focusing on how well apps adapt to the increasingly diverse Android device landscape including foldables and large screens.
For a new developer in 2026, the most important takeaway from the Target SDK 35 vs 36 discussion is this: do not just change the number and ship. Each API level brings runtime behavioral changes that need to be tested on actual emulators or devices running those Android versions. A targetSdk bump is a trigger for a testing session, not just a configuration edit.
Start with API 35 as your baseline, understand the edge-to-edge and back navigation requirements, test thoroughly, and then evaluate what API 36 requires for your specific app’s feature set. Building that habit early will save you from user-reported issues and Google Play compliance rejections down the road.
For the most up-to-date behavior changes per API level, the official Android API differences report is the most detailed technical reference available.
