Key points:
- Google’s own August 2026 Android Developers Blog post adds new rules. Memory thresholds, plus a sign-in rule for new devices.
- These sit apart from the existing crash and ANR rate bars. A separate set of checks.
- Memory rules cover three things. Memory use, bitmap use, and code optimization at 25% or higher. The deadline is February 2027.
- A sign-in rule, Zero-Tap Sign-In, follows in April 2027. New tools for all of this are already live in Android vitals.
Crash rate and ANR rate were never the whole picture. Google’s own August 2026 post adds two more bars. Both come with real numbers.
The three memory checks, in plain terms
Google’s own post names three specific things it now checks. First: how much memory an app’s own data uses. Active memory plus compressed memory together. Google calls this Anonymous RSS plus Swap. Files like code and images stored on the device don’t count toward this number.
Second: bitmap memory. This checks one narrow thing. Does an app keep images loaded in memory after it moves to the background? It shouldn’t. A bitmap should clear once a screen isn’t in view.
Third: code optimization. This one has a hard floor. At least 25% of an app’s code needs to pass through a shrinking and obfuscation tool, such as R8. Below that line, the app fails this check.
| Check | What it looks at | Deadline |
|---|---|---|
| Memory use (RSS + Swap) | An app’s own data in memory | February 2027 |
| Bitmap memory | Images left loaded in the background | February 2027 |
| Code optimization | 25%+ coverage via R8 or similar | February 2027 |
| Zero-Tap Sign-In | Auto sign-in on a new device | April 2027 |
Why the sign-in rule comes later, and works differently
The memory checks are about app performance. Zero-Tap Sign-In is a different kind of rule. It’s built on the Android Restore Credentials API. Any app with sign-in, whether required or optional, needs to support it. The deadline is April 2027. Two months past the memory deadline.
The goal is simple. Someone buys a new Android phone. They open your app. They’re already signed in. No extra tap, no re-entering a password. Games don’t need to meet this bar yet, though Google says game studios should still plan for it. More guidance for games is coming later.
The two deadlines don’t carry the same penalty. Miss the memory bar by February 2027, and Google’s own words point to reduced visibility and tighter publishing limits. Miss Zero-Tap Sign-In by April 2027, and the loss is bigger: full publishing rights and top-tier visibility both take a hit. Neither one means an app gets pulled.
Real-world scenario: A team had already fixed their crash rate and ANR rate. They thought their quality work was finished. Then they read Google’s own August 2026 post and checked the new memory tools in Android vitals. One screen kept old images loaded long after a user left it, even with the app in the background. They fixed that leak. Separately, since their app requires sign-in, they started the Restore Credentials API work early, well ahead of the April 2027 cutoff.
What to actually do about it
- Open Android vitals and look at the new memory breakdowns now. Google’s own tools already split this out by device type and percentile.
- Run your code through R8 if you haven’t. 25% coverage is a real, checkable number. Not a vague goal.
- Start the sign-in work early if your app has accounts. April 2027 isn’t far behind February 2027, and most apps won’t get an exemption.
- Don’t assume a clean crash rate covers this too. These are new, separate checks. Clearing the old bar says nothing about the new one.
AppRankr’s Rank Tracker tracks your visibility trends over time, a useful way to catch an early dip before a quality deadline like this one makes it worse.