Android构建系统演进：从Make到Soong的技术解析

1. Android构建系统演进史

1.1 从Make到Soong的技术迭代

Android构建系统的发展历程堪称一部移动操作系统底层工具链的进化史。2008年Android 1.0发布时，整个系统完全基于GNU Make构建，这种选择在当时看来顺理成章——Make作为经典的构建工具，在Linux生态中已有多年成熟应用。但随着Android系统规模呈指数级增长（从最初的几百个模块发展到现在的数万个），Make的局限性逐渐暴露：

• 递归解析问题：Make采用深度优先的递归解析策略，当遇到include指令时必须完全解析完被包含的Makefile才能继续。在AOSP这样的大型项目中，这种串行处理方式导致构建前期准备时间过长。我曾实测过，在Android 6.0时代，仅解析所有Makefile就需要近2分钟。

• 依赖关系模糊：Makefile中的依赖关系往往隐含在条件判断和变量替换中。例如LOCAL_SHARED_LIBRARIES := liblog这样的声明，实际依赖路径需要通过多个中间变量才能确定。这种隐式依赖使得增量构建经常失效，开发者不得不频繁执行make clean。

2016年Android 7.0引入Soong构建系统，其核心创新在于：

1. 并行化前端解析：Blueprint文件（Android.bp）采用声明式语法，所有模块定义可以并行解析
2. 精确依赖图：通过显式的shared_libs等属性，构建系统可以生成精确的DAG依赖图
3. 类型安全检查：每个属性都有明确定义的类型，避免Make中常见的变量拼写错误

1.2 现代构建系统架构解析

当前Android构建系统采用分层架构设计：

code复制+---------------------+
|  Module Definitions |  # Android.bp / Android.mk
+----------+----------+
           |
+----------v----------+
|   Soong / Kati      |  # 构建描述生成器
+----------+----------+
           |
+----------v----------+
|      Ninja          |  # 实际执行构建命令
+----------+----------+
           |
+----------v----------+
|   Compiler Toolchain|  # gcc/clang/javac等
+---------------------+

Soong作为构建系统的"大脑"，主要完成以下工作：

• 解析所有Android.bp文件，构建模块依赖图
• 处理条件编译（如不同CPU架构）
• 生成Ninja构建规则文件
• 提供模块信息查询接口（用于IDE集成）

Ninja则专注于高效执行构建命令，其特点包括：

• 最小化重新构建：通过精确的输入输出文件哈希比对
• 并行任务调度：默认使用CPU核心数作为并行任务数
• 增量构建优化：仅重建依赖链上变更的模块

实际开发中，可以通过m showcommands命令观察Ninja实际执行的完整命令行，这对调试编译参数特别有用。

2. Android.mk深度解析

2.1 Makefile核心机制剖析

每个Android.mk都必须以LOCAL_PATH := $(call my-dir)开头，这个设计背后有重要考量：

1. my-dir是AOSP预定义的Make函数，返回当前Makefile所在目录
2. 必须最先执行是因为后续的include $(CLEAR_VARS)会重置LOCAL_PATH
3. 该路径用于解析相对路径的源文件和资源文件

典型的模块定义包含以下关键部分：

makefile复制include $(CLEAR_VARS)  # 清除除LOCAL_PATH外的所有LOCAL_变量
LOCAL_MODULE := libdemo
LOCAL_SRC_FILES := $(call all-cpp-files-under, src)
LOCAL_SHARED_LIBRARIES := liblog libutils
include $(BUILD_SHARED_LIBRARY)

变量作用域陷阱：Android.mk中所有LOCAL_前缀的变量都是全局可见的。这意味着如果忘记调用CLEAR_VARS，前一个模块的定义会污染后续模块。我曾在调试时遇到过一个诡异问题：某个模块莫名其妙地链接了不该有的库，最终发现就是因为遗漏了CLEAR_VARS。

2.2 高级构建技巧

条件编译实现

Android.mk支持多种条件判断方式：

makefile复制# 根据目标设备架构过滤源文件
ifeq ($(TARGET_ARCH), arm64)
    LOCAL_SRC_FILES += src/arm64/neon_impl.cpp
