Google Play technical quality requirements help to ensure high quality experiences for users of your apps on Google Play, as part of the four pillars of Android app quality.
Technical quality requirements on Google Play are organized into two categories:
- Current requirements: Requirements that are actively enforced today. Meeting these standards is essential for maintaining your app's stability, performance, and discoverability on Google Play.
- Upcoming requirements: New standards announced in advance. While these are not yet mandated, you should use the transition period to evaluate your app, integrate recommended tools and APIs, and work towards meeting the requirements before enforcement begins.
Upcoming requirements
As announced on August 26, 2026, there are upcoming technical quality requirements for apps and games that publish on Google Play. This HC article provides more details on the technical thresholds and aims to help you understand and prepare for the new requirements before they take effect.
Reduced memory usage
From February 2027, apps and games on Play will need to meet new bad behavior thresholds. See below for specific details.
Code optimization
From February 2027, apps and games on Play will need to meet optimization thresholds. See below for specific details.
Zero-Tap Sign-In Restoration
From April 2027, apps on Play will need to support zero-tap restore credentials. See below for specific details.
Reduced memory usage
Google Play has defined bad behavior thresholds for your app's core vitals. Memory usage is being introduced as new core vitals metrics, with two metrics:
- Memory usage (Anonymous RSS + Swap)
- Bitmap memory usage
Like existing Android vitals metrics with Bad behavior thresholds, Play uses the last 28 days of data to evaluate your app’s quality.
These metrics are available under the Memory heading within Android vitals overview, as well as within the Google Play Developer Reporting API.
These metrics measure the amount of memory your app uses throughout the lifecycle of your app once it’s loaded from storage and running, from the foreground to the background.
Values for these metrics are sampled from opted-in user’s devices, anonymized and aggregated. In Play Console, you can see various percentiles for each, including the 90th percentile, which is used to evaluate your app’s performance against the bad behavior thresholds. The 90th percentile value means that 10% of samples collected over a 1d period, had a higher number than that. For example, a P90 of 1.7 GB indicates that 90% of samples collected had a value less than 1.7 GB, and 10% of samples collected had a value of more than 1.7 GB.
This requirement only applies to mobile and tablet form factors.
Memory Usage
Anonymous Resident Set Size (Anon RSS) represents memory allocated directly by your application (such as the Java/Kotlin heap, native memory allocations, and anonymous memory mappings) that cannot be paged out to disk without swap. Swap accounts for memory compressed or paged into zRAM.
Thresholds are tailored to your application category (Apps vs. Games) and Device RAM tier to reflect varying hardware constraints. From February, 2027, apps and games on Play will need to meet the following thresholds to remain compliant:
Apps
| App State | Foreground | User-perceived services | Background | Cached |
| Physical RAM | 90th Percentile | 90th Percentile | 90th Percentile | 90th Percentile |
|
0 - 4 GB (0 MB - 3200 MB Total Memory) |
- | - | - | - |
|
4 GB (3200 MB - 4800 MB Total Memory) |
2 GB | 1 GB | 1 GB | - |
|
6 GB (4800 MB - 6800 MB Total Memory) |
2.25 GB | 1.25 GB | 1.25 GB | - |
|
8 GB (6800 MB - 9216 MB Total Memory) |
2.25 GB | 1.5 GB | 1.5 GB | - |
|
12 GB (9216 MB - 14336 MB Total Memory) |
3.25 GB | 1.75 GB | 1.75 GB | - |
|
16 GB (14336 MB - 18432 MB Total Memory) |
4.25 GB | 2 GB | 2 GB | - |
|
16 GB + (Above 18432 MB Total Memory) |
- | - | - | - |
Note: Each RAM tier range includes its lowest value. Total Memory can be lower than a device’s advertised Physical RAM.
Games
| App State | Foreground | User-perceived services | Background | Cached |
| Physical RAM | 90th Percentile | 90th Percentile | 90th Percentile | 90th Percentile |
|
0 - 4 GB (0 MB - 3200 MB Total Memory) |
- | - | - | - |
|
4 GB (3200 MB - 4800 MB Total Memory) |
2.25 GB | 2.0 GB | 2.0 GB | - |
|
6 GB (4800 MB - 6800 MB Total Memory) |
2.75 GB | 2.5 GB | 2.5 GB | - |
|
8 GB (6800 MB - 9216 MB Total Memory) |
3.5 GB | 2.75 GB | 2.75 GB | - |
|
12 GB (9216 MB - 14336 MB Total Memory) |
4 GB | 3.2 GB | 3.2 GB | - |
|
16 GB (14336 MB - 18432 MB Total Memory) |
5 GB | 3.5 GB | 3.5 GB | - |
|
16 GB + (Above 18432 MB Total Memory) |
- | - | - | - |
Note: Each RAM tier range includes its lowest value. Total Memory can be lower than a device’s advertised Physical RAM.
Bitmap memory usage
Holding onto bitmaps for long periods of time in app states other than the Foreground can consume excessive memory - it’s not possible to render bitmaps unless the UI is visible. You typically shouldn’t hold onto bitmaps for long periods of time in these states, but your app might be sampled shortly after a state change where you are actively responding to onTrimMemory and releasing memory held for bitmaps, so these thresholds are higher than zero to account for this.
| App State | 90th Percentile |
| Foreground | |
| User-perceived services | > 200 MB |
| Background | > 200 MB |
| Cached | > 400 MB |
DEX Code optimization
From February 2027, apps and games on Google Play will need to meet minimum optimization requirements. You will need to achieve a minimum of 25% optimization, obfuscation and shrinking for any app uploads to Play Console. We understand not every app or game makes heavy use of DEX code, and so this requirement will only be enforced where you have non-negligible DEX sizes. You can view your DEX size, as well as your optimization percentages for each app bundle you upload on the app bundle explorer within Play Console.
This requirement applies across all form factors.
| Games | Apps | |||
| Code Optimization | Games with > 50 MB DEX code | Apps with > 10 MB DEX code | ||
| Obfuscation | 25% | 25% | ||
| Optimization | 25% | 25% | ||
| Shrinking | 25% | 25% | ||
You can use any tool, such as R8 or another app shrinker to achieve the minimum 25% thresholds.
You can use the R8 Configuration Analyzer to get more insights and tune your performance further. Note that if you publish via CI/CD pipelines or in an enterprise environment, your local builds might not perfectly match the build that gets uploaded to Play Console for distribution to users, so some minor differences can be expected.
Zero-tap sign-in restoration
From April 2027, apps that support user sign-in (optional or mandatory) must support Zero-Tap Sign-In restoration when a user moves from their previous Android device to a new one and selects to restore their data either from a device-to-device transfer or cloud backup. Manual sign-ins during device setup doesn't just create onboarding friction and decrease user retention, it actively exposes apps to critical security vulnerabilities like phishing and credential theft during setup. The Android Restore Credentials API is the primary method to solve these problems and meet this requirement, and is available from Android 9 and above.
Exceptions and scope
- Apps integrating with Block Store, on or before September 30, 2026, to restore a user's sign-in state are considered compliant with this requirement.
- Permanently private and enterprise device management apps are outside the scope of this requirement.
- Apps subject to strict regulatory or compliance mandates that impact how your sign-in feature works (such as financial services or healthcare) may be eligible for an exemption. Developers must submit an exemption request for this requirement through the Play Console prior to the enforcement date.
- Games are currently out of scope from this requirement. Developers should expect dedicated guidance and tailored solutions for complex gaming authentication use cases coming in 2027. For games that support a single user account, we strongly encourage usage of the Restore Credentials API to support zero-tap sign-in.
More details about the requirement and exceptions will be published in the coming months.
Integrating and testing
Test your integration to make sure users have a seamless experience and you meet this requirement. The recently published AI skill for Restore Credentials can help you integrate more easily.
Form factors and Android versions in scope
This requirement only applies to mobile/tablet form factors. The Restore Credentials API is not supported for other form factors today. Restore Credentials is available from Android 9 and above.
Upcoming Requirement FAQs
Memory requirements
Why is Google introducing enforcements for memory metrics?
An ecosystem-wide memory crisis is imminent due to rising RAM costs. Inefficient memory use, such as a single app with a runaway memory leak that consumes most of the device memory, causes the device to stutter and kill other well-behaving apps in the background. Android has announced strict memory limits, and Play wants to ensure your app’s fall within this and minimize the chances that the device needs to terminate your app.
How can I reduce my memory usage?
Follow the best practices for apps and games. Key strategies include releasing resources in onTrimMemory() (including leveraging the game engine to do so), avoiding static memory leaks by using lifecycle-aware components, profiling allocations and heap dumps using Perfetto, and minimizing long-running background tasks
How can I reduce my bitmap allocations?
Downsample and decode images to match exact display view dimensions, use modern image-loading libraries (such as Coil or Glide) configured with memory-conscious caches, release unused in-memory bitmaps when your UI is hidden (via TRIM_MEMORY_UI_HIDDEN in onTrimMemory), and avoid holding static references to Bitmaps or Views.
Am I required to use R8 for code optimization?
While we strongly recommend using R8 for its advanced optimizations and insights, other optimization tools are available and can be used to meet this requirement.
Why do the requirements differ between apps and games?
Games have different memory usage patterns to deliver smooth game play experience primarily in the foreground. They often rely on native game engines which have different technical constraints than apps. Games requirements are tailored to the use case.
How does Play distinguish between an app and a game?
This is based on the category you can configure within the Store settings on Play Console, which influences what part of the Play Store your app appears in. Please note that changing your app’s category to one that does not accurately reflect its core functionality in an attempt to qualify for different technical thresholds is a violation of our store listing Metadata policy.
How do these requirements intersect with Apps Experience Program and Level Up Programs?
Once enforcement for these memory thresholds are in effect, apps and games must comply with all memory thresholds to qualify for or maintain AEP and Level Up eligibility.
Android Memory Limits are on Android 17+, are Play’s requirements on A17+ only?
No, Google Play evaluates all of your app versions where data is available. This is Android 13+ for Memory usage (AnonRSS + Swap), and Bitmap memory usage.
Why are there different thresholds for RSS Anon+Swap and each RAM tier?
Splitting by RAM tier acknowledges that different devices have varying tolerance levels for excessive memory usage. What is performant on a 16 GB device may not be as performant on a 4 GB device. You should ensure their app does not use excessive memory across all RAM tiers
Which form factors are in-scope for the Memory requirements?
For Memory usage (Anonymous RSS + Swap) and Bitmap memory usage metric, the mobile and tablets form factor is in scope.
What tools are available to understand my memory usage more?
-
You can get started with improving memory for apps or games using our memory guidance.
-
Google Play Console (Android vitals): Monitor 28-day rolling P90 metrics for Memory usage (Anon RSS + Swap) and Bitmap memory usage, filterable by App State (Foreground, User-perceived service, Background, Cached), Device RAM tier (for example, 4-6 GB), Android version, and app release.
-
Google Play Developer Reporting API: Programmatically query metrics to automate reporting, identify performance regressions, and integrate vitals data into your internal dashboards.
-
Android Studio Memory Profiler and Heap Dumps: Inspect real-time allocations across Java/Kotlin heap, native memory, and graphics. Capture and analyze heap dumps (.
hprof) to detect memory leaks, unreleased Activities, duplicate bitmaps, and retaining paths. -
Perfetto and System Tracing: Use Perfetto (
heapprofd) for low-overhead sampling of native and Java allocations to identify callstacks causing memory spikes. System traces help track memory usage across lifecycle transitions and correlate with low-memory killer (lmkd) events. AI analysis skills (such as Perfetto AI skills) are also available to automate trace and heap dump analysis. -
On-Device Diagnostic Tools: Use
adb shell dumpsys meminfo <package_name>for live breakdown of PSS, Private Dirty (Anon RSS), Swap Dirty (zRAM), and Bitmaps, or instrumentComponentCallbacks2.onTrimMemory()for custom client telemetry.
Why is there a DEX size floor for code optimization?
While we always recommend code optimization, for the many performance benefits - we are balancing the effort required to rebuild and optimize an app or game, alongside the user benefit. Small DEX sizes (Less than 10 MB for apps and less than 50 MB for games) have limited impact on the devices memory footprint, and so we are not mandating code optimization here.
Zero-Tap Sign-In Restoration
Does the restore key persist if an app is uninstalled and reinstalled on the same device?
No. The restore key is automatically deleted when an app is uninstalled.
Does this requirement apply to all form factors?
No, the zero-tap restore credentials requirement only applies to the mobile and tablet form factors.
Does this requirement apply if a user is not signed in, or to apps without user accounts?
No. The requirement is designed to preserve an active sign-in state across device transitions.
-
Apps without user sign-in: Apps that do not offer user accounts or login functionality are not affected.
-
Signed-out or guest users: If a user was signed out, using guest mode, or logged out before switching devices, your app should launch in that same unauthenticated state on the new device.
Does Restore Credentials work with any authentication method?
Yes, the Restore Credentials API is designed to work with any authentication method by enabling apps to store a restore key.
Does Restore Credentials handle authorization scopes or step-up verification (for example., MFA)?
-
No. The Restore Credentials API is designed exclusively for authentication (restoring the user’s identity and session). It does not handle secondary authorization requests, like OAuth permission grants, or multi-factor challenges.
-
We recommend a two-step approach:
-
Restore identity: Use Restore Credentials to silently re-establish the user's primary signed-in state upon first launch on the new device.
-
Authorize in-context: Request specific resource permissions (for example, Google Drive access) just-in-time when the user accesses features requiring them. If necessary, you can also request step-up authentication (for example, MFA)
-
How do I know if my integration is meeting the requirement?
Successful user sign in restoration is determined through the successful restore key retrieval. Apps we identify as not meeting this requirement will be notified.
How do I know if my app is part of an exception?
Further guidance on exceptions will be provided at a later date.
How do I manage multi factor authentication (MFA) use cases?
The Restore Credentials API does not handle MFA challenges, nor is it intended to bypass your app’s security policies. Upon retrieving a restore key on a new device, your app must decide whether to require an additional step-up verification. Restoring the user's identity context (for example, displaying "Welcome back, Alex") is sufficient to meet the requirement. However, note that a device-to-device restoration provides strong proof of possession and should therefore not require an additional MFA step.
Why are games exempt from this requirement?
Games are initially exempt as we work on tailored solutions for complex authentication use cases, which are common for games. Games who support single-account sign-in are strongly encouraged to adopt the Restore Credentials API to support zero-tap sign-in.
Can I use Block Store to meet the new device onboarding requirements?
Yes, an integration with Block Store may be considered compliant but only if the integration was completed and in production on or before September 30, 2026, and it successfully restores a user’s sign-in state. Other integration types or those completed after the cutoff date are not considered compliant.
Why is there a September 30, 2026 cutoff for Block Store integrations?
The September 30, 2026 date provides a clear milestone for teams currently in the middle of integrating Block Store. It ensures existing zero-tap sign-in implementations remain valid while directing future integrations towards the recommended Credential Manager standard.
What happens when the user logs out or deletes their account on the old device?
The app will have to actively delete the restore key. If the app gets uninstalled, the restore key will automatically be deleted.
What do I do with users in a guest mode?
The requirement applies only to the authenticated portion of your app. If a user was a guest on the old device, the app should launch in guest mode on the new device.
What do I do with users using multiple accounts on the same device?
To satisfy the requirement, your app should store the restore key for the currently active user account (or the last active account) on the source device. You can learn more in the Restore Credentials Documentation.
Can I send notifications to restored users without requiring them to re-grant notification permissions?
Yes. Backup and restore services handle the restoration of app permissions, including notification permissions, from the previous device. This allows you to send generic notifications. Furthermore, when combined with Restore Credentials, YOU can re-engage users with personalized notifications on the new device without requiring the user to open the app first.
Others
Are these requirements optional?
All of the requirements posted in this page are not optional. Not meeting a requirement can affect an app’s visibility and publishing capabilities on Google Play.
Useful resources
Code optimization
- Enable app optimization with R8 | App quality | Android Developers
- Use R8 in full mode | App quality | Android Developers
- Use R8 Configuration Analyzer | App quality | Android Developers
Memory usage (Anonymous RSS + Swap)
Bitmap memory usage
Restore Credentials
- Understanding Restore Credentials
- Official Guides: Implement Restore Credentials
- Testing Materials: Test Restore Credentials in Android Studio
- Real-World Impact Case Study: How Uber Reduced Manual Logins by 4M Per Year
Skills
Skills are AI-optimized, modular instructions and resources that help LLMs better understand and execute specific patterns that follow the best practices and guidance on Android development from developer.android.com. You can use these through the Android CLI or other LLM-based tooling.
- R8 Analysis Skill: Analyzes an app’s R8 configuration and keep rules
- Perfetto AI Skills: Use for interpreting heap dumps and getting actionable suggestions to improve memory performance
- Android Profiler Skill: Use for interpreting heap dumps and traces and getting actionable suggestions to improve memory performance
- Restore Credentials Skill: Use for help integrating and testing your restore credentials setup
Current Requirements
Existing Google Play technical requirements include bad-behavior thresholds across a set of core vitals, as well as requirements relating to the app bundle you upload into Play Console.
Core Vitals and Stability
Google Play monitors core performance metrics to ensure apps meet stability standards. Exceeding these thresholds can affect your app's discoverability on the Google Play Store.
- User-perceived crash rate: Threshold of 1.09% overall (average across devices), 8% per phone model, and 4% per watch model. Learn more
- User-perceived ANR rate: Threshold of 0.47% overall (average across devices), 8% per phone model, and 5% per watch model. Learn more
- Excessive partial wake locks: Threshold of 5% overall (average across devices). Keeping the device awake unnecessarily drains battery; ensure you use wake locks correctly and consider using WorkManager for background tasks. Learn more
- Excessive battery usage: Threshold of 1% per watch model. Learn more
Technical Requirements
Google Play supports a wide range of devices with varying hardware configurations and architectures. Some architectures are fundamental to the future of Android, and as such new app bundles uploaded to Play Console must support them to ensure we can deliver your app’s experiences to them.
- 64-bit support: Apps that contain native code must support 64-bit only architectures. Learn more
- 16 KB memory page size support: Apps that contain native code must support devices with 16 KB memory page sizes. Java/Kotlin only apps are compatible by default. Learn more
- Wear-OS 64 bit and 16 KB memory page size support: Required as of 15 Sep, 2026. Learn more
- TV 64 bit and 16 KB memory page size support: Required as of 1 Aug, 2026. Learn more