AI & TechnologyGoogle Play Memory, DEX and Zero-Tap Sign-In Rules 2027

Google Play will enforce three new technical quality requirements: lower memory and bitmap memory use and DEX code optimization from February 2027, and zero-tap sign-in restoration from April 2027. Google gives the month for each, not a day. Memory is judged at the 90th percentile over a rolling 28 days, DEX optimization must reach at least 25% where your DEX is large enough, and any app with sign-in must restore the signed-in state on a new device with the Restore Credentials API. Google says missing a requirement can affect visibility and publishing capabilities.

I checked Google's pages on October 19, 2026. Google can update these pages, so open the linked pages before you plan around any number.

Disclosure: App369 is my studio. I build and fix Flutter and Firebase apps, and the last section mentions what I sell. Google doesn't pay me for anything on this page.

The dated table

The August blog post says apps that miss the thresholds may see reduced app visibility and publishing capabilities on Google Play.

The memory and bitmap thresholds

Google's page shows these metrics under the "Memory" heading in Android vitals and in the Google Play Developer Reporting API.

• Memory usage (Anonymous RSS + Swap): Anon RSS is memory the app allocates directly (Java/Kotlin heap, native allocations, anonymous mappings) that can't be paged out without swap. Swap is memory compressed or paged into zRAM.
• Bitmap memory usage.

How it is measured, as Google writes it:

• Play uses a rolling 28 days of data.
• Samples come from opted-in users' devices.
• Compliance is judged on the 90th percentile (P90). Measurement covers the app's lifecycle from foreground to background.
• Only mobile and tablet form factors are in scope.
• Play evaluates all app versions with available data.

Apps, P90 by app state and device RAM tier:

Games, P90:

Google's page shows a dash in the empty cells. I read that as no threshold listed, and I wrote it that way rather than guess. Each RAM tier includes its lowest value, and Total Memory can be lower than the advertised Physical RAM.

Bitmap memory, P90:

Google explains that these thresholds sit above zero because apps may be sampled shortly after a state change, while they are still releasing bitmaps in response to onTrimMemory. It also warns that changing an app's category to get different thresholds violates the Metadata policy.

The DEX code optimization rule

• Apps and games must reach at least 25% for obfuscation, optimization and shrinking.
• It applies only where DEX size is non-negligible: games with DEX over 50 MB, apps with DEX over 10 MB.
• It applies across all form factors.
• DEX size and optimization percentages are visible per bundle in the app bundle explorer.
• Any tool can be used, such as R8 or another shrinker. Google strongly recommends R8.
• Builds from CI/CD or enterprise pipelines may differ slightly from the uploaded build, so Google says some minor differences are expected.

The blog post adds that Play Console shows DEX optimization insights for each uploaded bundle "if the shrinking tool shares metadata".

The zero-tap sign-in requirement

What it says. Apps that support sign-in, optional or mandatory, must support zero-tap sign-in restoration when a user moves to a new Android device through a device-to-device transfer or cloud backup. The primary method is the Android Restore Credentials API, available from Android 9. Mobile and tablet form factors only.

Exceptions, as written:

• Apps that integrated Block Store on or before September 30, 2026 to restore sign-in state are considered compliant.
• Permanently private apps and enterprise device management apps are out of scope.
• Apps under strict regulatory or compliance mandates, such as financial services or healthcare, may qualify for an exemption. The request must be submitted through Play Console before the enforcement date.
• Games are currently out of scope. Google expects dedicated guidance in 2027 and encourages games with single-account sign-in to adopt Restore Credentials.

Scope details from Google's FAQ:

• Apps without user accounts are unaffected.
• Signed-out or guest users should launch unauthenticated on the new device.
• Restore Credentials handles authentication only, not authorization scopes or MFA step-up.
• If a user has several accounts, store the restore key for the current or last active account.
• The restore key is deleted on uninstall. Apps must actively delete it on logout or account deletion.
• Apps that don't meet the requirement will be notified by Google.

How the API works. Per Google's Restore Credentials documentation, it is a Credential Manager feature that lets users restore their app accounts and be signed in on first opening an app after setting up a new device. You generate a restore key silently after the user signs in, and again on a later launch if they are already signed in. For cloud backup the user must be signed in to a Google Account, have Android data backup enabled and have a screen lock. If not, an E2eeUnavailableException is thrown. The implementation guide's text on handling it is internally inconsistent (it says to call with cloud backup true, then shows a retry with false), so check the current page before copying it.

