跳过主要内容
Capgo logo
开发 安卓 Google Play

修复Capacitor应用中的Google Play混淆率低于25%

通过启用R8、压缩未使用的DEX和发布发行版App Bundle来在Capacitor安卓应用中通过Google Play的25%混淆率检查

文章来源

马丁·多纳迪尤

作者

瓦莱里亚

审阅者

乔丹

编辑器

修复Capacitor应用中的Google Play混淆率低于25%

Play Console现在会标记CapacitorAndroid应用 应用优化率低于我们的阈值通常伴有 混淆 混淆率一直居高不下 3%。Google希望至少 25% 混淆、优化和压缩。执行开始于 2027年2月，而失败可能会减少可见性和发布选项。

Android vitals中的警告看起来像这样：

Google Play Console Android vitals warning显示在3%的混淆率下，低于25%的应用优化阈值，具有2027年2月的修复日期

这是一个本机Android DEX问题。它不是关于您的Vue、React或Angular包。 Capgo 实时更新也不会改变此分数。您在Android Gradle发布构建中修复它，然后上传一个新的应用包。

Google Play正在衡量

Google Play检查 DEX 在您的Android应用包中：编译的Java和Kotlin，包括Capacitor，插件和AndroidX。从2027年2月起，DEX大小超过 10 MB 的应用必须在所有三个方面达到 25% 指标

在Android App Bundle中 什么意思 低分评分的典型Capacitor原因
混淆 类、字段和方法名称重命名为短名称 minifyEnabled 仍然 false
优化 R8内联、合并和重写字节码 默认 proguard-android.txt 包括 -dontoptimize
压缩 未使用的类和方法被移除 资源code压缩从未打开

Play 读取 r8.json 当您使用 Android Gradle Plugin 8.10 或更高版本的最新补丁时，Play 会读取 mapping.txt, then DEX heuristics. A Capacitor app shipped with minification off has almost no mapping file, so Play sees readable names and reports a few percent obfuscation (often leftover from already-obfuscated library AARs). That matches a 3% ,然后DEX heuristics。一个 __CAPGO_KEEP_0__ 应用程序，带有 minification 关闭，几乎没有映射文件，所以 Play 可以看到可读的名称并报告几百分比的混淆（通常来自已混淆的库 AARs）。这与一个

vitals 分数相符。 官方政策：Play Console 技术质量要求 DEX code optimization DEX __CAPGO_KEEP_0__ 优化 和.

Why Capacitor apps fail this check

为什么 Capacitor 应用程序会失败此检查？ 不需要 R8:

