Google Play Quality Requirements: Memory, Bitmaps, R8

Indie Android teams just got a calendar, not a suggestion. On August 26, 2026, Google Play published technical quality requirements for memory, bitmaps, DEX optimization, and zero-tap sign-in restoration. The blog post is polite. Play Console Help is not: these requirements are not optional, and missing them can reduce visibility and publishing capabilities.

Read the thresholds in Play Console technical quality requirements and the announcement on the Android Developers Blog . This page is the indie translation: which bars actually apply, what “P90” means in Console, and what to do before February 2027 without pretending a category switch will save you.

The dates that matter

Announcement was August 26, 2026. Memory and DEX enforcement starts February 2027. Zero-tap sign-in restoration starts April 2027. Block Store only grandfathered if it was already in production by September 30, 2026.

Memory: Anon RSS+Swap, by RAM tier

Play is adding two core vitals: Memory usage (Anonymous RSS + Swap) and Bitmap memory usage. Like other vitals with bad-behavior thresholds, Console uses the last 28 days of data and judges you at the 90th percentile. A P90 of 2 GB means 10% of samples were worse than 2 GB. The memory bars apply to mobile and tablet only — not Wear, TV, or XR.

Play splits thresholds by category and RAM tier. A 4 GB phone app must stay at or under 2 GB foreground P90; a game on the same tier gets 2.25 GB. Cached Anon RSS+Swap is not given a numeric bad-behavior cap in the current table. Sub-4 GB and 16 GB+ tiers are listed without numeric thresholds.

Games get higher caps because Play says they have different foreground memory patterns and often sit on native engines. User-perceived services and background states are tighter than foreground for apps; games keep more headroom there too (2.0 GB on 4 GB devices, up to 3.5 GB on 16 GB). Cached Anon RSS+Swap is shown in Console but the published bad-behavior table leaves that column blank.

Bitmaps: stop holding images when the UI is gone

Bitmap memory is a separate vital. Play’s point is blunt: you cannot render bitmaps unless the UI is visible, so holding decoded images in background or cached states is wasted RAM. Thresholds are higher than zero because a sample might land right after a state change while you are still answering onTrimMemory.

Keeping more than 200 MB of bitmaps in user-perceived services or background, or more than 400 MB when cached, is bad behavior. Foreground bitmap use is measured but not given a published numeric cap in the current table.

• Decode images to the actual view size. Full-resolution assets in a 1080p list row are a self-own.
• Use a memory-conscious loader (Coil, Glide, or equivalent) and shrink the memory cache when the UI hides.
• Release bitmaps on TRIM_MEMORY_UI_HIDDEN. Do not keep static references to Bitmaps or Views.
• Watch the new out-of-memory crash filter in Android vitals. That is the OS killing you under pressure, not a mysterious native abort.

DEX: 25% obfuscation, optimization, and shrinking

From February 2027, uploads need a minimum of 25% obfuscation, 25% optimization, and 25% shrinking. Play recommends R8 and says other shrinkers are fine if they hit the same floors. This one applies across form factors, unlike the memory vitals.

Play only enforces the 25/25/25 DEX bars when the binary has a non-negligible DEX size: more than 10 MB for apps, more than 50 MB for games. Check each App Bundle in Play Console’s app bundle explorer.

Zero-tap restore, April 2027

If your app supports sign-in — optional or mandatory — you must restore that session when a user moves to a new Android device and chooses device-to-device transfer or cloud backup. The documented method is the Android Restore Credentials API, available from Android 9. The requirement is mobile and tablet only. Apps without accounts, and users who were signed out or in guest mode, are out of scope.

• Games are currently exempt. Play says dedicated game-auth guidance is coming in 2027. Single-account games are still encouraged to adopt Restore Credentials now.
• Block Store integrations that were already restoring sign-in in production on or before September 30, 2026 still count. Later Block Store work does not.
• Permanently private and enterprise device-management apps are out of scope. Heavily regulated finance and health apps may request an exemption in Console before enforcement.
• Restore Credentials authenticates; it does not complete OAuth grants or MFA. Restoring identity (“welcome back”) meets the letter. Play says a device-to-device restore is strong proof of possession and should not force another MFA step.

What an indie app should actually change

You do not need a platform team. You need a 28-day vitals baseline and a shrinking pipeline you can explain. Open Android vitals → Memory, filter by RAM tier and app state, and look at P90 — not the pretty median. Then turn on full-mode R8 (or your shrinker) and read the optimization insights on the next bundle upload.

• Foreground leaks first: static Context, retained Activities, unbounded image caches, “just in case” SDKs you forgot you shipped.
• Background next: long-lived services, FGS that keep bitmaps warm, work that should have been WorkManager.
• DEX last if you are already on R8 full mode. If minify is still off in release, that is the entire ticket.
• Sign-in apps: schedule Restore Credentials before the Block Store cutoff if you were counting on Block Store and are not in production yet.

Sources, verified 2026-08-26:

• Play Console Help — Play Console technical quality requirements
• Android Developers Blog — Elevating app quality: Reducing memory usage and improving device migration
• Android Developers — Restore Credentials
• Android Developers — Enable app optimization with R8