Godot Engine Android 平台第三方库溯源管理：从 THIRDPARTY.md 到 apksig 签名实现详解

本文以 platform/android/java/THIRDPARTY.md 为核心文档，解析 Godot Engine 在 Android 源码目录中登记第三方库来源、版本、许可证与修改记录的做法。读完后，你将理解该清单中三个第三方库（Play APK Expansion、Play Licensing、AOSP apksig）各自的定位与现状，并掌握从文档条目反查到仓库实际源码、验证 vendored 代码真实落地的方法。

1. THIRDPARTY.md 的定位与记录格式

THIRDPARTY.md 位于 platform/android/java/ 目录根部——该目录是 Godot 的 Android Gradle 子工程，由 settings.gradle 组织出 app（运行时 APK 骨架）、lib（Godot 共享库代码）与 editor（Godot 编辑器的 Android 端工程）等模块。这份文档的自述目标是：列出 Android 源码目录中使用的所有第三方库，记录它们的来源（provenance），以及“在相关时”对这些文件所做的修改。

文档对每个库条目都固定了四类信息要素：

要素	说明	示例（文档原文口径）
Upstream	上游来源（Google Play 官方库 / AOSP 平台仓库）及具体子目录	apkx_library、lvl_library、platform/tools/apksig
Version	精确到 git commit 号与年份	9ecf54e, 2017、eb57657, 2018、ac5cbb07..., 2024
License	许可证类型	三个库均为 Apache 2.0
Overwrite targets	vendored 文件覆盖进仓库的目标目录	lib/src/...、editor/src/main/java/...

需要特别注意一个路径约定：文档中写的覆盖目录（如 lib/src/com/...、editor/src/main/java/com/android/apksig）是相对于 platform/android/java/ 目录的。换算到仓库根目录时，需要在前面补上 platform/android/java/ 前缀。例如 apksig 条目写的是 editor/src/main/java/com/android/apksig，其真实仓库路径即 platform/android/java/editor/src/main/java/com/android/apksig。

这种“上游地址 + 精确 commit + 修改补丁位置”的记录方式，是 vendored（直接内嵌）第三方源码时典型的合规与可维护性实践：既能让下游用户追溯每个文件的出处，也能在升级时对照上游重新 diff。

2. 三个第三方库的登记条目

2.1 com.google.android.vending.expansion.downloader（Play APK Expansion）

• 上游：Google Play APK Expansion 官方库的 apkx_library 子目录
• 版本：git 9ecf54e（2017 年）
• 许可证：Apache 2.0
• 覆盖目录：lib/src/com/google/android/vending/expansion/downloader
• 修改记录：文档明确写道“部分文件的修改原因尚不明确（yet unclear reasons）”，修改内容见 lib/patches/com.google.android.vending.expansion.downloader.patch

该库属于 Google Play 的 APK Expansion 方案，典型用途是为大型游戏分发额外容量数据文件。文档没有说明引入它的历史动机，也诚实地将部分修改标注为“原因不明”，只保留了 patch 文件供后续追查——这种“如实记录但不掩饰不确定性”的写法本身值得参考。

2.2 com.google.android.vending.licensing（Play Licensing）

• 上游：Google Play Licensing（LVL）官方库的 lvl_library 子目录
• 版本：git eb57657（2018 年），文档特别注明“with modifications”（含修改）
• 许可证：Apache 2.0
• 覆盖目录：lib/aidl/com/android/vending/licensing 与 lib/src/com/google/android/vending/licensing
• 修改记录：文档给出明确动机——“为消除 linter 报错或修复下游问题”，修改内容见 lib/patches/com.google.android.vending.licensing.patch

条目中的 lib/aidl/ 目标值得注意：AIDL（Android Interface Definition Language）文件定义跨进程服务接口，说明 Godot 当年 vendored 的不仅是 LVL 的 Java 实现，还包括其与许可证服务通信所需的接口定义。

2.3 com.android.apksig（AOSP APK 签名/验签库）

• 上游：AOSP 平台仓库 platform/tools/apksig
• 版本：git ac5cbb07d87cc342fcf07715857a812305d69888（2024 年）
• 许可证：Apache 2.0
• 覆盖目录：editor/src/main/java/com/android/apksig