else
    LOCAL_SRC_FILES += src/generic_impl.cpp
endif

# 根据Android版本启用特性
ifneq ($(filter 8.1.0 9.0.0, $(PLATFORM_VERSION)),)
    LOCAL_CFLAGS += -DSUPPORT_NEW_FEATURE
endif

预编译模块处理

对于第三方闭源库，通常需要以预编译形式集成：

makefile复制include $(CLEAR_VARS)
LOCAL_MODULE := libprebuilt
LOCAL_SRC_FILES := prebuilt/$(TARGET_ARCH)/libprebuilt.so
LOCAL_MODULE_CLASS := SHARED_LIBRARIES
LOCAL_MODULE_SUFFIX := .so
LOCAL_MODULE_TAGS := optional
include $(PREBUILT_SHARED_LIBRARY)

路径陷阱：预编译库必须按prebuilt/(TARGET_ARCH)/目录结构存放，否则在模拟器构建时会出现LOCAL_SRC_FILES points to a missing file错误。建议使用$(TARGET_ARCH)和$(TARGET_2ND_ARCH)变量处理多架构场景。

3. Android.bp现代构建方案

3.1 Blueprint语法精要

Android.bp采用类似JSON的声明式语法，但有以下重要区别：

1. 允许单行注释（//）
2. 最后一个属性后可以保留逗号
3. 支持多行字符串（不需要\n转义）

基础结构示例：

python复制cc_library_shared {
    name: "libmodern",
    srcs: ["src/*.cpp"],
    shared_libs: ["liblog"],
    cflags: [
        "-Wall",
        "-Werror=return-type",  // 特别注意返回类型检查
    ],
    export_include_dirs: ["include"],
}

类型系统：Soong会对所有属性进行强类型检查。例如：

• name必须是字符串且全局唯一
• srcs必须是字符串列表或glob模式
• cflags只能是字符串列表

如果类型不匹配，构建时会直接报错（而非像Make那样静默继续）。这种严格性显著提高了构建可靠性。

3.2 模块依赖的高级用法

可见性控制

Android.bp引入了Java风格的可见性控制：

python复制cc_library {
    name: "libinternal",
    visibility: [":__subpackages__"],  // 仅对当前目录及子目录可见
}

cc_library {
    name: "libpublic",
    visibility: ["//frameworks/base"],  // 对指定路径可见
}

这种机制有效防止了模块间的非法依赖。当尝试在未经授权的模块中引用时，构建系统会报错：

code复制module "libunsecure" depends on restricted module "libinternal"

导出依赖

对于SDK开发场景，需要精确控制头文件暴露：

python复制cc_library_headers {
    name: "libapi_headers",
    export_include_dirs: ["include/public"],
    // 不包含include/internal目录
}

cc_library {
    name: "libsdk",
    shared_libs: ["libimpl"],
    export_shared_lib_headers: ["libimpl"],  // 传递依赖
}

4. 构建系统实战技巧

4.1 性能优化方案

增量构建加速

在开发过程中，可以组合使用以下命令显著提升构建速度：

bash复制# 首次全量构建
m -j16

# 后续增量构建（仅更新变化的模块）
m -j16 quick_build

# 针对单个模块的极速构建（跳过依赖检查）
mma -j16 BUILD_MODULE=libdemo

并行度设置：-j参数理论上可以设置为CPU核心数的2倍，但在内存有限的机器上（小于32GB），建议设置为核心数×1.5以避免OOM。

缓存利用

Android构建系统支持两种缓存机制：

1. ccache：编译器缓存，通过export USE_CCACHE=1启用
2. sccache：分布式编译缓存，适合团队环境

配置示例：

bash复制prebuilts/misc/linux-x86/ccache/ccache -M 50G  # 设置缓存大小
export CCACHE_COMPRESS=1  # 启用压缩节省空间

4.2 调试与排错指南

常见错误处理

依赖分析工具

Soong提供了强大的模块查询接口：

bash复制# 显示模块的所有依赖
m query MODULE deps

# 可视化依赖图（需要graphviz）
m query MODULE graph | dot -Tpng > graph.png

