如何安全配置 Android SDK 的 ProGuard 混淆规则

如何将移动端 SDK 排除在 Android ProGuard 混淆之外？要将 Android SDK 排除在代码混淆之外，研发团队需要先核查该依赖库是否已内置 consumer ProGuard 规则，随后针对反射调用的入口点、回调接口、JNI 桥接方法以及数据模型添加精准作用域的 -keep 和 -keepclassmembers 指令，并通过 R8 诊断报告与原始 DEX 字节码检查来审计最终保留的符号。当 Android 工程团队在生产环境的 Release 构建中开启代码缩减（Code Shrinking）与优化时，R8 编译器会移除未被直接引用的字节码，并将类、字段及方法重命名为简短的标识符。如果移动安装归因 SDK（Software Development Kit）依赖动态反射或 JNI 回调，且未针对高强度的 Tree-shaking 和重命名配置保护规则，那么即使在未混淆的 Debug 测试包中通过了全部验证，延迟深度链接（Deferred Deep Linking）、JSON 模型反序列化以及渠道包生成（Channel Package）依然可能在正式生产环境中静默失效。作为专注于移动渠道归因与深度链接的平台，OpoInstall 提供了原生 Android SDK 归档包与渠道分包工作流，方便工程团队在开启 R8 缩减的 Release 流水线中完成配置与校验。