与前两个条目不同，apksig 被放置到 editor 模块而非 lib 模块。结合 4 节的源码分析可以推断，这一选择与其服务对象（Godot 编辑器的 APK 签名流程）直接相关。

3. 文档条目与当前仓库快照的比对

对当前仓库实际检索后，可以得到两个与文档对照的结论：

apksig 条目仍然有效。 在 platform/android 范围内检索 com.android.apksig，完整源码确实存在于 platform/android/java/editor/src/main/java/com/android/apksig/ 下，包括顶层入口 ApkSigner.java、ApkVerifier.java 以及 internal/ 下的成套实现。

expansion downloader 与 licensing 两个条目在当前快照中已无对应源码。 检索 com.google.android.vending 时，platform/android 目录下唯一命中的文件就是 THIRDPARTY.md 本身；检索 *.patch 文件在 platform/android 下也无任何命中，即文档引用的 lib/patches/com.google.android.vending.expansion.downloader.patch 与 lib/patches/com.google.android.vending.licensing.patch 两个补丁文件当前均不在树中。需要谨慎表述：仓库未提供这两处源码移出的原因说明，这里只能确认“当前快照中不存在”，不能断言移出的具体缘由。

这说明 THIRDPARTY.md 的性质是溯源与修改记录：它的价值在于记录历史上哪些第三方文件被内嵌、被改在哪里；条目与源码树的状态可能随演进而不同步，读者应以文档为线索、以当前树为事实做双向核对。

另外，当前源码树中仍保留 expansion 相关处理，命中点包括 GodotLib.java、Godot.kt、os_android.cpp 等。从源码结构看，这部分主要对应引擎在 Android 上读取游戏数据文件（.pck）的既有机制，与文档所登记的 Play APK Expansion downloader 库并非同一层面，阅读时不必混淆。

4. 源码级佐证：apksig 在 Godot 编辑器中的落地

apksig 条目是唯一与当前源码树直接对应的条目，其实现范围可以从文件列表完整核对：

• 四种签名方案的完整实现：internal/apk/v1（传统 JAR 签名）、v2 方案（APK Signing Block）、internal/apk/v3（支持签名证书轮换）、v4 方案（文件级增量签名），且每种方案都同时提供 Signer 与 Verifier；
• source stamp（来源印章）：internal/apk/stamp/ 下的 V1/V2 版本实现；
• 底层支撑：ASN.1 BER/DER 编解码（internal/asn1/）、PKCS7 解析（internal/pkcs7/）、X.509 证书解析（internal/x509/）、zip 结构工具（internal/zip/、internal/util/）。

检索 com.android.apksig 的命中点中还包含 ApkSignerUtil.kt，这是 Godot 编辑器自身的工具类。可以推断：Godot 编辑器在 Android 端导出/签名 APK 的流程，是基于这份本地 vendored 的 AOSP apksig 实现来完成的，签名与验签能力直接内嵌在编辑器工程中，而不是依赖外部构建工具。这也解释了文档为何把 apksig 的覆盖目录放在 editor 模块而非共享的 lib 模块。

从许可证角度看，文档登记的三个库全部为 Apache 2.0，彼此保持一致的宽松许可取向，便于与 Godot 引擎主体代码共存于同一仓库中。

5. 这份溯源文档带来的工程实践

以 THIRDPARTY.md 为样本，Godot 在 Android 目录的第三方源码管理给出了几条可复用的做法：

1. 锁定精确版本：不写“latest”或模糊版本号，一律写 git commit 号加年份（如 ac5cbb07d87cc342fcf07715857a812305d69888, 2024），使任何条目都可复现；
2. 写明覆盖目标目录：读者能直接定位 vendored 代码在树中的位置，并需注意文档路径是相对 platform/android/java/ 的，引用时须转换为仓库根目录起算的完整路径；
3. 修改独立成 patch 文件：对上游的改动集中放在 lib/patches/<库名>.patch，与源码本体分离，升级时可以对上游重新生成 diff；
4. 诚实标注不确定性：修改动机不明时写明“yet unclear reasons”，而不是省略该信息。

对维护者而言，这类文档与源码树应视为“记录—事实”两层：文档给出历史与出处，源码树给出当下状态，两者结合使用（如第 3 节所示的检索比对）才是完整的使用方式。