SYSONLINE
SDK36 · MIN 24
KOTLIN2.0
UTC07:37:16
UP00:01
MOD · ARTICLE · BEST PRACTICESS/N · AX-TARGETPUBLISHED
Best PracticesJul 28, 20269 MIN

API 36 Is Due August 31: The Android 16 Changes That Break Real Apps

Google Play requires API 36 for new apps and updates from August 31, 2026. Edge-to-edge, predictive back and large screens are where migrations break.

By Rocky Elsalaymeh · Founder & Principal Consultant, Strategia-X

A Build Number That Changes Behaviour

Every summer the same ticket appears in Android backlogs: "Bump targetSdk." It gets estimated as a one-line change, because in the build file it is one. Then it lands in a release, and the release is the first one where the platform treats your app differently. This year the date is fixed. Google Play's target API requirements say: "Starting August 31, 2026: New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play; except for Wear OS, and Android Automotive OS apps, which must target Android 15 (API level 35) or higher, and Android TV and Android XR apps, which must target Android 14 (API level 34) or higher." There is a pressure valve, "you will be able to request an extension to November 1, 2026 if you need more time", but an extension moves the deadline; it does not remove the work. The penalty for doing nothing is not removal, which is why teams underestimate it. Apps already on the store keep their current users. But "existing apps must target Android 15 (API level 35) or higher to remain available to new users on devices running Android OS higher than your app's target API level." Miss the bar long enough and the newest phones, the ones your future users are buying, stop seeing your listing. The behavior changes are the real work, and they split into two groups that need different treatment:
ChangeApplies toWhere to look
Edge-to-edge opt-out removedApps targeting 36Every screen with bars, sheets or bottom buttons
Predictive back, onBackPressed not calledApps targeting 36Every custom back handler
Orientation and resizability ignored at 600dp+Apps targeting 36Manifest locks, fixed layouts
elegantTextHeight ignoredApps targeting 36Custom text metrics
Job runtime quota, broadcast priorityAll apps on Android 16WorkManager, ordered broadcasts

Edge-to-Edge: The Escape Hatch Is Welded Shut

Android 15 made edge-to-edge the default: "Apps are edge-to-edge by default on devices running Android 15 if the app is targeting Android 15 (API level 35)." Many teams responded by setting the opt-out attribute and moving on. That attribute is now dead weight. From the Android 16 behavior changes: "For apps targeting Android 16 (API level 36), R.attr#windowOptOutEdgeToEdgeEnforcement is deprecated and disabled, and your app can't opt-out of going edge-to-edge." The breakages are predictable, and a screen-by-screen audit finds them fast: a toolbar title under the status bar, a "Pay now" button under the gesture navigation bar where the swipe-home gesture steals the tap, a text field hidden by the keyboard, a bottom sheet whose last row cannot be reached. In Compose the fix is mostly discipline rather than code. Scaffold already computes insets for its bars and hands them to you as innerPadding; the bug is almost always content that ignores it. Content that should draw behind the bars (maps, camera previews, hero images) does so on purpose, and only its *controls* take the safe-drawing insets. One rule covers most of it: backgrounds go edge to edge, touch targets never do.
kotlin
class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        enableEdgeToEdge()
        super.onCreate(savedInstanceState)
        setContent {
            AppTheme {
                Scaffold(bottomBar = { CheckoutBar() }) { innerPadding ->
                    // The classic bug: ignoring innerPadding puts the last rows under the bar.
                    OrderList(contentPadding = innerPadding)
                }
            }
        }
    }
}

@Composable
fun CameraScreen() {
    Box(Modifier.fillMaxSize()) {
        CameraPreview(Modifier.fillMaxSize())               // behind the bars, deliberately
        ShutterControls(
            Modifier
                .align(Alignment.BottomCenter)
                .windowInsetsPadding(WindowInsets.safeDrawing) // controls stay tappable
        )
    }
}

