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的模块
最佳实践	禁用模块而非删除，保留可恢复性