# 检查两个模块的依赖关系
m query MODULE1 path MODULE2

5. 迁移策略与最佳实践

5.1 渐进式迁移方案

对于大型项目，建议采用以下迁移路线：

1. 准备阶段

   • 在项目根目录创建Android.bp
   • 保留原有Android.mk但移除具体实现

   makefile复制# 过渡期的Android.mk
   ifndef MY_MODULE_MIGRATED
   include $(LOCAL_PATH)/Android.mk.legacy
   endif
   

2. 模块迁移

   • 使用androidmk工具生成初始bp文件
   • 手动优化依赖关系

   bash复制androidmk Android.mk > Android.bp.partial
   

3. 验证阶段

   • 并行构建验证：

   bash复制m -j16 && m -j16 BUILD_BP_ONLY=true
   

   • 运行时验证：

   bash复制adb shell ldd /system/lib64/libmigrated.so
   

5.2 条件编译处理

将Make中的条件逻辑转换为bp的arch/target块：

python复制cc_library {
    name: "libarch",
    srcs: ["common.cpp"],
    arch: {
        arm: {
            srcs: ["arm/neon.cpp"],
            cflags: ["-mfpu=neon"],
        },
        arm64: {
            srcs: ["arm64/simd.cpp"],
        },
        x86: {
            enabled: false,  // 完全禁用x86构建
        },
    },
    target: {
        android: {
            shared_libs: ["liblog"],
        },
        host: {
            static_libs: ["libhost"],
        },
    },
}

对于复杂的条件逻辑，可以使用soong_config_module_type定义自定义变量：

python复制soong_config_module_type {
    name: "custom_library",
    module_type: "cc_library",
    config_namespace: "my_project",
    variables: ["enable_feature"],
    properties: ["cflags", "srcs"],
}

custom_library {
    name: "libconfigurable",
    soong_config_variables: {
        enable_feature: {
            cflags: ["-DFEATURE_ENABLED"],
            srcs: ["feature.cpp"],
            conditions_default: {
                cflags: ["-DFEATURE_DISABLED"],
            },
        },
    },
}

6. 构建系统深度定制

6.1 自定义构建规则

对于非标准构建需求，可以使用genrule：

python复制genrule {
    name: "generate_proto",
    tools: ["protoc"],
    srcs: ["src/*.proto"],
    out: ["generated/%proto:name%.pb.cc", "generated/%proto:name%.pb.h"],
    cmd: "mkdir -p $(dirname $(location generated/)) && " +
         "protoc --cpp_out=$(location generated/) $(in)",
}

路径处理要点：

• $(location)宏用于获取文件绝对路径
• 输出文件必须明确声明，否则增量构建会失效
• 建议为工具声明明确的版本依赖：

  python复制host_binary {
      name: "protoc",
      srcs: ["tools/protoc-3.19.4"],
  }
  

6.2 产品配置策略

设备厂商通常需要定制产品特性：

python复制// product_config.mk
PRODUCT_PACKAGES += \
    MySystemApp \
    libvendor

// 在Android.bp中声明产品特定配置
cc_library {
    name: "libvendor",
    product_specific: true,
    vendor: true,
    srcs: ["vendor/*.cpp"],
}

产品继承体系：

code复制+---------------------+
|   base_product.mk   |  # 最基础的产品配置
+----------+----------+
           |
+----------v----------+
|  device_common.mk   |  # 设备系列通用配置
+----------+----------+
           |
+----------v----------+
|  device_variant.mk  |  # 具体型号的特殊配置
+---------------------+

通过inherit-product实现配置复用：

makefile复制$(call inherit-product, device/common/base.mk)
$(call inherit-product-if-exists, vendor/partner/config.mk)

在多年的AOSP开发实践中，我发现构建系统的正确理解直接关系到开发效率。特别是在处理系统级模块时，一个优化的Android.bp配置可以将构建时间从分钟级降到秒级。建议开发者深入理解Ninja的构建日志，这往往能揭示出隐藏的依赖问题。记住，良好的构建配置应该像优秀的代码一样——模块化、可维护、高效。