buildTypes {
    release {
        minifyEnabled false
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
}

这是默认的在 android-template/app/build.gradle. Debug 构建应该保持这种方式。 Release 构建不应该，如果您发布到 Play。

您的 JavaScript 已经被 Vite 或 webpack 进行了压缩。 Play 不会计算此项。只有原生 DEX 名称、未使用的原生 code 和 R8 优化才会计算。

步骤 1 — 为发布启用 R8

打开 android/app/build.gradle (Groovy 是 Capacitor 默认值) 并更改 发布 块：

buildTypes {
    release {
        minifyEnabled true
        shrinkResources true
        proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
    }
}

如果模块使用 Kotlin DSL (build.gradle.kts):

buildTypes {
    getByName("release") {
        isMinifyEnabled = true
        isShrinkResources = true
        proguardFiles(
            getDefaultProguardFile("proguard-android-optimize.txt"),
            "proguard-rules.pro"
        )
    }
}

Three details matter:

  1. minifyEnabled true 是实际运行R8（压缩+混淆+优化）的
  2. shrinkResources true 移除未使用的Android资源。它需要进行混淆
  3. 对于这个R8设置，使用 proguard-android-optimize.txt. proguard-android.txt 运输 -dontoptimize，它阻止了R8的优化，并且在AGP 9中会失败。 Play允许任何压缩器；Capacitor 应用程序应该使用R8的优化默认值。 请参见 Capacitor 插件AGP 9构建错误修复 如果插件仍然引用旧文件

不要设置 minifyEnabled true 在 debug. 仅在发布时保留本地运行的速度和堆栈跟踪的可读性

步骤2 — 不要禁用R8全模式

打开 android/gradle.properties 并且如果存在，请删除以下这行代码：

android.enableR8.fullMode=false

AGP 8+ 已经启用了全模式。保留该标志会限制优化。

另外搜索 android/app/proguard-rules.pro (以及任何额外的) -include 文件）中的：

-dontobfuscate
-dontoptimize
-dontshrink
-keep class ** { *; }

这些规则即使您切换后也会保持低的Play评分。除非您有一个文档记录的临时原因，否则请删除它们。 minifyEnabled步骤 3 — 保留 __CAPGO_KEEP_0__ 插件，而不是整个应用程序

R8 使用反射元数据。 Capacitor 插件是通过注解发现的，因此需要保留规则。

R8 uses reflection metadata. Capacitor plugins are discovered by annotations, so they need keep rules. 自 __CAPGO_KEEP_0__ 3.2.3, Since Capacitor 3.2.3, @capacitor/android 运送 消费者ProGuard规则 那些保持:

  • @CapacitorPlugin 类 @PluginMethod, 权限和活动回调
  • 扩展 com.getcapacitor.Plugin
  • 遗留 @NativePlugin 和Cordova插件类

保持当前Capacitor 6/7/8 行以便应用消费者规则

在 android/app/proguard-rules.pro 仅 如果你能在发布构建中重现一个崩溃。狭窄击败广泛:

# Good: one misbehaving plugin package
-keep class com.mycompany.myplugin.** { *; }

# Bad: this will tank obfuscation and shrinking
-keep class com.getcapacitor.** { *; }
-keep class ** { *; }

If a third-party plugin still crashes after a targeted keep rule, update the plugin, then consider a maintained alternative from the Capgo plugin directory Capgo Consulting __CAPGO_KEEP_0__

Official Capacitor notes: to patch it..

Official

__CAPGO_KEEP_0__

notes:

npm run build
npx cap sync android
cd android
./gradlew bundleRelease

使用 ProGuard release 步骤 4 — 构建一个真实的发布包 .aab. 在 Android Studio 中签名并上传到 Play Store 之前。

安装一个 在设备上安装一个 （然后在./gradlew assembleRelease下面的 app/build/outputs/apk/release/）. 一个 .aab 是 Play Store 上传的格式，而不是手动安装的。测试本地插件（摄像头、推送、文件、计费、身份验证）。 R8 的错误在 npx cap run android 中不会显示。

在上述 Gradle 命令之后（您应该在 android/中），确认 R8 确实运行了：

  • app/build/outputs/mapping/release/mapping.txt
  • app/build/outputs/mapping/release/configuration.txt
  • 在 AGP 8.10 或更高版本的最新补丁中 r8.json ，在 App Bundle 内部

那些 release 文件夹是默认的Capacitor变体。使用产品风味，映射在变体名称下（mapping/freeRelease/APK在 apk/<flavor>/release/ (例如 apk/free/release/).

如果 mapping.txt 不存在，您可能在错误的变体文件夹中，CI debug或R8 -dontobfuscate。重新检查 minifyEnabled true 和确保不禁用混淆。步骤5—保持崩溃报告可读 release 混淆的堆栈跟踪在没有映射文件的情况下是无用的。保持

步骤5—保持崩溃报告可读

混淆的堆栈跟踪在没有映射文件的情况下是无用的。保持 mapping.txt 针对每个Play版本：

  • Play控制台： 测试和发布 → 应用程序包浏览器 → 下载 → 资产然后上传 mapping.txt 如果它尚未附加
  • Firebase Crashlytics / Sentry：将相同的映射作为CI的一部分上传

Android Studio / AGP通常在映射中嵌入 .aab仍然在首次优化上传后验证Assets选项卡

步骤 6 — 上传并重新检查Play

将新的 .aab 上传到内部测试跟踪（不需要刷新分数的生产环境）。打开：

  1. 测试和发布 → 应用程序包浏览器 为了那个版本
  2. DEX大小加上混淆/优化/压缩百分比
  3. 监控并改进 → Android vitals 新版本发布后，Google Play会分析

您需要 每个指标的25%，而不是仅仅是混淆。启用R8时， 通常会将__CAPGO_KEEP_0__应用从单位百分比的混淆率跃升到所有三个指标的25%以上。 proguard-android-optimize.txt usually jumps a Capacitor app from single-digit obfuscation to well above 25% on all three.

强制 执行 25%的最低门槛，当DEX大小超过10MB时，对于应用（50MB对于游戏）。即使低于这个门槛，修复它仍然值得：DEX大小更小，占用内存更少，启动速度更快。

如果您仍然低于25%

R8已启用，但Play（或本地分析器）仍显示弱分数。广泛保留规则是通常的遗留物。

  1. 打开 R8配置分析器 如果您的Android Gradle插件版本为9.3或更高—— assembleRelease 然后写入 configanalyzer.html 下一个 mapping.txt. 在AGP 9.2及更早版本中，跳过该HTML文件，使用 mapping.txtAPK分析器，和Play的App包浏览器代替。
  2. 按保留规则的冻结应用程序比例排序。库消费者规则无法编辑是正常的。应用级别 -keep class com.foo.** { *; } 不是。
  3. 打开 .aab 在Android Studio APK分析器中，选择大型 .dex 文件和切换脱混淆的名称（需要） mapping.txt那些保持庞大可读的包是需要停止大规模保留的包
  4. 更新仍然引用 proguard-android.txt这个文件在AGP 9中阻止了优化，并且在旧版插件中是一个红旗

不要通过 minifyEnabled false 和希望他uristic改变来修复一个低分数。Play想要缩小，优化 和 混淆

这并不能取代

  • JavaScript压缩 在 vite.config.ts 这并不能移动这个指标
  • Capgo 实时更新 __CAPGO_KEEP_0__ 发布 HTML/JS/CSS。它们不重建 DEX。商店二进制文件中启用 R8 后，您仍可以通过 airship JS 修复。
  • 16 KB 页面大小 这是一个独立的 Play 原生要求。请参见 Android 16 KB 页面大小.

如果您已经使用 Capgo 构建, 则更改 android/app/build.gradle 在仓库中。下一个云构建会获取 R8。您不需要不同的 Play pipeline，只需使用 minification 生成的发布二进制文件。同样，如果您保留 GitHub Actions Android 构建: 工作流必须组装 发布, not debug.

FAQ

Will enabling R8 break my Capacitor plugins?

会启用R8破坏我的Capacitor插件吗? narrow 如果插件使用反射并没有提供任何保留规则,那么是可能的。核心__CAPGO_KEEP_0__已经保留了插件类。测试一个发布版本。只为导致崩溃的包添加一个保留规则。如果插件未维护, Capgo咨询 can fork and keep it building.

Does npx cap run prove I passed the check?

No. That command uses a debug build with R8 off. Use bundleRelease / a signed Play upload.

We already set minifyEnabled true and still see 3%. 为什么?

Search for -dontobfuscate, proguard-android.txt, android.enableR8.fullMode=false, and blanket -keep rules. 确认 CI 已经上传了最小化的 AAB 文件，而不是旧的 artifact。

Do we need ProGuard instead of R8?

不。R8 是 Android Gradle Plugin 的压缩器。它读取 ProGuard 风格的规则文件。Google 的 Play 文档允许任何压缩器；R8 是 Capacitor 应用程序应该使用的。

Checklist

  • release { minifyEnabled true; shrinkResources true }
  • proguard-android-optimize.txt (not proguard-android.txt)
  • 不 -dontobfuscate / -dontoptimize / app-wide -keep class **
  • Capacitor 3.2.3+ 所以插件消费者规则适用
  • Release build produces mapping.txt
  • Native plugins tested on a release install
  • 新 .aab 已上传; 在 App bundle explorer 中映射
  • 混淆、优化和缩小各 25%+

这是整个 Play Console 警告： Capacitor 左 R8 离开，Play 开始评分 DEX，且一行 release Gradle 更改加上一个商店上传即可修复。

Keep going from Fix Google Play Obfuscation Below 25% in Capacitor Apps

如果您正在使用 Fix Google Play Obfuscation Below 25% in Capacitor Apps 来规划 Android 商店发布，连接它到 Capgo 原生构建 用于发布 App Bundle Capgo CI/CD 为上传管线 CI/CD 集成 context:Capgo Builder / 原生云构建产品页面. 角色: 短 UI 标签或导航项. 消息键 `native_build_feature_ci_cd` (Native Build Feature Ci Cd). Automatic Capacitor Android build with GitHub actions 自动 __CAPGO_KEEP_0__ Android 构建 Capgo Consulting 自主托管管线

实时更新 Capacitor 应用

当 web 层 bug 活跃时，通过 Capgo 发送修复而不是等待几天的 app store 审核。用户在后台接收更新，而原生变化仍然在正常审查路径中。

来自马丁的人性化支持

立即开始

最新博客

Capgo gives you the best insights you need to create a truly professional mobile app.

2-Way Communication in Capacitor Apps
开发 移动 +1
2025年4月26日

2-Way Communication in Capacitor Apps

避免的5种OTA更新常见错误
开发 安全 +1
2025年4月13日

避免的5种OTA更新错误

移动应用实时更新的5种安全最佳实践
开发 移动 +1
2025年1月14日

移动应用实时更新的5种安全最佳实践

查看我们博客中的所有内容