What changes in 2027
From February 2027, Google Play says apps and games must meet applicable bad-behavior thresholds for dynamic memory usage, bitmap memory and DEX code optimization. Google also states that published bundles need at least 25 percent coverage across optimization, shrinking and obfuscation using R8 or an equivalent tool. Products that exceed thresholds may face reduced visibility and publishing capability.
From April 2027, apps that support sign-in—whether optional or required—must support the Zero-Tap Sign-In standard for device migration through the Android Restore Credentials API to maintain full publishing capability and optimal visibility. Games are currently exempt from the Zero-Tap requirement.
Why memory is now a distribution concern
Memory pressure is easy to postpone because it can appear as an occasional device problem rather than a product metric. Google is moving it closer to distribution by surfacing anonymous RSS plus swap, bitmap use, out-of-memory terminations and DEX optimization signals in Android vitals.
Teams need to measure by device RAM category and process state. An image cache that is reasonable on a flagship can cause repeated termination on a lower-memory device. A background screen retaining large bitmaps can damage other apps and force slower cold starts even when the foreground flow appears smooth.
A ninety-day preparation plan
The first month should establish a baseline: current Android vitals, representative RAM buckets, app-bundle optimization metadata and the screens with the largest bitmap footprint. The second month should address leaks, cache policy, image sizing, unnecessary retained state and R8 configuration. The third month should run staged builds on lower-memory devices and define regression thresholds for every release.
- Record memory by foreground, background and cached state.
- Inspect bitmap lifetime rather than only compressed file size.
- Review keep rules that silently prevent R8 from shrinking code.
- Test split bundles and downloadable assets on a clean install.
- Add a release alert when memory or DEX coverage regresses.
| Window | Primary work | Deliverable | Release evidence |
|---|---|---|---|
| Days 1–30: baseline | Review Android vitals by RAM category and process state, inspect bundle optimization metadata, and map the current account-migration flow. | A shared inventory of memory risks, R8 configuration, authentication dependencies and named owners. | Saved baseline reports and reproducible test journeys tied to the current production build. |
| Days 31–60: remediation | Address leaks, bitmap lifetime, cache policy and unnecessary keep rules; design Restore Credentials handling for expiry, logout and account switching. | Reviewed code changes plus an authentication threat and failure-state review. | Pull requests, test cases and documented decisions without claiming improvement before measurement. |
| Days 61–75: verification | Run staged builds on representative lower-memory devices and test clean install, device transfer, revoked credentials and deleted accounts. | A results log separating confirmed fixes, remaining defects and accepted exceptions. | Device/build details, vitals snapshots and repeatable migration test records. |
| Days 76–90: release gate | Add regression checks, finalize incident and rollback steps, and review store-readiness ownership. | A go/no-go checklist with unresolved risks assigned before submission. | Signed review record, monitoring plan and rollback owner for the release candidate. |
Zero-Tap is also an account-security project
Restoring a session is not simply copying a token. The receiving app must associate the credential with the intended account, handle revoked or expired state, respect logout, support account switching and avoid restoring a user into the wrong tenant or environment.
Treat migration as a separate authentication flow with audit events and failure recovery. Test a new device, multiple accounts, a revoked credential, an account deleted on the old device and a user who intentionally signed out before transfer.
The management decision
These requirements affect acquisition and retention, not only engineering cleanliness. Product managers should reserve roadmap capacity, security owners should review the restore model, and release managers should make Android vitals part of the same gate as crashes and store metadata.
Primary sources
Facts are grounded in the official announcements below. AppMe analysis and recommendations should be validated against the product being changed.