第4章 C/C++编译错误：头文件缺失、NDK版本不兼容、ABI不匹配

C/C++编译错误是AOSP编译中最频繁的问题类型之一。头文件缺失、NDK版本冲突、ABI架构不匹配往往导致编译中断或运行时崩溃。本章从现象出发，通过结构化排查手段快速定位根因，并给出可落地的修复与预防策略。

4.1 现象识别

三种错误的典型编译/链接错误信息如下表，可据此快速归类。

4.2 数据采集

定位前需收集以下关键信息（记入排查笔记本）：

1. 完整编译日志：使用 make showcommands 或 m -j32 2>&1 | tee build.log 保留原始输出。
2. 模块依赖声明：检查目标模块的 Android.bp 或 Android.mk 文件，重点查看 header_libs、shared_libs、static_libs。
3. NDK/SDK版本：从 build/soong/cc/config/ 或 prebuilts/ndk/current/ 下确认使用的NDK版本。
4. 目标ABI：lunch 选择的 TARGET_ARCH 与 TARGET_2ND_ARCH，以及预编译库的.so实际ABI（通过 file libfoo.so查看）。
5. 编译环境变量：printenv | grep -E "NDK|ABI|ARCH"。

# 头文件缺失
In file included from frameworks/av/media/utils/MediaUtils.cpp:28:
frameworks/av/include/media/IMediaPlayer.h:30:10: fatal error: 'binder/IBinder.h' file not found

# NDK版本不兼容
external/libcxx/src/variant.cpp:125: error: undefined reference to '__cxa_demangle'
clang++: error: linker command failed with exit code 1

# ABI不匹配
prebuilts/arm64/libfoo.so: error: skipping incompatible when searching for -lfoo
target arm64-v8a, but prebuilt is for armeabi-v7a

4.3 原因定位（故障树+排查表）

使用下列决策表逐步缩小根因范围：

头文件缺失深度定位

1. 确认缺失头文件属于哪个模块（查找 find . -name "xxx.h"）。
2. 检查目标模块的 Android.bp 是否包含该模块的 header_libs 或直接通过 include_dirs 引用。
3. 验证依赖链：被依赖模块是否已 cc_library_headers 导出头文件。

NDK版本不兼容深度定位

1. 获取当前编译使用的NDK版本：ls prebuilts/ndk/current 或查看 build/soong/cc/config/ndk_version.go。
2. 检查模块的 Android.bp 中 sdk_version 或 ndk_version 是否显式指定，若未指定则使用默认值。
3. 对比链接错误中的符号与NDK运行时库的导出符号表（nm -D libc++_shared.so | grep __cxa_demangle）。
4. 确认 APP_STL 类型（c++_shared vs c++_static）与预置库一致。

ABI不匹配深度定位

1. 执行 echo $TARGET_ARCH 和 echo $TARGET_2ND_ARCH。
2. 对出错预编译库执行 file prebuilts/xxx/libfoo.so，确认ABI（如 ARM aarch64 vs ARM）。
3. 检查模块声明：Android.bp 中的 arch: { arm64: { srcs: [...], }, } 是否只提供了单一ABI版本。
4. 若链接 arm64 目标，却引用 arm 平台的预编译 .so，则报 skipping incompatible。

4.4 修复动作

针对三类根因给出明确修复步骤：

cc_binary {
    name: "my_binary",
    header_libs: [
        "libcutils_headers",
        "liblog_headers",
    ],
}

cc_library {
    name: "libfoo",
    sdk_version: "30",
    ndk_version: "25",
    stl: "c++_shared",
}

arch: {
    arm64: { srcs: ["libfoo_arm64.a"] },
    arm:   { srcs: ["libfoo_arm.a"] },
}

4.5 复测

执行以下步骤验证修复：

1. 清理目标模块：mm -B 或 m clean-。
2. 重新编译：m -j32 并观察是否出现同样错误。
3. 全面编译：若修复涉及公共头文件或NDK配置，建议执行 m -j32 全量编译确认无新增错误。
4. 运行单元测试/集成测试：对于ABI修复，需在相应架构的真机或模拟器上测试 .so 加载与运行。

4.6 预防措施

在团队开发中嵌入以下检查点，避免同类问题反复出现：

• 头文件依赖可视化：使用 build/soong/scripts/dotdep.py 生成模块依赖图，确保所有 #include 的模块都显式声明在 header_libs 中。
• NDK版本锁定：在 build/soong/cc/config/ndk_version.go 中固定NDK主版本，并在 BoardConfig.mk 或 ProductConfig.mk 中集中定义 NDK_APP_STL := c++_shared。
• ABI前置校验：在提交预编译 .so 前，编写CI脚本检查其ABI是否与 lunch 目标一致。示例检查脚本：

# 检查预编译库ABI是否匹配指定目标
TARGET_ARCH=$(get_build_var TARGET_ARCH)
for lib in prebuilts/*.so; do
    ABI=$(file "$lib" | grep -oE 'ARM aarch64|ARM|Intel 80386|x86-64' | head -1)
    case "$TARGET_ARCH" in
        arm64) expected="ARM aarch64" ;;
        arm)   expected="ARM" ;;
        x86)   expected="Intel 80386" ;;
        x86_64)expected="x86-64" ;;
    esac
    if [ "$ABI" != "$expected" ]; then
        echo "ABI mismatch: $lib -> $ABI, expected $expected"
        exit 1
    fi
done
echo "All prebuilt libraries match target ABI."