Android 16 Compatibility Testing: ADB, Compatibility Toggles & Debugging

Installing your app on a device running the newest Android version is not the same as testing the newest Android version. A build running on Android 16 behaves under one set of platform changes, and a subset of those changes only switches on once your targetSdkVersion reaches 36. Two test questions hide inside one device.

That distinction is what makes Android 16 compatibility testing practical. Google ships a mechanism that turns individual behaviour changes on and off for a single app, without editing the manifest or recompiling. It is the compatibility framework, reachable from Developer Options and ADB. Used well, it turns "targeting 36 broke something" into "change 357141415 is responsible for this one screen".

This guide covers that workflow: the kinds of compatibility changes, what the framework can and cannot toggle, the exact ADB commands, what CompatibilityChangeReporter writes to Logcat, and how to produce a report someone else can act on. It assumes you already know your app must reach API 36 — Google Play's Android 16 target API requirements cover that policy side.

What Is Android App Compatibility Testing?

Platform compatibility changes come in two shapes, and the difference decides how you test them.

Changes that affect all apps apply whenever the app runs on that Android version, whatever its target SDK is. Android 16's JobScheduler quota changes are of this kind. If you install your existing build on Android 16 and a background job stops running on schedule, that is an all-apps change, and nobody raised a target SDK to cause it.

Changes gated by targetSdkVersion switch on only when your app declares the relevant API level or higher. Edge-to-edge enforcement, the large-screen orientation and resizability rules, and the fixed-rate scheduling change are in this group for apps targeting 36 — the changes that arrive as a batch the week you bump the target, which is why teams mistake a platform shift for a regression they introduced.

None of this is Google Play submission compliance. Compliance asks whether the uploaded artifact declares the required target level; compatibility testing asks whether the app still behaves correctly under the platform changes it will meet in the field. An app can pass the first and fail the second in the same release.

What Is the Android Compatibility Framework?

The compatibility framework is the part of the platform that decides, per app, whether a behaviour change is active. Google introduced the developer tooling around it in Android 11: the ability to turn breaking changes on and off individually through Developer Options or ADB.

The important sentence is in Google's own documentation: because the platform adapts its internal logic, you do not need to change your targetSdkVersion or recompile your app to perform basic testing. That is what makes the tool useful before a migration rather than after it — you can force a gated change on, watch what breaks, and fix it while the app still declares the old target.

Two constraints decide whether the toggles are available at all. The app must be debuggable — a release build installed from Play does not expose them. The device build matters: on a public user build a debuggable app can toggle changes gated by targetSdkVersion, but changes that apply to all apps cannot be toggled there, whereas a preview or beta device build allows both. Understand this before planning a session, because it determines which questions the framework can answer on the hardware you have.

How to Open App Compatibility Changes in Android 16

Google documents this path for a device running Android 16:

1. Build and install a debuggable variant of your app on the Android 16 device or emulator.
2. If Developer Options are not already on, enable them.
3. Open Settings and navigate to System › Advanced › Developer options › App Compatibility Changes.
4. Select your app from the list.
5. Review the groups: changes enabled by default, changes enabled only for apps targeting a level (shown as something like "Enabled for targetSdkVersion >= 36"), and a Default Disabled Changes section.
6. Find the one change you intend to test and use its switch.
7. The app is killed when you toggle, so relaunch it deliberately rather than being surprised.
8. Reproduce the affected workflow, then record the result.

Two caveats. Menu wording and placement vary between manufacturers and Android versions. And toggling a change you do not understand is a bad habit: read its description in the Android 16 compatibility framework list first, because the Default Disabled section exists for changes that are not meant to be flipped casually.

How to Test Android 16 Compatibility Changes Using ADB

Everything the Developer Options screen does, ADB can do faster and scriptably. Confirm the device is visible first:

adb devices

The rest follows the framework's own syntax. These four commands are the core, and each accepts either the numeric change ID or the change name:

# whole-device view of every change, enabled and disabled
adb shell dumpsys platform_compat

# force one change on for one package
adb shell am compat enable (CHANGE_ID|CHANGE_NAME) PACKAGE_NAME

# force one change off for one package
adb shell am compat disable (CHANGE_ID|CHANGE_NAME) PACKAGE_NAME

# drop the override and return to the default state
adb shell am compat reset (CHANGE_ID|CHANGE_NAME) PACKAGE_NAME

In those commands, PACKAGE_NAME is the applicationId of the installed build — the value Play Console shows as the package name, for example com.example.notes. CHANGE_ID is the numeric identifier from the official list, and CHANGE_NAME is its constant, such as UNIVERSAL_RESIZABLE_BY_DEFAULT. Either works; the name reads better in a script, the ID pastes neatly from a log line.