在现代 Android Gradle Plugin (AGP) 工具链中，保留规则文件（传统 DSL 中的 proguard-rules.pro，或 AGP 9.3+ 中的 src/<variant>/keepRules/*.keep）充当着 Google R8 编译器的规则配置契约。安全地将第三方 Android SDK 排除在混淆之外，核心在于仅保留运行时必需的特定公开 API 入口、反射构造函数、回调接口、JNI 上行调用（Upcalls）及数据模型字段——同时避免使用范围过宽的包级别通配保留规则，或未经验证就盲目抑制构建警告。

为什么 R8 与 ProGuard 混淆会破坏 Android SDK 的归因回调

Debug 与 Release 的差异陷阱：为什么归因在测试环境正常，上线却失效

在移动获客与增长工程中，最常见的发版回归问题之一就是：应用的延迟深度链接（handleDeepLink）与安装参数还原（getInstallParam）在 QA 阶段的 Debug 构建包上运行稳定，但一旦编译为签名后的正式版 Release APK 或 Android App Bundle（.aab），就会返回空数据或不再触发回调。

根本原因在于 Gradle 中配置的构建类型（Build Type）差异。默认情况下，debug 构建类型会关闭代码缩减以加快增量编译速度。而当工程师开启 R8 优化并编译 release 变体时，Android Gradle Plugin 会调用 Android R8 编译器，对宿主应用及所链接的第三方库执行三项字节码转换：

• 代码缩减（Tree Shaking）：R8 从声明的入口点（如 AndroidManifest.xml 组件与显式的 -keep 种子）出发分析应用的调用图，并剥离静态分析判定为不可达的所有类、构造函数、方法或字段。
• 字节码优化与访问权限修改：R8 会内联方法、移除未使用的参数、合并类，并且在配合 Android 默认优化配置中的 -allowaccessmodification 指令时，修改类与成员的可见性标志（例如在内联过程中将 private 或包级私有成员扩大为 public），从而减小 Dalvik 可执行文件（.dex）体积并提升运行时执行速度。
• 标识符混淆（重命名与重打包）：R8 会将保留下来的类、包、字段和方法重命名为紧凑的简短标识符（如 a.a.b()），并可能将混淆后的类重新打包到扁平化的包层级中，以降低 classes.dex 内部的字符串池开销。

自 Android Gradle Plugin (AGP) 8.0 起，R8 Full Mode（完全模式） 已默认开启。与传统的 ProGuard 兼容模式相比，R8 Full Mode 执行了更为严格的优化策略——除非相关类和成员被匹配的 keep 规则显式保留，否则它会移除默认的无参构造函数（<init>()）、更改成员访问修饰符并剥离元数据属性。关于 .aar 二进制结构及 SDK 选型标准的基础背景，请参阅我们的配套指南：深入理解移动 SDK 的核心概念与技术增长协议 以及 如何选择支持精准归因的软件开发工具包（SDK）。

混淆环境下归因 SDK 的六种典型失效模式

由于静态调用图分析无法预测运行时的动态查找，缺乏保护规则的 Android SDK 在 R8 Full Mode 下会出现六种截然不同的失效模式。工程师需要仔细区分这些模式，因为每种情况都需要对应特定的 ProGuard 保护目标：

[Android Release Build: R8 Full Mode Enabled]
                      |
                      v
     [R8 Evaluates Bundled & Host Keep Rules]
                      |
      +---------------+---------------+
      |                               |
      v (Missing / Mismatched Rules)  v (Scoped Keep Rules + Attributes Active)
[SDK Symbols Stripped or Renamed] [Required SDK Entry Points & Models Preserved]
- Reflective () Removed     - Confirmed in -printseeds (seeds.txt)
- JNI Upcall / Model Fields Lost  - Verified in Raw DEX (apkanalyzer dex packages)
- Generic Signature Metadata Lost - Release Attribution Matches Debug Behavior

AAR 包内置 Consumer 规则与手动导入 JAR 的对比

AAR 与 JAR 库如何内置 Consumer ProGuard 规则

在向宿主应用手动添加排除规则之前，请先检查第三方 Android SDK 是否已经内置了开箱即用的 R8 规则。正如 Google Android 开发者库优化指南 中所述，AGP 和 R8 支持在 .aar 与 .jar 两种分发格式中自动发现 consumer 规则，包括针对特定版本范围的 R8 规则：

（关于 Gson 序列化规则的补充说明：正如 Gson 针对 ProGuard 与 R8 的故障排查指南 所记录的，Gson 2.11.0 及更高版本已为 TypeToken 和带有 @SerializedName 注解的字段内置了 R8 规则。但这些内置规则并不能替代工程团队对反射模型访问的约束，开发者仍需提供兼容的无参构造函数，并在开启代码缩减的 Release 构建中全面测试所有序列化与反序列化路径。）

编写规则前：先检查下载的 SDK 归档包结构

ProGuard 与 R8 的规则匹配严格区分大小写，且要求包路径完全一致。在不同的 SDK 版本或区域分发包中，包命名空间可能存在差异——如果你直接复制了旧版教程中的规则，而其中的包名大小写与当前归档包内实际的 .class 文件不符，R8 将静默匹配零个类，不会抛出任何错误提示。

在编辑 keep 规则之前，请先下载目标 SDK 软件包（例如从 移动 SDK 下载中心 获取 Android SDK v2.1.0），并检查其内置规则（同时查看 /proguard.txt 与 classes.jar 内部）以及准确的 .class 目录层级：

# 1. Inspect an .aar archive for root consumer rules (proguard.txt) and extract classes.jar to check META-INF rules
unzip -l opoinstall-android-sdk.aar
unzip -p opoinstall-android-sdk.aar proguard.txt
unzip -p opoinstall-android-sdk.aar classes.jar > temp_classes.jar
jar tf temp_classes.jar | grep -E "META-INF/proguard/|META-INF/com\.android\.tools/|\.class$"

# 2. If using a standalone .jar archive, inspect embedded META-INF rules and exact case-sensitive .class paths
jar tf libs/OpoInstall_SDK.jar | grep -E "META-INF/proguard/|META-INF/com\.android\.tools/|\.class$"

为归因类 Android SDK 配置 proguard-rules.pro

规避包级全量保留反模式与盲目警告抑制

在编写自定义规则时，工程师应当遵循 Google 官方的 选择要保留的内容（R8 Keep 规则） 最佳实践，避免不必要地削弱编译优化效果：

• 优先使用精准规则，规避包级通配 -keep class package.** { *; } 反模式：一刀切的包级通配规则会强制 R8 保留该包下的每一个内部辅助类，并跳过对它们的所有优化。建议将规则作用域收敛到运行时动态访问的具体类、构造函数（<init>();）、回调接口、JNI 目标以及数据模型字段（或者在你可控的自研代码上使用 Jetpack 的 @UnconditionallyKeep 注解）。
• 在数据模型上严格区分 -keep 与 -keepclassmembers：-keepclassmembers 仅在包含这些成员的类本身已被保留在调用图中时，才会保留指定的字段或方法。如果某个数据模型（如 OpoData）仅通过反射进行实例化，或仅通过编译期被擦除的泛型类型进行引用，则必须使用 -keep class ...，以防 R8 将该类本身直接移除。
• 理解 -keepclasseswithmembernames 在 JNI 场景下的局限性：Android 默认优化规则包含 -keepclasseswithmembernames,includedescriptorclasses class * { native <methods>; }。根据 Google R8 Keep 规则文档及 ProGuard 官方手册关于 Keep 指令的说明，-keepclasseswithmembernames 等价于 -keepclasseswithmembers,allowshrinking。它只会为在代码缩减阶段存活下来的匹配类和成员保留名称，但不会阻止未被直接引用的类或 native 方法在缩减阶段被移除。如果 native 方法是通过 RegisterNatives 动态注册且没有直接的 Java 调用点，或者 C/C++ 代码通过 JNI 上行调用反向触发 Java 方法，你必须根据目标类的实例化方式，显式使用 -keep 或 -keepclassmembers 规则。
• 避免未经核实的全局 -dontwarn 指令：-dontwarn 对代码缩减或重命名没有任何保护作用，反而会掩盖未解析的引用警告，进而导致运行时爆发隐藏的 NoClassDefFoundError 崩溃。仅当构建日志明确报告某个仅在编译期存在的缺失类，且你已核实该类在运行时确实为可选项时，才添加精准作用域的 -dontwarn。

在 AGP 8.x 与 AGP 9.3+ 工具链中配置 Gradle

Android Gradle Plugin 9.3 引入了简化的 optimization DSL 代码块以及区分构建变体的 keepRules 目录（.keep 文件），而 AGP 8.x 至 9.2（以及 AGP 9.3+ 中仍向后兼容的传统配置）则使用 isMinifyEnabled 和 proguardFiles。工程师应当清晰区分以下三类配置对象：

// Option A: AGP 8.x - 9.2 Legacy DSL (also supported in AGP 9.3+) — app/build.gradle.kts
android {
    buildTypes {
        getByName("release") {
            isMinifyEnabled = true
            isShrinkResources = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

// Option B: AGP 9.3+ Simplified Optimization DSL — app/build.gradle.kts
// Place scoped class/member keep rules in app/src/main/keepRules/sdk-attribution.keep
android {
    buildTypes {
        release {
            optimization {
                enable = true
            }
        }
    }
}

精准作用域 Keep 规则与诊断指令示例

由于 OpoInstall 的公开文档与历史 FAQ 页面中曾引用过不同的包名前缀（如 com.opoinstall.api.** 与 com.fm.OpoInstall.** 或 io.OpoInstall.**），下方的规则集仅作结构性示例——并非针对 OpoInstall SDK v2.1.0 的生产环境实测规则集。请务必先检查你所下载的 v2.1.0 归档包内的实际类路径与内置 consumer 规则，并查阅 OpoInstall 技术文档（有关底层 Java 生命周期代码的实现逻辑，可参考 软件开发工具包（SDK）如何驱动移动归因与业务增长）：

# File: app/src/main/keepRules/sdk-attribution.keep (or app/proguard-rules.pro)
# IMPORTANT: Illustrative only — not a verified production rule set for OpoInstall SDK v2.1.0.
# Verify exact case-sensitive package and class names inside your downloaded v2.1.0 archive
# via `jar tf` or `apkanalyzer`, and check `configuration.txt` for existing consumer rules.

# ---------------------------------------------------------------------------
# 1. Preserve Bytecode Attributes on Explicitly Kept Classes
# Required so generic callback interfaces (e.g., ResultCallBack<OpoData>)
# retain their parameterized type metadata in R8 Full Mode.
# ---------------------------------------------------------------------------
-keepattributes Signature, InnerClasses, EnclosingMethod, *Annotation*

# ---------------------------------------------------------------------------
# 2. Scoped SDK Entry Point, Callback Interface, and Data Model Rules
# ---------------------------------------------------------------------------

# Preserve public SDK entry point and any reflectively invoked constructors/methods:
-keep public class com.opoinstall.api.OpoInstall {
    <init>(...);
    public <methods>;
}

# Preserve callback listener interfaces and their callback methods:
-keep public interface com.opoinstall.api.ResultCallBack {
    public <methods>;
}

# Model Scenario A: If OpoData / OpoError models are instantiated dynamically via reflection
# or referenced only via erased generics, use -keep to preserve both the class and its members:
-keep class com.opoinstall.api.OpoData {
    <init>(...);
    <fields>;
    public <methods>;
}
-keep class com.opoinstall.api.OpoError {
    <init>(...);
    <fields>;
    public <methods>;
}

# Model Scenario B: If a model class is already directly retained in your host call graph
# and only its fields require protection from renaming, use -keepclassmembers:
# -keepclassmembers class com.opoinstall.api.OpoData { <fields>; }

# ---------------------------------------------------------------------------
# 3. JNI Downcall and Native-to-Java Upcall Protection (Illustrative JNI Patterns)
# ---------------------------------------------------------------------------
# JNI Case A: If Java/Kotlin code already directly instantiates the JNI bridge class,
# use -keepclassmembers,includedescriptorclasses for C/C++ upcall methods, and keep
# any parameter model classes/constructors instantiated by native code:
-keepclassmembers,includedescriptorclasses class com.example.sdk.internal.JniBridge {
    public void onNativeAttributionEvent(com.example.sdk.internal.NativeEventData);
}
-keep class com.example.sdk.internal.NativeEventData {
    <init>(...);
}

# JNI Case B: If native C/C++ code dynamically looks up or instantiates the Java class
# itself via FindClass / NewObject, or registers native methods via RegisterNatives
# without direct Java call sites, use -keep to prevent class and method removal:
-keep,includedescriptorclasses class com.example.sdk.internal.DynamicNativeBridge {
    <init>(...);
    public native <methods>;
    public void onNativeCallback(java.lang.String);
}

# File: app/proguard-rules.pro (Diagnostic Output Directives)
# Place R8 diagnostic report flags in your verified R8 configuration file.
# Paths resolve relative to the module working directory (`app/`).
# Adjust the directory name for product flavors (e.g., build/outputs/mapping/prodRelease/).
-printseeds build/outputs/mapping/release/seeds.txt
-printusage build/outputs/mapping/release/usage.txt
-printconfiguration build/outputs/mapping/release/configuration.txt

解决 Android 渠道包混淆与加固冲突

理清构建期 R8 编译、APK 对齐、签名与渠道分包的边界

针对 Google Play 以外的 Android 分发场景，OpoInstall 支持导出专属的 Android 渠道包——即基于开发者上传的母包（Base APK），批量生成携带独立 channelCode 追踪元数据的渠道专属 APK。

在排查导出渠道包的 Android渠道统计数据丢失或安装失败问题时，工程师需要从两个独立的发版校验维度进行隔离分析——APK 加密签名的有效性与厂商渠道元数据的完整性：

1. 构建期 R8 代码缩减：R8 在母包被打包和签名之前，于 Gradle 构建流水线内部将 Java/Kotlin 字节码编译为 classes.dex 时执行。R8 绝不会在已经导出的 APK 文件上运行。
2. Android APK 对齐 (zipalign) 与加密签名 (apksigner)：由 AGP 构建的标准 Release APK 会自动完成字节对齐。但如果你的发版流水线在签名之前对 APK 执行了自定义后处理或第三方 APK 加固，则必须严格遵循官方的 Android zipalign 规范 与 Android apksigner 规范 重新对齐 APK。zipalign 会将未压缩的数据按 4 字节边界对齐——且如果 APK 包含未压缩的原生 .so 动态库，团队应当使用 zipalign -P 16 -f -v 4 infile.apk outfile.apk 以满足 16 KB 页面对齐要求，并通过 zipalign -c -P 16 -v 4 验证对齐状态。zipalign 必须在使用 apksigner 签名之前执行，因为在签名之后对 APK 进行任何修改都会破坏其 V2/V3 全文件加密签名。
3. 厂商专属渠道元数据与签名校验：从 OpoInstall 控制台导出渠道 APK 之后，如果再对其运行第三方 APK 加固（加壳）或二次打包工具，可能会覆盖已写入的渠道元数据，或导致 APK 签名失效。如果某个第三方渠道包解析器要求特定的 APK 签名方案（例如在开启 V2/V3 全文件签名的同时启用 V1 JAR 签名），请在修改生产环境签名配置前，直接对照你当前使用的 OpoInstall 控制台文档或联系厂商技术支持核实该要求，切勿将 V1 签名视为 Android 操作系统的通用强制要求。

Android 渠道包的推荐发版流水线顺序

为了同时保障 APK 签名有效、R8 字节码优化到位以及厂商渠道元数据完整无损，请严格按照以下顺序执行发版流水线：

1. 使用 R8 编译并缩减母包 (Base APK)：带着已验证的 keep 规则运行 ./gradlew :app:assembleRelease，让 R8 在构建期完成对 classes.dex 的优化。
2. 在上传前完成所有加固、字节对齐与签名操作：如果安全团队使用了第三方 APK 加固工具，请先对母包执行加固，随后运行 zipalign -P 16 -f -v 4（若签名前需要重新对齐），使用 zipalign -c -P 16 -v 4 验证对齐结果，最后对母包完成签名。
3. 上传母包并独立验证导出的渠道 APK：将已完成签名和混淆的母包上传至 OpoInstall 控制台，导出各渠道 APK，并在正式对外分发前，针对导出的 APK 独立验证加密签名有效性（apksigner verify --verbose）与真机环境下的渠道归因回调。

[Recommended Channel Package Pipeline]:
Source Code -> Gradle R8 Minification -> (Optional Pre-Upload Hardening + zipalign -P 16 + Signing) -> Upload Base APK to Console -> Export Channel APK -> Verify Both Signature (apksigner) & Channel Callback

使用 R8 报告与 APK Analyzer 审计保留的 SDK 符号

在 AGP 9.3+ 中使用独立的 R8 配置分析器

在 Android Gradle Plugin 9.3 及更高版本中，你无需等待完整的 Release APK 或 App Bundle 编译结束，即可审计 keep 规则的合并与匹配情况。AGP 9.3+ 提供了专属的 analyze<Variant>R8Config Gradle 任务（例如运行 ./gradlew :app:analyzeReleaseR8Config），它能够快速评估 consumer 规则与宿主 keep 规则并输出配置诊断信息，方便工程师在执行完整 Release 构建之前高效迭代 .keep 规则。

交叉核对 configuration.txt、seeds.txt、usage.txt 与 mapping.txt

切勿仅仅因为 ./gradlew :app:assembleRelease 编译成功且未报错，就想当然地认为某条 -keep 规则已经生效。为了确定性地验证配置结果，请检查生成在 app/build/outputs/mapping/<buildVariant>/ 目录下的四个 R8 诊断文件（若需调试某个特定符号为何被保留，可使用 -whyareyoukeeping class <ClassName> 指令）：

• configuration.txt：包含 R8 实际应用的完整合并规则集——汇集了宿主 keep 规则、默认 Android 平台规则、AAPT2 规则，以及所链接的 .aar 和 .jar 库中内置的所有 /proguard.txt 或 /META-INF/ 规则。
• seeds.txt：列出与当前激活的 -keep 规则成功匹配的每一个类、构造函数（<init>()）、方法和字段。请注意，出现在 seeds.txt 中可以确认规则语法匹配成功，但仍需配合 DEX 字节码检查与真机运行时测试。
• usage.txt：列出 R8 在 Tree-shaking 期间从 APK 中剥离的无用代码（Dead Code）。请务必确认你所需的任何 SDK 类、反射构造函数或 JNI 上行调用方法均未出现在 usage.txt 中。
• mapping.txt：记录保留下来的类与成员在混淆前后的标识符映射关系。需要特别注意的是，某个类未出现在 mapping.txt 中，并不能证明它以原始名称被保留了下来——它很可能在代码缩减阶段就已经被彻底移除（并被记录在 usage.txt 中）。因此，务必将 mapping.txt 与 seeds.txt、usage.txt 以及编译后的 DEX 文件进行交叉比对。

使用 apkanalyzer 验证原始 DEX 标识符与反混淆报告状态

在使用官方的 Google Android 开发者 APK Analyzer CLI 检查 Release APK 时，必须严格区分编译后的原始 DEX 标识符与经 mapping 映射还原后的反混淆名称：

• 检查编译后的原始 DEX 名称（不带 --proguard-mappings 参数）：当你向 apkanalyzer 传入 --proguard-mappings mapping.txt 时，该工具会将混淆后的 DEX 名称（如 a.b.c）还原为原始源码名称进行展示。因此，在启用 --proguard-mappings 时看到原始类名，并不能证明该符号在 classes.dex 中躲过了重命名。请务必先在不带 --proguard-mappings 参数的情况下运行 apkanalyzer dex packages。此外，由于 R8 的类重打包（Repackaging）机制可能会将类移动到扁平化的包路径下，请不要仅依赖针对包名的 grep 搜索；应当检查原始 DEX 类树、核实反射入口点的类名、检查 JNI 方法名与描述符签名，并交叉比对 mapping.txt，以确认必需的方法和字段未被重命名。
• 检查 R8 保留状态标志（同时传入 --proguard-mappings、--proguard-seeds 与 --proguard-usages）：在第二轮检查中，同时传入这三个 R8 报告文件，即可还原出每一个包（P）、类（C）、方法（M）和字段（F）的保留状态标志（k 代表被 seed 规则保留，x 代表在缩减阶段被移除，r 代表被引用，d 代表已定义）：

# Run from the Android project root directory (adjust variant path for product flavors, e.g., prodRelease)

# 1. (AGP 9.3+) Run the standalone R8 configuration analyzer for rapid rule verification, then build release APK
./gradlew :app:analyzeReleaseR8Config
./gradlew :app:assembleRelease

# 2. Inspect the merged R8 configuration, matched seeds, and stripped usage reports
grep -i -C 3 "opoinstall" app/build/outputs/mapping/release/configuration.txt
grep -i "opoinstall" app/build/outputs/mapping/release/seeds.txt
grep -i "opoinstall" app/build/outputs/mapping/release/usage.txt

# 3A. Inspect RAW compiled DEX identifiers (WITHOUT --proguard-mappings)
# Also inspect the full raw DEX tree and cross-check mapping.txt in case R8 repackaged classes
apkanalyzer dex packages app/build/outputs/apk/release/app-release.apk | grep -i "opoinstall"

# 3B. Inspect R8 retention state flags (k = kept, x = removed, r = referenced, d = defined) WITH R8 report files
apkanalyzer dex packages \
  --proguard-mappings app/build/outputs/mapping/release/mapping.txt \
  --proguard-seeds app/build/outputs/mapping/release/seeds.txt \
  --proguard-usages app/build/outputs/mapping/release/usage.txt \
  app/build/outputs/apk/release/app-release.apk | grep -i "opoinstall"

# 4. Verify 16 KB page alignment (if native .so files are present) and cryptographic APK signatures
zipalign -c -P 16 -v 4 app/build/outputs/apk/release/app-release.apk
apksigner verify --verbose app/build/outputs/apk/release/app-release.apk

Release 构建归因故障排查矩阵

诊断开启代码缩减的 Android 构建中静默发生的归因与深度链接故障

当排查仅在开启代码缩减的 Release 构建中出现的归因数据异常时，可参考下方的诊断矩阵快速定位根本原因：

总结与 Release 构建核查清单

掌握如何将移动端 SDK 排除在 Android ProGuard 与 R8 混淆之外，是防止应用从 Debug 测试转向生产环境 Release 构建时发生静默归因故障的关键。通过核查内置的 consumer 规则、编写与 SDK 归档包内严格区分大小写的类路径完全匹配的精准作用域 -keep 指令、遵循 Android 渠道包上传前的构建顺序，并将 R8 诊断输出文件与原始 DEX 字节码进行交叉比对，Android 工程师可以在保持完整代码缩减优化的同时，确保延迟深度链接与安装参数还原稳定运行。

在将开启代码缩减的 Android Release 构建包发布至 Google Play 或导出渠道包之前，请执行以下四步核查清单：

• 检查 SDK 归档包与合并后的配置：使用 jar tf 或 unzip -l 检查下载的 SDK 归档包（如 v2.1.0），核实准确的类路径与内置的 consumer 规则，并运行 ./gradlew :app:analyzeReleaseR8Config（适用于 AGP 9.3+）或查阅 configuration.txt。

• 交叉核对 R8 报告与原始 DEX 标识符：确认必需的 SDK 入口点、反射 <init>() 构造函数、OpoData 模型字段、ResultCallBack 方法以及 JNI 签名均已出现在 seeds.txt 中，未出现在 usage.txt 中，并且在原始的 apkanalyzer dex packages 输出（不带 --proguard-mappings 运行）和 mapping.txt 中保留了原始名称。

• 严格执行上传前缩减并验证渠道 APK 签名：在上传母包以导出 Android 渠道包之前，在母包上完成全部的 R8 代码缩减、第三方加固、zipalign（zipalign -c -P 16 -v 4）以及 APK 签名操作，并对导出的渠道包运行 apksigner verify --verbose。

• 执行物理真机 Release 冒烟测试：将已完成签名和代码缩减的 Release APK 安装到真实的 Android 设备上，实测验证 H5 传参安装（getInstallParam）与一键拉起（handleDeepLink）功能。

工程团队可以在 OpoInstall 开发者控制台 注册应用并上传混淆后的母包，快速测试渠道包导出并验证 Release 构建环境下的安装参数还原效果。

相关参考资料

• 核心概念：Android R8 代码缩减（Code Shrinking）、标识符混淆（Identifier Obfuscation）、Consumer ProGuard 规则、渠道包构建顺序

• 相关技术：Android Gradle Plugin (AGP)、R8 编译器、proguard-rules.pro、Android Studio APK Analyzer

• 安全标准：OWASP 移动应用安全项目 (MAS)

• 平台与集成接口：isMinifyEnabled, optimization.enable, analyzeReleaseR8Config, consumerProguardFiles, seeds.txt, usage.txt, apkanalyzer dex packages, apksigner, zipalign

• 官方文档与参考链接：

  • Google Android 开发者指南：缩减、混淆和优化应用 (R8 / ProGuard)

  • Google Android 开发者指南：选择要保留的内容 (R8 Keep 规则)

  • Google Android 开发者指南：Android 库 Consumer ProGuard 文件配置

  • Google Android 开发者指南：APK Analyzer 命令行工具

  • Google Android 开发者指南：apksigner 签名工具

  • Google Android 开发者指南：zipalign 对齐工具

  • Gson 针对 ProGuard 与 R8 的故障排查指南

  • Guardsquare ProGuard 配置用法手册

  • OWASP 移动应用安全项目 (MAS)