RK3566 Android15去掉repo后编译报错？一招enabled: false搞定

 

适用场景：Rockchip RK3566 + Android 15 平台，移除 repo 多仓库管理后编译中断问题

做 RK3566 Android15 开发的同学大概率都遇到过：把官方 SDK 从 repo 多仓库改成单体仓库后，编译直接报错，明明代码没改几行，却卡在各种测试模块的依赖缺失上。今天就把这个问题的根因、解决方案和避坑要点一次性讲透。

一、为什么要跟 repo 说再见？

Rockchip 官方 SDK 用 Google 的 repo 工具管理上百个 Git 仓库，看似模块化，实则对小团队极不友好：

•初始化同步动辄几十 GB，网络差的时候同步半天还容易断；

•多仓库分散管理，定制产品时改了 A 仓库漏了 B 仓库是家常便饭；

•CI/CD 流水线搭建复杂，新人上手光理解 repo 流程就得好几天。

所以很多团队都会选择把 SDK “扁平化”：删掉.repo 目录，整合成一个单体仓库，从此告别 repo sync。但问题也随之而来 —— 编译报错了。

二、报错的核心原因：依赖的仓库“消失了”

编译系统（Soong/Blueprint）在解析阶段会扫描所有 Android.bp 文件，哪怕是平时用不到的测试模块，只要它引用了其他 repo 仓库的文件，而这些仓库已经被删掉，就会直接报错退出。

最典型的就是 external/skia/Android.bp 里的 CtsSkQPTestCases 模块：
这个 CTS 测试模块依赖了 platform/cts 仓库的 cts_defaults 配置，去掉 repo 后 platform/cts 仓库没了，Soong 解析时找不到依赖，自然就卡壳了。

简单说：这是个“别人家仓库” 的模块，你没拉人家的代码，编译系统却硬要去构建，不报错才怪。

三、三种解决方案，推荐第一种

方案 1：直接加 enabled: false（最推荐）

在报错模块的 Android.bp 中添加一行 enabled: false：

•  
•  
•  
•  
•  
•  
•  
•  
•  
•  
•  

android_test {    name: "CtsSkQPTestCases",    team: "trendy_team_android_core_graphics_stack",    enabled: false,  // 关键：屏蔽这个模块    defaults: ["cts_defaults"],    test_suites: [        "general-tests",        "mainline-tests",    ],    ...}

这是最干净的做法，Soong 在解析阶段就会跳过该模块，既不影响其他模块，也不会留下后遗症。

方案 2：产品配置中排除（有局限性）

在 device/rockchip/xxx/[BoardConfig.mk](BoardConfig.mk) 中添加：

•  

PRODUCT_PACKAGES -= CtsSkQPTestCases

 注意：这个方案只在编译阶段生效，如果 Soong 解析阶段就因为文件不存在报错，此方法无效。

方案 3：条件编译（适合复杂场景）

•  
•  
•  
•  

android_test {    name: "CtsSkQPTestCases",    enabled: $(WITH_CTS_TESTS),  // 通过环境变量控制}

适合需要在不同构建变体中切换的场景，但对单纯去掉 repo 的需求来说，属于 “杀鸡用牛刀”。

四、避坑关键：这些细节一定要注意

1. 不止 Skia，要全面排查

去掉 repo 后，所有依赖外部仓库的测试模块都可能出问题，重点检查这些类型：

模块类型	典型路径	依赖仓库
CTS 测试	external/*/Android.bp 中的 android_test	platform/cts
GTS/VTS 测试	各模块的 android_test	platform/gts、platform/vts
vendor 测试	hardware/*/tests	各 vendor 仓库

可以用这个命令快速扫描：

•  

grep -rn "enabled.*false" --include="*.bp" external/ | head

对比官方 SDK，找出未被禁用的测试模块逐一处理。

2. 别直接删模块，留一线生机

千万不要图省事删除模块定义！原因很实在：

•后续上游更新时容易产生冲突；

•万一哪天要重新用 repo，恢复模块比重新写简单多了；

•保留原始代码 + enabled: false，是最小侵入式修改，方便后续追踪。

3. 注意 CTS 认证的影响

如果项目需要过 Google CTS/GMS 认证，这些测试模块是必须的。要么单独拉回 platform/cts 仓库，要么在认证时切回 repo 模式编译。

4. 分清 Soong 的两个阶段

•解析阶段：扫描 Android.bp，构建依赖图，文件不存在会直接报错（PRODUCT_PACKAGES -= 没用）；

•编译阶段：实际编译模块，PRODUCT_PACKAGES -= 只在这个阶段生效。
这也是为什么 enabled: false 是最安全的 —— 它直接跳过了解析阶段。

五、总结

核心结论	具体说明
报错根因	去掉 repo 后，模块依赖的外部仓库不存在，Soong 解析失败
最优解	在 Android.bp 中给报错模块加 enabled: false
排查重点	CTS/GTS/VTS 测试模块、引用外部 defaults 的模块
最佳实践	禁用模块而非删除，保留可恢复性

去掉 repo 确实简化了开发流程，但也意味着我们要自己维护 SDK 的 “边界”。及时屏蔽这些用不到的外部依赖模块，才能让编译一路畅通。

如果你的 RK3566 Android15 项目也遇到了类似问题，不妨试试这个方法，欢迎在评论区交流更多踩坑经验～