Predictive Back: onBackPressed Goes Silent

This is the change most likely to ship a real bug, because the failure is silent. Per the behavior changes page, for apps targeting API 36 on Android 16 devices, "the predictive back system animations (back-to-home, cross-task, and cross-activity) are enabled by default. Additionally, onBackPressed is not called and KeyEvent.KEYCODE_BACK is not dispatched anymore." Read the second sentence again. Every "are you sure you want to discard this draft?" dialog implemented in onBackPressed() stops firing. The user swipes back, the draft is gone, and no test fails, because the code that would have run simply is not called. There is a temporary opt-out, setting android:enableOnBackInvokedCallback="false" on the application or activity, and the page frames it as exactly that: temporary. The migration path is the predictive back guide: "the backward compatible OnBackPressedCallback in AndroidX Activity 1.6.0 or higher API, or using the new OnBackInvokedCallback platform API." A useful guarantee from the same page: "OnBackPressedCallback is always called regardless of the value of android:enableOnBackInvokedCallback," so migrating to it is safe before and after you remove the opt-out. The design rule that makes predictive back work: enable a callback only while there is something to intercept. An always-enabled callback tells the system your app will handle every back gesture, so the system cannot preview the back-to-home animation. Toggle it with the state it protects. If you only need to *observe* back (analytics, logging), Android 16 offers an observer: "Use OnBackInvokedCallback with PRIORITY_SYSTEM_NAVIGATION_OBSERVER. This creates an observer callback that doesn't consume the back event."
kotlin
// Before: never called when targeting API 36 on an Android 16+ device.
override fun onBackPressed() {
    if (editor.hasUnsavedChanges) showDiscardDialog() else super.onBackPressed()
}

// After (Views): enabled only while there is something to protect.
private val discardGuard = object : OnBackPressedCallback(false) {
    override fun handleOnBackPressed() = showDiscardDialog()
}

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    onBackPressedDispatcher.addCallback(this, discardGuard)
    editor.onDirtyChanged = { dirty -> discardGuard.isEnabled = dirty }
}

// After (Compose): same rule, expressed as state.
@Composable
fun EditorScreen(state: EditorState, onDiscardRequest: () -> Unit) {
    BackHandler(enabled = state.hasUnsavedChanges) { onDiscardRequest() }
    EditorContent(state)
}

Large Screens: Your Orientation Lock Is Ignored

The third change is the one with the longest tail. "For apps targeting Android 16 (API level 36), orientation, resizability, and aspect ratio restrictions no longer apply on displays with smallest width >= 600dp." Games declared through android:appCategory are exempt, and a temporary opt-out exists through a manifest property, but Google is explicit that "the opt-out is temporary and won't apply when targeting API level 37." The Android 17 page confirms it: "Android 17 removes the temporary developer opt-out for orientation and resizability restrictions on large screen devices that was provided in Android 16." For this deadline, the pragmatic path is to use the opt-out if you must and start the real work in parallel, because Play's schedule for the next step is already published: new apps and updates must target API 37 "in August 2027." We covered the full playbook (window size classes, canonical layouts and state that survives a fold) in Your Phone App Is Already a Tablet App.

The Quieter Changes That Still Cost a Day

The headline changes get the attention. These are the ones that produce a confusing bug report two weeks after release:
ChangeWhat the docs sayWhere it bites
Elegant text height"The attribute will be ignored once your app targets Android 16."Custom line heights, clipped text in fixed-height views
Fixed-rate scheduling"At most one missed execution of scheduleAtFixedRate is immediately executed when the app returns to a valid lifecycle."Code that relied on a burst of catch-up runs
Safer intentsStricter matching is opt-in through intentMatchingFlagsWorth enabling deliberately, not discovering later
Job runtime quota (all apps)Jobs that start while the app is visible and continue after it is not "will adhere to the job runtime quota"WorkManager and DownloadManager work started from the foreground
Broadcast priority (all apps)Delivery order by priority "across different processes will not be guaranteed"Ordered broadcasts used as a cross-app chain
The last two rows come from Google's changes for all apps page, which means they reach your users on Android 16 devices whether or not you bump targetSdk. The quota change "impacts tasks scheduled using WorkManager, JobScheduler, and DownloadManager." If a long upload was started as ordinary work while the user was watching and has quietly relied on staying alive after they leave, this is the release where it starts getting cut off; user-initiated data transfer jobs are the documented home for that work.