Android 16 also documents two change-specific overrides for the JobScheduler quota work, which you can enable for your package when diagnosing background work:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS PACKAGE_NAME
adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS PACKAGE_NAME

Standby-bucket behaviour uses commands that take a bucket argument rather than an ID:

adb shell am set-standby-bucket PACKAGE_NAME active|working_set|frequent|rare|restricted
adb shell am get-standby-bucket PACKAGE_NAME

These commands have two limits. They act on a package on a connected device, so they are useless against a release build installed by a user — the debuggable requirement applies to ADB exactly as it does to the on-screen switches. And a change the device build does not allow you to toggle simply will not accept the override; that is the restriction table above, not a broken command.

Understanding Android 16 Compatibility Change IDs

A change ID is a unique number identifying one behaviour change inside the framework — not a document section, an API level or a version. The same ID is what the toggle screen lists, what dumpsys platform_compat prints, what Logcat reports, and what am compat accepts, which is what makes it a usable thread to pull on when a feature misbehaves.

These verified Android 16 entries come from Google's official list, with their documented default states:

Three states appear in the reporter, and one is easy to misread. ENABLED means the change is active and will affect the app if it calls the affected APIs. DISABLED means it is not affecting the app — and Google notes that a change disabled because the app's target is below the threshold will switch on by itself once the target rises. LOGGED means the framework reports the change but cannot toggle it; it may still affect behaviour, and many such changes are experimental. Do not assume LOGGED is harmless without reading the description.

Always verify a change against the official Android 16 list rather than a list in a blog post, including this one. The set of changes and their default states differ between Android releases, so read the list for the version you are testing.

How to Find Compatibility Problems in Logcat

The first time your app calls an API affected by a change, the system writes a line tagged CompatibilityChangeReporter. Google's documented shape is:

D CompatibilityChangeReporter: Compat change id reported: 194833441; UID 10265; state: ENABLED

That is the format from the documentation, not output captured from a device during this article. The change ID tells you which behaviour is in play, the UID identifies the app — useful when several builds are installed — and the state tells you whether the change is active.

To cut the noise, use Logcat's documented tag filter syntax with *:S as an allowlist, so only the reporter tag is shown:

adb logcat CompatibilityChangeReporter:D *:S

In Android Studio's Logcat window the same idea works through the query field: filter on tag:CompatibilityChangeReporter, and add package:mine to keep only your own app's entries.

Android 16 Changes Worth Testing

Not every Android 16 change applies to every app. The four below most often produce a visible defect in an app that was working the day before. The summary table then adds JobScheduler quota and standby-bucket behaviour, which matters only if your app schedules background work.

Edge-to-edge enforcement

For apps targeting 36, the opt-out attribute R.attr#windowOptOutEdgeToEdgeEnforcement is deprecated and disabled, so the app cannot avoid drawing edge to edge. Note the version split Google documents: targeting 36 on an Android 15 device, the attribute still works; on an Android 16 device it does not. That difference alone can make a bug appear on one test device and not another.

What to inspect: content under the status or navigation bar, a scrollable view whose last item is unreachable, toolbars without insets, bottom buttons behind the gesture bar, and dialogs that apply insets twice.

Predictive back

When an app targets 36 and runs on Android 16, the predictive back animations — back-to-home, cross-task and cross-activity — are enabled by default. Google states that onBackPressed is not called and KeyEvent.KEYCODE_BACK is no longer dispatched. The documented options are to update to the supported back navigation APIs, or to set android:enableOnBackInvokedCallback to false on the <application> or <activity> as a temporary opt-out.

What to test: back from a nested screen, back with a dialog open, back after an unsaved edit, and back twice quickly. The symptom is rarely a crash — usually a screen that no longer exits, or a confirmation prompt that never appears.

Large-screen adaptive layouts

For apps targeting 36, orientation, resizability and aspect ratio restrictions no longer apply on displays with smallest width of 600dp or more: the app fills the window regardless of the orientation it requested, and pillarboxing is not used. Fixed-portrait layouts are the ones that break.

Google documents exceptions and a temporary opt-out — the android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY property at activity or application level — with a warning that it will not apply when targeting API 37. Treat it as time bought, not a fix.

Background scheduling behaviour

The fixed-rate change is narrower than headlines suggest. Before targeting 36, when scheduleAtFixedRate missed executions because the app was outside a valid process lifecycle, all of them ran when it returned. When targeting 36, at most one missed execution runs. Google also documents JobScheduler quota adjustments that apply to all apps on Android 16, with stop reasons available through WorkInfo.getStopReason() or JobParameters.getStopReason().

What to test: a job that should fire while the app is backgrounded, then whether it fires once or in a burst on return. If your app does not use these APIs, none of this applies to it.

A Practical Android 16 Compatibility Testing Workflow

