Google Play 技术质量要求作为 Android 应用质量四大要素的一部分，旨在确保 Google Play 上的应用能为用户提供优质体验。
Google Play 上的技术质量要求分为以下两类：
- 现行要求：目前正在强制执行的要求。达到这些标准对于保持应用在 Google Play 上的稳定性、性能和曝光度至关重要。
- 即将实施的要求：提前公布的新标准。虽然这些要求尚未强制执行，但您应利用过渡期评估您的应用、集成推荐的工具和 API，并努力在强制执行开始之前满足这些要求。
即将实施的要求
我们在 2026 年 8 月 26 日已宣布，Google Play 上发布的应用和游戏即将面临新的技术质量要求。这篇帮助中心文章更详细地介绍了技术阈值，旨在帮助您了解新要求，并在新要求生效之前做好准备。
降低内存用量
Google Play 针对您应用的 Android Vitals 核心指标设定了不良行为阈值。内存用量将作为新的 Android Vitals 核心指标推出，具体包含两项指标：
- 内存用量（匿名 RSS + 交换空间）
- 位图内存用量
与已设置不良行为阈值的现有 Android Vitals 指标类似，Play 会使用过去 28 天的数据来评估应用的质量。
您可以在 Android Vitals 概览中的内存标题下查看这些指标，也可以在 Google Play Developer Reporting API 中进行查看。
这些指标用于衡量应用从存储空间加载并运行后，在整个生命周期内（从前台到后台）使用的内存量。
这些指标的数值从选择加入的用户设备中抽样获取，并经过匿名化和汇总处理。在 Play 管理中心内，您可以查看每项指标的各种百分位数，包括第 90 百分位数，该数值用于对照不良行为阈值来评估应用的性能。第 90 百分位数值表示，在 1 天内收集的样本中，有 10% 的样本值高于该数值。例如，P90 为 1.7 GB 表示，有 90% 的样本值低于 1.7 GB，而 10% 的样本值高于 1.7 GB。
此要求仅适用于移动设备和平板电脑。
内存用量
匿名常驻内存大小（匿名 RSS）表示由应用直接分配的内存（例如 Java/Kotlin 堆、原生内存分配和匿名内存映射），在没有交换空间的情况下，这些内存页无法换出到磁盘。交换空间包含压缩到 zRAM 中或换出到 zRAM 的内存。
阈值会根据应用类别（应用与游戏）和设备 RAM 层级而定，以反映不同的硬件限制。自 2027 年 2 月起，Play 上的应用和游戏需要满足以下阈值才能保持合规：
应用
| 应用状态 | 前台 | 用户感知的服务 | 后台 | 已缓存 |
| 物理 RAM | 第 90 百分位 | 第 90 百分位 | 第 90 百分位 | 第 90 百分位 |
|
0 - 4 GB （总内存：0 MB - 3200 MB） |
- | - | - | - |
|
4 GB （总内存：3200 MB - 4800 MB） |
2 GB | 1 GB | 1 GB | - |
|
6 GB （总内存：4800 MB - 6800 MB） |
2.25 GB | 1.25 GB | 1.25 GB | - |
|
8 GB （总内存：6800 MB - 9216 MB） |
2.25 GB | 1.5 GB | 1.5 GB | - |
|
12 GB （总内存：9216 MB - 14336 MB） |
3.25 GB | 1.75 GB | 1.75 GB | - |
|
16 GB （总内存：14336 MB - 18432 MB） |
4.25 GB | 2 GB | 2 GB | - |
|
16 GB 及以上 （总内存超过 18432 MB） |
- | - | - | - |
注意：每个 RAM 层级范围均包含其最小值。总内存可能会低于设备标称的物理 RAM。
游戏
| 应用状态 | 前台 | 用户感知的服务 | 后台 | 已缓存 |
| 物理 RAM | 第 90 百分位 | 第 90 百分位 | 第 90 百分位 | 第 90 百分位 |
|
0 - 4 GB （总内存：0 MB - 3200 MB） |
- | - | - | - |
|
4 GB （总内存：3200 MB - 4800 MB） |
2.25 GB | 2.0 GB | 2.0 GB | - |
|
6 GB （总内存：4800 MB - 6800 MB） |
2.75 GB | 2.5 GB | 2.5 GB | - |
|
8 GB （总内存：6800 MB - 9216 MB） |
3.5 GB | 2.75 GB | 2.75 GB | - |
|
12 GB （总内存：9216 MB - 14336 MB） |
4 GB | 3.2 GB | 3.2 GB | - |
|
16 GB （总内存：14336 MB - 18432 MB） |
5 GB | 3.5 GB | 3.5 GB | - |
|
16 GB 及以上 （总内存超过 18432 MB） |
- | - | - | - |
注意：每个 RAM 层级范围均包含其最小值。总内存可能会低于设备标称的物理 RAM。
位图内存用量
在非前台应用状态下长时间保留位图可能会占用过多内存，因为只有在界面可见时才能渲染位图。通常情况下，您不应在这些状态下长时间保留位图。但由于应用可能会在状态发生变化后不久被采样，而此时您可能正在积极响应 onTrimMemory 并释放位图占用的内存，因此这些阈值被设定为大于零，以充分考虑到这一情况。
| 应用状态 | 第 90 百分位 |
| 前台 | |
| 用户感知的服务 | > 200 MB |
| 后台 | > 200 MB |
| 已缓存 | > 400 MB |
DEX 代码优化
自 2027 年 2 月起，Google Play 上的应用和游戏必须满足最低优化要求。您上传到 Play 管理中心的任何应用必须至少达到 25% 的优化、混淆和缩减率。我们知道，并非每个应用或游戏都会大量使用 DEX 代码，因此只有在 DEX 大小不容忽略的情况下，我们才会强制执行此要求。您可以在 Play 管理中心的 App bundle 资源管理器中查看 DEX 大小以及您上传的每个 app bundle 的优化百分比。
此要求适用于所有设备规格。
| 游戏 | 应用 | |||
| 代码优化 | DEX 代码超过 50 MB 的游戏 | DEX 代码超过 10 MB 的应用 | ||
| 混淆 | 25% | 25% | ||
| 优化 | 25% | 25% | ||
| 缩减 | 25% | 25% | ||
您可以使用任何工具（例如 R8 或其他应用缩减工具）来达到 25% 的最低阈值要求。
您可以使用 R8 配置分析器获取更多数据洞见，并进一步优化性能。请注意，如果您通过 CI/CD 流水线或在企业环境中发布应用，本地 build 可能与上传到 Play 管理中心以分发给用户的 build 不完全一致，因此可能会出现一些细微的差异。
免点按登录恢复
自 2027 年 4 月起，当用户从旧 Android 设备换到新设备并选择通过设备间传输或云端备份来恢复数据时，支持用户登录（可选或强制）的应用必须支持“免点按登录恢复”功能。在设备设置期间手动登录，不仅会增加初始配置过程中的阻力并降低用户留存率，还会使应用在设置期间面临钓鱼式攻击和凭证盗用等严重安全漏洞。Android Restore Credentials API 是解决这些问题并满足此要求的主要方法，适用于 Android 9 及更高版本。
- 在 2026 年 9 月 30 日或之前集成 Block Store 以恢复用户登录状态的应用，将被视为符合此要求。
- 永久私有应用和企业设备管理应用不在此要求之列。
- 如果应用受到严格的法规或合规要求约束，且这些要求会影响登录功能的运作方式（例如金融服务或医疗保健），则该应用可能符合豁免条件。开发者必须在强制执行日期之前通过 Play 管理中心提交此要求的豁免申请。
- 目前，游戏不在此要求之列。开发者预计将在 2027 年获得针对复杂游戏身份验证场景的专门指导和定制解决方案。对于支持单个用户账号的游戏，我们强烈建议使用 Restore Credentials API 来支持免点按登录功能。
未来几个月内，我们将发布有关此要求和例外情况的更多详细信息。
集成和测试
测试您的集成情况，确保用户获得顺畅的体验，并确保您满足此要求。最近发布的用于恢复凭证的 AI 技能可以帮助您更轻松地进行集成。
适用的设备规格和 Android 版本
此要求仅适用于移动设备/平板电脑。Restore Credentials API 目前尚不支持其他设备规格。“恢复凭证”功能适用于 Android 9 及更高版本。
关于即将实施的要求的常见问题解答
内存要求
Google 为何要针对内存指标引入强制执行措施？
由于 RAM 成本不断攀升，整个生态系统即将面临内存危机。内存使用效率低下（例如单个应用出现失控的内存泄漏，从而占用了大部分设备内存）会导致设备卡顿，并终止在后台正常运行的其他应用。Android 已宣布严格的内存限制，而 Play 希望确保您的应用符合这些限制要求，并尽量降低设备需要终止应用的可能性。
如何降低内存用量？
如何减少位图的内存分配？
对图片进行降采样和解码，使其与显示视图的尺寸完全匹配；使用配置了内存感知型缓存的现代图片加载库（如 Coil 或 Glide）；当界面隐藏时，释放内存中未使用的位图（通过 onTrimMemory 中的 TRIM_MEMORY_UI_HIDDEN）；并避免保留对位图或视图的静态引用。
我是否必须使用 R8 进行代码优化？
鉴于 R8 具有高级优化功能和数据分析功能，我们强烈建议您使用它；不过，您也可以使用其他优化工具来满足此要求。
为什么应用和游戏的要求有所不同？
游戏具有不同的内存用量模式，主要在前台提供流畅的游戏体验。它们通常依赖于原生游戏引擎，与应用相比，这些引擎受到不同的技术限制。游戏要求会根据应用场景进行调整。
Google Play 如何区分应用和游戏？
这取决于您在 Play 管理中心的“商店设置”中配置的类别，该类别会影响您的应用在 Play 商店中的显示位置。请注意，如果您为满足不同的技术阈值要求而更改应用类别，以致于无法准确地反映其核心功能，则违反了我们的商品详情元数据政策。
这些要求与应用体验计划和 Level Up 计划有何关联？
这些内存阈值强制生效后，应用和游戏必须符合所有内存阈值要求，才有资格加入 AEP 和 Level Up 计划或继续保留其资格。
Android 内存限制适用于 Android 17 及更高版本，Play 的要求是否也仅适用于 Android 17 及更高版本？
否，Google Play 会评估所有能够获取数据的应用版本。对于内存用量（匿名 RSS + 交换空间）和位图内存用量，该要求适用于 Android 13 及更高版本。
为什么匿名 RSS + 交换空间和每个 RAM 层级有不同的阈值？
按 RAM 层级进行划分，是考虑到不同设备对内存用量过高的容忍度有所不同。在 16 GB 设备上性能良好的应用，在 4 GB 设备上可能无法达到同样的性能水平。您应确保其应用在所有 RAM 层级中都不会占用过多内存
内存要求适用于哪些设备规格？
对于“内存用量（匿名 RSS + 交换空间）”和“位图内存用量”指标，移动设备和平板电脑在此要求之列。
哪些工具可以帮助我更充分地了解内存用量？
-
您可以参考我们的内存指南，开始优化应用或游戏的内存。
-
Google Play 管理中心 (Android Vitals)：监控内存用量（匿名 RSS + 交换空间）和位图内存用量的 28 天滚动 P90 指标，可按应用状态（前台、用户感知到的服务、后台、已缓存）、设备 RAM 层级（例如 4-6 GB）、Android 版本和应用版本进行过滤。
-
Google Play Developer Reporting API：通过编程方式查询指标，以自动生成报告、识别性能回退并将 Vitals 数据集成到内部信息中心。
-
Android Studio 内存分析器和堆转储：检查 Java/Kotlin 堆、原生内存和图形中的实时内存分配。捕获并分析堆转储 (.
hprof)，以检测内存泄漏、未释放的 Activity、重复位图和保留路径。 -
Perfetto 和系统跟踪：使用 Perfetto (
heapprofd) 对原生和 Java 内存分配进行低开销采样，以识别导致内存占用激增的调用堆栈。系统跟踪有助于跟踪整个生命周期转换过程中的内存用量，并将其与低内存杀手 (lmkd) 事件关联起来。您还可以使用 AI 分析技能（例如 Perfetto AI 技能）来自动执行跟踪和堆转储分析。 -
设备端诊断工具：使用
adb shell dumpsys meminfo <package_name>实时查看 PSS、Private Dirty (Anon RSS)、Swap Dirty (zRAM) 和位图的内存占用明细，或对ComponentCallbacks2.onTrimMemory()进行插桩，以收集自定义客户端遥测数据。
为什么代码优化有 DEX 大小下限？
虽然我们始终建议进行代码优化，因为这能带来诸多性能优势，但我们也在权衡重新构建和优化应用或游戏所需的工作量与用户能从中获得的益处。当 DEX 大小较小（应用小于 10 MB，游戏小于 50 MB）时，其对设备内存占用的影响有限，因此在这种情况下，我们不强制要求进行代码优化。
免点按登录恢复
如果在同一设备上卸载并重新安装应用，恢复密钥是否会保留？
否。当应用被卸载时，恢复密钥会自动删除。
这项要求是否适用于所有设备规格？
否，免点按恢复凭证要求仅适用于移动设备和平板电脑。
如果用户未登录，或者应用本身不提供用户账号，此要求是否仍然适用？
否。此要求旨在确保用户在切换设备后仍能保持有效的登录状态。
-
无需用户登录的应用：不提供用户账号或登录功能的应用不受影响。
-
已退出账号的用户或访客用户：如果用户在切换设备之前已退出账号、使用访客模式或已退出登录，您的应用应在新设备上以相同的未验证身份状态启动。
“恢复凭证”功能是否适用于任何身份验证方法？
是，Restore Credentials API 旨在确保应用能够存储恢复密钥，从而支持任何身份验证方法。
“恢复凭证”功能是否负责处理授权范围或增强身份验证（例如，MFA）？
-
否。Restore Credentials API 专门用于身份验证（恢复用户身份和会话）。它不负责处理额外的授权请求（如 OAuth 权限授予）或多重身份验证要求。
-
我们建议使用分两步执行的方法：
-
恢复身份：在新设备上首次启动时，使用“恢复凭证”功能以静默方式恢复用户的主要登录状态。
-
按具体场景授权：在用户访问需要特定资源权限（例如 Google 云端硬盘访问权限）的功能时，即时请求这些权限。必要时，您还可以请求增强身份验证（例如 MFA）
-
如何判断我的集成是否符合要求？
用户登录状态能否成功恢复，取决于是否成功检索到了恢复密钥。针对我们认为不符合此要求的应用，我们会发出通知。
如何确定我的应用是否属于例外情况？
我们日后会提供有关例外情况的进一步指导。
如何管理多重身份验证 (MFA) 使用场景？
Restore Credentials API 不负责处理 MFA 要求，也无意绕过应用的安全政策。在新设备上检索到恢复密钥后，您的应用必须决定是否需要执行额外的增强身份验证。恢复用户身份的上下文信息（例如，显示“欢迎回来，Alex”）足以满足要求。不过，请注意，设备间恢复可以充分证明用户拥有相应凭证，因此不应要求执行额外的 MFA 步骤。
为什么游戏不受此要求的约束？
游戏初期可获豁免，因为我们正在针对游戏中常见的复杂身份验证场景开发定制解决方案。我们强烈建议支持单账号登录的游戏采用 Restore Credentials API，以支持免点按登录功能。
我可以使用 Block Store 来满足新设备初始配置要求吗？
可以，与 Block Store 的集成可以视为符合要求，但前提是该集成已于 2026 年 9 月 30 日或之前完成并投入正式版使用，且能够成功恢复用户的登录状态。其他集成类型或在截止日期之后完成的集成均视为不符合要求。
为什么集成 Block Store 的截止日期是 2026 年 9 月 30 日？
2026 年 9 月 30 日这一日期为目前正在集成 Block Store 的团队提供了一个明确的里程碑。这确保了现有的免点按登录实施方案仍然有效，同时引导未来的集成采用推荐的 Credential Manager 标准。
如果用户在旧设备上退出账号或删除账号，会出现什么情况？
应用必须主动删除恢复密钥。如果应用被卸载，恢复密钥会自动删除。
对于访客模式下的用户，我应该怎么办？
此要求仅适用于应用中需要进行身份验证的部分。如果用户在旧设备上处于访客模式，应用应在新设备上继续以访客模式启动。
对于在同一设备上使用多个账号的用户，我应该怎么办？
为满足此要求，您的应用应在源设备上存储当前活跃用户账号（或上一个活跃账号）的恢复密钥。如需了解详情，请参阅“恢复凭证”文档。
我能否向已恢复的用户发送通知，而无需他们重新授予通知权限？
可以。备份和恢复服务负责恢复之前设备中的应用权限，包括通知权限。这样，您就可以发送通用通知。此外，如果将此功能与“恢复凭证”功能搭配使用，您可以在新设备上通过个性化通知重新吸引用户，而无需用户先打开应用。
其他
这些要求是否是硬性要求？
此页面中发布的所有要求均为硬性要求。不符合要求可能会影响应用在 Google Play 上的曝光度和发布能力。
实用资源
代码优化
内存用量（匿名 RSS + 交换空间）
位图内存用量
“恢复凭证”功能
- 了解“恢复凭证”功能
- 官方指南：实现“恢复凭证”功能
- 测试材料：在 Android Studio 中测试“恢复凭证”功能
- 实际影响案例研究：Uber 如何实现每年减少 400 万次手动登录
技能
技能是经过 AI 优化的模块化指令和资源，可帮助 LLM 更好地理解和执行特定模式，这些模式遵循 developer.android.com 上关于 Android 开发的最佳实践和指南。您可以通过 Android CLI 或其他基于 LLM 的工具利用这些技能。
- R8 分析技能：分析应用的 R8 配置和 Keep 规则
- Perfetto AI 技能：用于解读堆转储，并获取切实可行的建议来提升内存性能
- Android Profiler 技能：用于解读堆转储和跟踪记录，并获取切实可行的建议来提升内存性能
- “恢复凭证”技能：用于帮助您集成和测试恢复凭证设置
现行要求
现有的 Google Play 技术要求包括针对一组 Android Vitals 核心指标设定的不良行为阈值，以及与您上传到 Play 管理中心的 app bundle 相关的要求。
Android Vitals 核心指标和稳定性
Google Play 会监控核心性能指标，以确保应用符合稳定性标准。如果超出这些阈值，可能会影响您的应用在 Google Play 商店中的曝光度。
技术要求
Google Play 支持硬件配置和架构各异的众多设备。某些架构对于 Android 的未来发展至关重要，因此上传到 Play 管理中心的新 app bundle 必须支持这些架构，以确保我们能够在采用这些架构的设备上提供您的应用体验。