A Plan That Fits Before the Deadline

Five weeks is enough if the work is sequenced, and too little if it is discovered in QA. The order that minimises surprise: 1. Branch and bump today. Raise targetSdk to 36 on a branch, run the app on an Android 16 emulator and a large-screen profile, and write down everything that looks wrong before fixing anything. The list is your estimate. 2. Back handling first. Search the codebase for onBackPressed and KEYCODE_BACK. Every hit is a silent data-loss bug under API 36. Move each to an OnBackPressedCallback or BackHandler that is enabled only while it has something to protect. 3. Edge-to-edge audit. Walk every screen with a top bar, bottom bar, bottom sheet, text input or full-bleed media. Delete the opt-out attribute so the build tells you the truth. 4. Decide on large screens. Remove orientation locks where you can; apply the temporary opt-out where you cannot, with a ticket that names API 37 as its expiry. 5. Sweep the quiet changes. Text metrics, fixed-rate timers, foreground-started jobs, ordered broadcasts. 6. Ship behind a staged rollout. A target bump is exactly the kind of release that deserves a 1% canary: the device matrix is where these changes differ. Request the November 1 extension early if you need it; the Play Console help page says extension forms arrive "later this year." But plan to ship on August 31. An extension is insurance, not a schedule.
MOD · TAKEAWAYS6 POINTSSUMMARY

Key Takeaways

  1. 1Google Play requires new apps and updates to target API 36 from August 31, 2026, with an extension available to November 1, 2026.
  2. 2For apps targeting API 36, the edge-to-edge opt-out is deprecated and disabled: backgrounds go edge to edge, touch targets take safe-drawing insets.
  3. 3onBackPressed is no longer called and KEYCODE_BACK is not dispatched; move back handling to OnBackPressedCallback or BackHandler, enabled only while it has something to intercept.
  4. 4Orientation and resizability locks are ignored on 600dp+ displays for API 36; the temporary opt-out ends at API 37, which Play requires in August 2027.
  5. 5The job runtime quota and cross-process broadcast priority changes apply to all apps on Android 16, whatever their targetSdk.
  6. 6Bump on a branch first, fix back handling before anything else, and ship the target bump behind a staged rollout.
MOD · FAQ3 ENTRIESANSWERED

Frequently Asked

When must Android apps target API 36 on Google Play?

New apps and app updates must target Android 16 (API 36) from August 31, 2026. Wear OS and Android Automotive OS apps need API 35, Android TV and Android XR apps need API 34, and an extension to November 1, 2026 can be requested.

Why does my back confirmation dialog no longer appear on Android 16?

For apps targeting API 36 on Android 16 devices, onBackPressed is not called and KEYCODE_BACK is not dispatched. Move the logic to OnBackPressedCallback or Compose BackHandler.

Can I still opt out of edge-to-edge?

Not when targeting API 36: windowOptOutEdgeToEdgeEnforcement is deprecated and disabled. It still works if the same app runs on an Android 15 device.

MOD · BUILD · NEXTS/N · AX-CTA-0001READY

Ready to architect your next Android app?

ANDROID-ARCHITECT generates production-ready Kotlin code, architecture blueprints, and CI/CD configurations from plain-language descriptions. Start building for free.

ANDROID-ARCHITECT · CONSOLE
S/N · AX-1A-00001
STRATEGIA-X · ENGINEERED · IN · CALIFORNIA