Google Play is adding two new categories to its technical-quality requirements.

The first measures app memory behavior and takes effect in February 2027.

The second requires automatic restoration of user sign-in state during device migration from April 2027.

Google announced both changes on August 26, providing developers with several months of preparation time.

Google Play will measure how much private memory an app actually consumes

The primary new metric is Memory usage, defined as Anonymous RSS plus Swap.

It captures private memory used by an app, including active memory and memory compressed or paged into zRAM.

Files stored on the device, such as code and assets that are not represented in this private-memory figure, are treated separately.

Google evaluates consumption across several app states, including foreground, user-perceived services, background and cached processes.

The applicable limit also varies according to the device's physical-RAM category.

A normal app on a 4GB phone gets a 2GB foreground threshold

Google has already published the numerical limits.

For ordinary apps on devices in the 4GB RAM tier, the 90th-percentile threshold is 2GB while the app is in the foreground.

For user-perceived services and background operation, it falls to 1GB.

On the 6GB tier, the published values are 2.25GB foreground and 1.25GB for those lower-visibility states.

At 8GB, they become 2.25GB and 1.5GB.

At 12GB, they rise to 3.25GB and 1.75GB.

For 16GB-class devices, Google's app threshold is 4.25GB in the foreground and 2GB for user-perceived services or background work.

The current table does not specify the same numerical limits for the very lowest and highest RAM categories.

Using a 90th percentile keeps one exceptional spike from defining an app

Google will not grade an application solely on its single worst instant on one handset.

Like other Android vitals, the memory measurements use a rolling 28-day period.

Compliance is evaluated at the 90th percentile.

That means developers primarily need to prevent consistently excessive behavior across a meaningful share of sessions rather than eliminate every rare peak.

The metrics will be accessible through Android vitals and the Google Play Developer Reporting API.

Bitmap memory is becoming its own quality signal

Google separately evaluates memory occupied by bitmaps.

Holding large images while they are actively visible can be expected behavior.

Continuing to retain them for extended periods after an app moves into the background or cached state is less defensible.

Play Console will therefore flag memory-heavy bitmap behavior independently, giving developers another route to identify leaks and unnecessary retention.

Code optimization gets a numerical requirement as well

The new rules are not limited to runtime memory.

Android App Bundles published through Google Play must achieve at least 25% coverage across optimization, shrinking and obfuscation of DEX code.

Google highlights R8, although developers can use another compatible shrinking tool.

Shrinking removes unused code and resources, while optimization can rewrite portions of an application to reduce runtime cost.

Google says better-optimized bundles use less memory, start faster, produce fewer ANRs and improve rendering and runtime performance.

Poor memory behavior can eventually hurt Play Store distribution

From February, these measurements move beyond diagnostic information.

Google says apps and games that fail the bad-behavior thresholds may see reduced visibility and publishing capabilities on Google Play.

The company has not yet detailed every enforcement mechanism and says more information will arrive later in 2026.

The important change is that memory consumption is joining crashes, ANRs and other vitals as a quality signal with potential commercial consequences.

Play Console is already exposing the data developers need

Google has begun rolling out the supporting diagnostics before enforcement.

Android vitals now provides dynamic-memory and bitmap-memory data across percentiles and RAM buckets.

A new Crashes and ANRs filter identifies cases where Android terminated an app under severe memory pressure.

Play Console also reports DEX optimization information for newly uploaded bundles when the build tooling provides the required optimization metadata.

Developers can receive warnings for threshold violations, unoptimized bitmaps, weak DEX optimization and limited split-bundle usage.

The policy exists partly because phone RAM is no longer guaranteed to keep growing

Google gives an unusually hardware-driven explanation for the change.

The mobile industry is dealing with memory supply constraints and higher component prices.

According to Google, some new devices are therefore maintaining or even reducing physical memory capacity rather than automatically increasing it generation after generation.

Applications, meanwhile, continue to become more demanding.

Several individually heavy apps can consequently degrade the entire device even when each one appears functional in isolation.

Android 17 can already throttle and terminate memory-hungry apps

The Play Store policy is arriving alongside a platform-level mechanism.

Android 17 introduced per-app memory limits, initially on Pixel devices.

Google expects more manufacturers to use those limits across devices ranging from 4GB to 16GB and beyond.

An app exceeding a platform memory limit can be throttled and may eventually be terminated.

Google Play is effectively adding pressure earlier in the chain by identifying applications whose normal behavior makes those system interventions more likely.

In April, another rule targets the pain of moving to a new phone

The second half of Google's announcement is largely unrelated to memory.

From April 2027, any Play-distributed app supporting user sign-in, whether optional or mandatory, must meet the Zero-Tap Sign-In standard.

When a user restores apps onto a new Android phone, the application should be able to recover that user's signed-in state on the first launch.

Google's intended experience is something closer to “Welcome back, Alex” than another sequence of email addresses, passwords and recovery screens.

Restore Credentials moves identity context during device transfer

The primary mechanism is Android's Restore Credentials API.

An application can create a restore credential associated with an established session on the old device.

That credential travels with supported device-to-device migration or cloud restoration.

When the app starts for the first time on the replacement phone, it can retrieve that context and restore the session without additional taps.

Google says a direct device-to-device restoration provides strong proof of possession and therefore should not require another MFA challenge merely because the user changed handsets.

Google also frames this as a phishing defense

The benefit is not only convenience.

Google argues that forcing users to re-enter credentials while setting up a new phone creates opportunities for phishing and credential theft.

Restoring previously established identity context avoids asking users to remember and retype passwords at a moment when they may be configuring dozens of applications at once.

Sensitive actions can still require their own security checks; Zero-Tap is about restoring the existing account context rather than eliminating all subsequent authentication.

Games receive a temporary exemption

Google will not apply the April 2027 Zero-Tap requirement to games initially.

The company says gaming authentication frequently involves more complex account models and promises tailored guidance during 2027.

Games using a simple single-account sign-in model are still strongly encouraged to adopt Restore Credentials.

The exemption only covers sign-in migration.

Games remain subject to the February memory and optimization requirements.

Existing Block Store integrations receive a narrow grandfathering rule

Some applications already use Google's Block Store system to restore authentication-related information.

Google will consider that approach compliant if the integration was completed and running in production on or before September 30, 2026 and successfully restores the user's signed-in state.

Integrations added after that cutoff do not receive the same exception.

That gives existing deployments continuity while steering new implementations toward Restore Credentials.

Google Play is increasingly becoming Android's quality enforcement layer

The broader pattern matters more than either rule in isolation.

Google already uses Play distribution requirements to enforce target API levels, 64-bit support, 16KB memory-page compatibility and quality thresholds around crashes and ANRs.

Memory behavior and account migration now join that list.

An application may still technically run on Android when installed by another route while losing visibility or publishing flexibility on Google Play because it does not meet Google's quality standards.

Starting in 2027, Android developers therefore have to optimize not merely for whether an app works, but for whether Google considers it a good citizen of the device — and whether it remembers who owns it when that device is replaced.