### 问题分析 在构建 Android 系统模块时，出现 `cannot link against libandroid` 错误通常意味着当前模块试图链接到一个不允许的系统库。根据错误提示中的 `(native:platform)` 和 `(native:vendor)` 标记，可以判断该问题是由于平台与供应商命名空间之间的依赖限制所引起的。 Android 引入了 VNDK（Vendor Neutral Development Kit）机制，将系统库划分为两类：平台库（`native:platform`）和供应商库（`native:vendor`）。平台库是核心的系统 API，供系统服务使用；而供应商库则用于 HAL 实现，仅允许被 vendor 分区内的模块引用。若 vendor 模块尝试直接链接平台库（如 `libandroid`），构建系统会报错并阻止编译通过[^1]。 --- ### 解决方案 #### 替换为等效的 Vendor 可见接口 如果目标模块属于 vendor 分区（即标记为 `native:vendor`），应避免直接链接 `libandroid` 这类平台库。建议查找是否有提供等效功能的 vendor 接口或封装层，例如通过 Binder 接口调用系统服务，而不是直接依赖系统库函数[^3]。 #### 使用 `llndk_libraries` 或 `vndk_sp` 列表中的库 对于某些必需的功能调用，Android 提供了一组 LLNDK（Low-Level Native Development Kit）库，这些库可在 vendor 模块中安全使用。可以通过检查 AOSP 源码中的 `llndk_libraries.txt` 文件确认哪些库是允许链接的。若确实需要使用 `libandroid` 的部分功能，可尝试将其封装为系统服务并通过 Binder 调用，而非直接链接[^4]。 #### 修改模块定义以允许跨命名空间链接（不推荐） 虽然可以通过修改 `Android.bp` 或 `Android.mk` 中的标签来绕过限制，例如添加 `vendor_available: true` 或 `private: true` 来允许平台库被 vendor 模块使用，但这种做法违背了 Android 的架构规范，可能导致兼容性问题或无法通过 CTS 测试。因此，除非有特殊需求且充分理解后果，否则不建议采用此方法[^1]。 #### 示例：调整 Android.mk 配置 如果模块仍需保留为 vendor 组件，同时又必须访问某些系统能力，可考虑将其拆分为两个组件：一部分运行于 vendor 分区并实现 HAL，另一部分运行于 system 分区并与系统库交互。例如： ```makefile # vendor_module/Android.mk LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := vendor_module LOCAL_SRC_FILES := vendor_code.cpp LOCAL_SHARED_LIBRARIES := libhardware include $(BUILD_SHARED_LIBRARY) # system_module/Android.mk LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := system_module LOCAL_SRC_FILES := system_code.cpp LOCAL_SHARED_LIBRARIES := libandroid include $(BUILD_EXECUTABLE) ``` 这样可以确保系统库仅被 system 分区中的组件使用，符合 VNDK 规范[^3]。 --- ### 总结 解决 `cannot link against libandroid` 并伴随 `native:platform` 错误的关键在于理解 Android 的 VNDK 架构和命名空间隔离机制。正确的做法是避免 vendor 模块直接链接平台库，转而使用 LLNDK 提供的接口、Binder 通信或模块拆分策略来实现所需功能。这种方式不仅保证了系统的稳定性与安全性，也提高了模块间的解耦程度。 ---