From the implementation guide:

• Requirements: Android 9 (API level 28) and higher, Google Play services core version 24220000 or higher, and androidx.credentials 1.5.0 or higher.
• On a new device, call it on first launch, or in onRestoreFinished of BackupAgent if you use app data backup. The page says not to use onRestore.
• Credential Manager does not delete keys for you. Call clearCredentialState() with TYPE_CLEAR_RESTORE_CREDENTIAL on logout, and also when the server invalidates the session.
• Notifications are not automatically restored. If you use Firebase, fetch and send the FCM token to your backend again.
• Scope: a restore key is tied to an app's package name, so a main app and sub-apps with different package names each need their own key. The feature works whether or not allowBackup is set in the manifest.

For the sign-in library background, see my Credential Manager guide.

What this means for a Flutter app

R8 and minify. Flutter's Android deployment page says R8 "is enabled by default when you build a release APK or AAB" and that you can disable it with --no-shrink. The same page later says the --[no-]shrink flag has no effect and that code shrinking is always enabled in release builds. Those two statements contradict each other, and the page does not say which is current. I would not rely on the flag either way. Check what your own release bundle shows.

The page also says obfuscation and minification can considerably extend compile time. It does not explain custom keep rules for plugins. For that, Android's docs say to add keep rules when optimization causes errors, and to refine them: "to allow maximum optimization of classes, fields and methods". Dart obfuscation is a separate feature from R8.

Large images. Flutter's performance best practices page has no guidance on large images, the image cache or decoding at a reduced size, so I can't cite Flutter docs for that. Android's bitmap page is general to Android. It recommends decoding images to match their target container dimensions instead of loading full-resolution assets, and serving images from your backend sized to device density and container size.

Restore Credentials in Flutter or React Native. I found no official Flutter or React Native documentation for Restore Credentials in the pages I fetched. Google's docs describe a Kotlin API. I did not verify any third-party plugin. So for a Flutter app, expect either to write it in your Android module through a platform channel or to vet a plugin yourself. Also expect server work: Google recommends the feature especially for apps that already support passkeys because of the common underlying server-side implementation.

How to check your app

1. Android vitals. Open Android vitals in Play Console and find the new Memory section: memory usage (anonymous RSS + swap) and bitmap memory usage, by percentile and RAM bucket. The blog post also lists a new out-of-memory filter for Crashes and ANRs and a warning on the Android vitals overview page for unoptimized bitmaps, limited DEX optimization or limited split-bundle usage.
2. Compare at P90. Read the P90 value for each app state and RAM tier against the tables above. Remember bitmap limits apply to user-perceived services, background and cached states, not foreground.
3. App bundle explorer. Open your latest bundle and check DEX size and optimization percentage. If DEX is under 10 MB (app), the 25% rule does not apply per Google's page.
4. R8 settings. Android's docs say to set isMinifyEnabled = true and isShrinkResources = true in the release build, and use proguard-android-optimize.txt, because support for proguard-android.txt was dropped (it includes -dontoptimize). For AGP 9.3 and higher the docs use an optimization { enable = true } block. If optimization causes errors, the docs say to add keep rules for the code it breaks, so test the release build.
5. Bitmap sizing. List the biggest images your app shows. Decode at the size they display, release bitmap caches when the UI is hidden, and use Memory Profiler and LeakCanary to find bitmaps kept after a screen is gone.
6. Sign-in. If your app has accounts, decide now whether you are covered by the Block Store cutoff, an exemption, or need Restore Credentials. Test with a real device-to-device transfer or a cloud-backup restore.

My advice: do the Android vitals and bundle explorer checks this week. They are free and tell you whether memory or DEX is even a problem for your app. If sign-in is in your app, treat April 2027 as a real project, because it touches your server and your logout flow.

My advice: do not wait for a Play notice. Google says apps that miss the sign-in requirement will be notified, but a notice close to enforcement leaves little time for server changes.

For every other dated Apple, Google Play and Firebase requirement in 2026 and 2027, see App Store and Google Play deadlines for 2026 and 2027.

Need a hand?

If your Flutter app has memory spikes, heavy images, an unoptimized release build or a sign-in flow that needs Restore Credentials before Google Play enforces the change, the App Fix Ticket covers it in two fixed-price steps. A $450 Diagnosis gives you the root cause with evidence and a fixed repair quote within 3 business days, credited toward the fix. If you go ahead, the $1,200 Fix takes 5 business days and comes as a pull request. Or send me a short description.