告别混乱！Android14分区管理避坑指南：从Android.mk迁移到Android.bp时，vendor和odm模块配置的那些坑

Android14分区管理迁移实战：从Android.mk到Android.bp的避坑指南

当你的代码库中充斥着历史遗留的Android.mk文件，而构建系统已经悄然升级到Android14时，那种感觉就像拿着老式钥匙试图打开智能门锁。特别是当涉及到vendor、odm等特殊分区的模块配置时，直接翻译的语法往往会在深夜构建时给你"惊喜"。本文将带你深入理解分区管理的演变逻辑，并提供一份完整的迁移路线图。

1. 理解Android分区体系的演变

在深入技术细节之前，我们需要先建立对Android分区体系的整体认知。Android的分区设计经历了从简单到复杂的演变过程：

• 早期阶段：仅有system分区，所有内容都打包在一起
• 硬件抽象层分离：引入vendor分区隔离芯片厂商代码
• 定制化需求：增加odm分区满足设备制造商特殊需求
• 产品差异化：product分区实现同一硬件平台的多产品形态

这种分层架构带来了显著的灵活性，但也增加了构建系统的复杂性。在Android.mk时代，我们通过以下标志指定模块位置：

LOCAL_VENDOR_MODULE := true LOCAL_ODM_MODULE := true LOCAL_PRODUCT_MODULE := true

而在Soong构建系统（Android.bp）中，这些概念被重新组织和命名：

注意：odm分区的配置在Android.bp中使用的是device_specific: true而非字面上的odm属性，这是新手常犯的错误之一。

2. 分区属性迁移的详细对照

2.1 vendor模块的迁移

vendor分区包含设备专用的底层驱动和HAL实现。在迁移时需要注意：

Android.mk配置示例：

LOCAL_MODULE := my_vendor_driver LOCAL_VENDOR_MODULE := true LOCAL_SRC_FILES := driver.c

对应的Android.bp配置：

cc_binary { name: "my_vendor_driver", srcs: ["driver.c"], vendor: true, shared_libs: [ "liblog", "libcutils", ], }

关键差异点：

• LOCAL_VENDOR_MODULE直接转换为vendor: true
• 不再需要显式指定LOCAL_MODULE_PATH
• 依赖库需要在shared_libs中明确声明

2.2 odm模块的特殊处理

odm分区是最容易配置错误的地方。在Android.bp中，odm模块需要使用device_specific属性：

Android.mk配置：

LOCAL_MODULE := custom_odm_feature LOCAL_ODM_MODULE := true

Android.bp正确配置：

cc_library { name: "custom_odm_feature", device_specific: true, srcs: ["feature.cpp"], }

常见错误包括：

• 错误地使用odm: true（无效属性）
• 忘记设置会导致模块默认安装到system分区
• 路径变为vendor/odm而非原来的odm

2.3 product分区的配置技巧

product分区用于存放与产品线相关的定制内容：

迁移前后对比：

Android.mk:

LOCAL_MODULE := product_app LOCAL_PRODUCT_MODULE := true

Android.bp:

android_app { name: "product_app", product_specific: true, srcs: ["app/**/*.java"], }

需要特别注意：

• 属性名为product_specific而非product
• 应用类模块需要使用android_app而非普通的cc_binary
• 资源文件路径会发生变化

3. 多分区兼容性处理实战

当你的模块需要支持多种硬件架构或同时存在于多个分区时，配置会变得更加复杂。以下是几个典型场景的处理方法：

3.1 多架构二进制文件处理

对于需要同时支持32位和64位的vendor模块：

cc_binary { name: "multiarch_driver", srcs: ["driver.c"], vendor: true, compile_multilib: "both", target: { android_arm: { srcs: ["arm_specific.c"], }, android_arm64: { srcs: ["arm64_optimized.c"], }, }, }

提示：compile_multilib可以取值为"32","64","both"或"first"，控制架构生成策略

3.2 条件化分区分配

有时我们需要根据产品特性决定模块安装位置：

cc_binary { name: "conditional_module", srcs: ["module.c"], product_specific: getenv("PRODUCT_FEATURE") == "premium", vendor: getenv("PRODUCT_FEATURE") != "premium", }

3.3 跨分区依赖处理

当vendor模块依赖product分区中的库时：

cc_binary { name: "cross_partition_demo", vendor: true, shared_libs: [ "product_lib", ], target: { vendor: { shared_libs: [ "libvendor", ], }, }, }

4. 高级技巧与疑难排查

4.1 属性冲突解决

当多个分区属性被同时设置时，构建系统会按照特定优先级处理：

1. vendor: true最高优先级
2. product_specific: true次之
3. device_specific: true再次
4. 默认system分区

常见冲突场景：

• 同时设置vendor和product_specific
• device_specific与product_specific混用
• 忘记设置任何属性导致模块进入system分区

4.2 路径映射验证

验证模块是否安装到正确位置的方法：

# 查看生成的安装路径 out/soong/.intermediates/path/to/module/installed_files.txt # 检查最终镜像内容 ls -R out/target/product/[device]/vendor/

4.3 常见错误速查表

4.4 性能优化建议

• 对于vendor分区的大模块，考虑使用cc_library_static减少体积
• 启用strip: true移除调试符号
• 使用optimize: true开启编译器优化
• 对启动关键路径模块设置overrides: ["preferred"]

迁移过程中，我发现在大型项目中逐步迁移比全量切换更稳妥。可以先用Android.bp构建新模块，同时保留现有的Android.mk文件，待验证通过后再分批迁移。遇到问题时，检查out/soong/build.ninja文件往往能找到线索——它展示了Soong如何解释你的Blueprint文件。