嗨，我之前在做Car/SystemUI的RRO Overlay时碰到过完全一样的问题，给你分享下实际可行的解决思路，千万别尝试忽略编译错误——AOSP的编译系统是严格的，资源引用找不到的话，aapt2打包会直接失败，根本生成不了可用的Overlay APK，就算你强行绕过去，运行时也大概率会因为资源ID不匹配导致UI崩溃或者显示异常。

下面是正确的解决方法，完全不用复制目标模块的资源：

1. 在RRO的构建脚本中添加资源依赖 #

核心就是让编译系统能找到Car/SystemUI以及依赖的资源模块，具体分两种构建脚本的情况：

如果你用Android.bp（AOSP 10+推荐写法） #

在你的Overlay模块的Android.bp中，通过resource_libs字段添加对目标资源模块的依赖，同时指定Overlay的目标包名：

android_resource {
    name: "your-car-systemui-overlay",
    srcs: ["res/**/*"],
    resource_libs: [
        "framework-res",          // 基础框架资源
        "com.android.systemui",   // 原生SystemUI资源
        "com.android.car.systemui",// Car版SystemUI的资源模块
    ],
    overlay: {
        target: "com.android.car.systemui", // 你的Overlay要替换的目标包名
    },
    certificate: "platform",
}

如果你用Android.mk #

对应的，在Android.mk中通过LOCAL_RESOURCE_DEPENDENCIES添加依赖，同时指定LOCAL_OVERLAY_PACKAGE：

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)

LOCAL_MODULE := your-car-systemui-overlay
LOCAL_OVERLAY_PACKAGE := com.android.car.systemui
LOCAL_RESOURCE_DEPENDENCIES := \
    frameworks/base/core/res \
    packages/SystemUI/res \
    packages/services/Car/SystemUI/res

LOCAL_CERTIFICATE := platform
include $(BUILD_PACKAGE)

2. 关键注意事项 #

• 资源可访问性：只要你的RRO和目标模块在同一AOSP源码树中编译，添加依赖后就能访问目标模块的所有资源——不管是public.xml声明的公开资源，还是模块内部的私有资源，编译系统都会自动关联它们的资源ID。
• 避免资源复制：复制资源到Overlay目录是下下策，后期Car/SystemUI的资源（比如颜色值、图标）更新后，你的Overlay会和目标模块脱节，出现UI不一致的问题，维护成本极高。
• 编译验证：添加依赖后重新编译你的Overlay模块，资源引用错误应该会全部消失，编译通过后刷入设备测试，就能正常加载目标模块的资源了。

为什么不能忽略编译错误？ #

AOSP的资源编译工具aapt2会在打包时严格校验所有资源引用的有效性，找不到的引用会直接终止打包流程。退一万步说，就算你通过某种hack跳过了编译检查，运行时Overlay的资源表中没有正确关联目标模块的资源ID，系统会找不到对应的资源，最终显示默认的占位符（比如灰色、缺失的字符串、空白图标），甚至直接抛出资源找不到的异常导致SystemUI崩溃。

所以还是乖乖添加资源依赖最靠谱，这也是AOSP官方推荐的RRO开发方式～