This is a recommended sequence, not a Google certification process. It is ordered so the cheapest evidence arrives first.

1. Write down the Android versions you support and the current targetSdkVersion of the build you are testing.
2. Produce a debuggable build of that exact commit, so results are reproducible.
3. Install it on an Android 16 emulator or physical device and run your normal smoke tests.
4. Review the all-apps changes for that release and test each against the features you ship.
5. Review the changes gated by API 36 and list the ones your code could plausibly hit.
6. Enable those changes one at a time and reproduce the affected flow after each.
7. When something fails, note the change ID, then disable that change and retest to confirm causation.
8. Read Logcat with the reporter tag filtered, after a force stop, to see which changes were actually reached.
9. Fix the underlying behaviour rather than pinning the toggle.
10. Reset the override and retest with the change at its default state.
11. Repeat your regression suite on at least one older supported API level.
12. Only then raise targetSdkVersion to 36, and repeat the smoke tests against the new default set.
13. Build the release AAB and confirm the merged manifest carries the intended target.
14. Record the results in a report that names devices, API levels and change IDs.

Android 16 Compatibility Testing Matrix

A starting checklist for a build that targets 36. It is a recommended matrix for your own regression pass, not an official Google test suite.

Common Compatibility Testing Problems

Testing Android 16 on Emulator vs Physical Devices

Use both where the project allows it. Emulators make breadth cheap, physical devices make results believable, and a defect that only reproduces on hardware is exactly the kind that reaches production. Our real device testing guide covers how to pick the matrix rather than guessing.

How to Write a Useful Compatibility Test Report

A compatibility defect is only actionable if the next person can recreate the state you were in, which means recording the environment, the toggle state and the evidence together.

Frequently Asked Questions

What is the Android compatibility framework?

The platform mechanism that decides per app whether a behaviour change is active, driven from Developer Options or ADB. It lets you test one change at a time instead of meeting all of them at once.

Can I test Android 16 behaviour without changing targetSdkVersion?

Yes for basic testing. Google states the platform adapts its own logic, so you can force individual gated changes on without editing the manifest or recompiling.

Do compatibility toggles require a debug build?

Yes. A debuggable build variant is required; release builds do not expose the toggles, and ADB overrides do not work on them either.

How do I open App Compatibility Changes?

On Android 16: Settings › System › Advanced › Developer options › App Compatibility Changes, then select your app. Manufacturer builds sometimes place it slightly differently.

Can ADB control Android compatibility changes?

Yes. am compat enable, am compat disable and am compat reset take a change ID or name plus a package name, and dumpsys platform_compat lists the device's changes.

What is a compatibility change ID?

A unique numeric identifier for one behaviour change. The same ID appears in the toggle list, in dumpsys output, in Logcat and in ADB commands, so one issue can be followed across all four.

How do I find compatibility issues in Logcat?

Filter on the CompatibilityChangeReporter tag — for example adb logcat CompatibilityChangeReporter:D *:S — and force stop the app first, because each change is reported at most once per process.

Should I test on both emulator and real devices?

Yes where possible. The emulator gives breadth across API levels and window sizes; a physical device gives real insets, gesture navigation and power behaviour, and is the better tie-breaker.

Does Android 16 compatibility testing guarantee Google Play approval?

No. Testing reduces defects; it does not guarantee review outcomes, rankings or uninterrupted distribution.

What is the difference between Android compatibility testing and Google Play target API compliance?

Compliance is whether the uploaded artifact declares the required target level. Compatibility testing is whether the app still behaves correctly on that platform. You need both; passing one says nothing about the other.

Official Android Resources

• Compatibility framework tools — toggling changes in Developer Options and ADB, restrictions, and the reporter states
• Android 16 compatibility framework changes — every toggleable change with its ID and default state
• Migrate apps to Android 16 — the migration path and toolchain steps
• Android 16 behaviour changes for apps targeting API 36 — edge-to-edge, predictive back, large screens, scheduling
• Android 16 behaviour changes affecting all apps — JobScheduler quotas, broadcast priorities and more
• Android Emulator — creating and running Android 16 virtual devices

Conclusion

Compatibility testing works best when you stop treating it as a single pass against a new Android version. Two questions run in parallel: what does the platform do to every app, and what does it do to apps declaring this target. The framework separates them; the reporter tells you which one you just hit.

The habit worth building is narrow: review the documented changes, pick the ones your code could plausibly reach, force them one at a time, and keep the change ID in every note. When something breaks, the ID is the difference between a guess and a diagnosis — and between fixing the app and pinning a toggle you will have to unpin later.

If your next step is a closed test on real hardware, the same discipline applies: name the device, the API level and the change under test, then let testers confirm it. TestersHQ works with Android teams on that last mile, where a compatibility report from a real device is worth more than a clean run on one emulator.