(2) 在 Build 系统中添加新的内容 - 添加新的产品


http://www.ibm.com/developerworks/cn/opensource/os-cn-android-build/


在 Build 系统中添加新的内容

添加新的产品

当我们要开发一款新的 Android 产品的时候，我们首先就需要在 Build 系统中添加对于该产品的定义。

在 Android Build 系统中对产品定义的文件通常位于 device 目录下（另外还有一个可以定义产品的目录是 vender 目录，这是个历史遗留目录，Google 已经建议不要在该目录中进行定义，而应当选择 device 目录）。device 目录下根据公司名以及产品名分为二级目录，这一点我们在概述中已经提到过。

通常，对于一个产品的定义通常至少会包括四个文件：AndroidProducts.mk，产品版本定义文件，BoardConfig.mk 以及 verndorsetup.sh。下面我们来详细说明这几个文件。

  • AndroidProducts.mk：该文文件中的内容很简单，其中只需要定义一个变量，名称为“PRODUCT_MAKEFILES”，该变量的值为产品版本定义文件名的列表，例如：
 PRODUCT_MAKEFILES := \ 
 $(LOCAL_DIR)/full_stingray.mk \ 
 $(LOCAL_DIR)/stingray_emu.mk \ 
 $(LOCAL_DIR)/generic_stingray.mk
  • 产品版本定义文件：顾名思义，该文件中包含了对于特定产品版本的定义。该文件可能不只一个，因为同一个产品可能会有多种版本（例如，面向中国地区一个版本，面向美国地区一个版本）。该文件中可以定义的变量以及含义说明如表 6 所示：
表 6. 产品版本定义文件中的变量及其说明
常量 说明
PRODUCT_NAME 最终用户将看到的完整产品名，会出现在“关于手机”信息中。
PRODUCT_MODEL 产品的型号，这也是最终用户将看到的。
PRODUCT_LOCALES 该产品支持的地区，以空格分格，例如：en_GB de_DE es_ES fr_CA。
PRODUCT_PACKAGES 该产品版本中包含的 APK 应用程序，以空格分格，例如：Calendar Contacts。
PRODUCT_DEVICE 该产品的工业设计的名称。
PRODUCT_MANUFACTURER 制造商的名称。
PRODUCT_BRAND 该产品专门定义的商标（如果有的话）。
PRODUCT_PROPERTY_OVERRIDES 对于商品属性的定义。
PRODUCT_COPY_FILES 编译该产品时需要拷贝的文件，以“源路径 : 目标路径”的形式。
PRODUCT_OTA_PUBLIC_KEYS 对于该产品的 OTA 公开 key 的列表。
PRODUCT_POLICY 产品使用的策略。
PRODUCT_PACKAGE_OVERLAYS 指出是否要使用默认的资源或添加产品特定定义来覆盖。
PRODUCT_CONTRIBUTORS_FILE HTML 文件，其中包含项目的贡献者。
PRODUCT_TAGS 该产品的标签，以空格分格。

通常情况下，我们并不需要定义所有这些变量。Build 系统的已经预先定义好了一些组合，它们都位于 /build/target/product 下，每个文件定义了一个组合，我们只要继承这些预置的定义，然后再覆盖自己想要的变量定义即可。例如：

 # 继承 full_base.mk 文件中的定义
 $(call inherit-product, $(SRC_TARGET_DIR)/product/full_base.mk) 
 # 覆盖其中已经定义的一些变量
 PRODUCT_NAME := full_lt26 
 PRODUCT_DEVICE := lt26 
 PRODUCT_BRAND := Android 
 PRODUCT_MODEL := Full Android on LT26
  • BoardConfig.mk：该文件用来配置硬件主板，它其中定义的都是设备底层的硬件特性。例如：该设备的主板相关信息，Wifi 相关信息，还有 bootloader，内核，radioimage 等信息。对于该文件的示例，请参看 Android 源码树已经有的文件。
  • vendorsetup.sh：该文件中作用是通过 add_lunch_combo 函数在 lunch 函数中添加一个菜单选项。该函数的参数是产品名称加上编译类型，中间以“-”连接，例如：add_lunch_combo full_lt26-userdebug。/build/envsetup.sh 会扫描所有 device 和 vender 二 级目 录下的名称 为"vendorsetup.sh"文件，并根据其中的内容来确定 lunch 函数的 菜单选项。

在配置了以上的文件之后，便可以编译出我们新添加的设备的系统镜像了。

首先，调用“source build/envsetup.sh”该命令的输出中会看到 Build 系统已经引入了刚刚添加的 vendorsetup.sh 文件。

然后再调用“lunch”函数，该函数输出的列表中将包含新添加的 vendorsetup.sh 中添加的条目。然后通过编号或名称选择即可。

最后，调用“make -j8”来执行编译即可。

添加新的模块

关于“模块”的说明在上文中已经提到过，这里不再赘述。

在源码树中，一个模块的所有文件通常都位于同一个文件夹中。为了将当前模块添加到整个 Build 系统中，每个模块都需要一个专门的 Make 文件，该文件的名称为“Android.mk”。Build 系统会扫描名称为“Android.mk”的文件，并根据该文件中内容编译出相应的产物。

需要注意的是：在 Android Build 系统中，编译是以模块（而不是文件）作为单位的，每个模块都有一个唯一的名称，一个模块的依赖对象只能是另外一个模块，而不能是其他类型的对象。对于已经编译好的二进制库，如果要用来被当作是依赖对象，那么应当将这些已经编译好的库作为单独的模块。对于这些已经编译好的库使用 BUILD_PREBUILT 或 BUILD_MULTI_PREBUILT。例如：当编译某个 Java 库需要依赖一些 Jar 包时，并不能直接指定 Jar 包的路径作为依赖，而必须首先将这些 Jar 包定义为一个模块，然后在编译 Java 库的时候通过模块的名称来依赖这些 Jar 包。

下面，我们就来讲解 Android.mk 文件的编写：

Android.mk 文件通常以以下两行代码作为开头：

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

这两行代码的作用是：

  1. 设置当前模块的编译路径为当前文件夹路径。
  2. 清理（可能由其他模块设置过的）编译环境中用到的变量。

为了方便模块的编译，Build 系统设置了很多的编译环境变量。要编译一个模块，只要在编译之前根据需要设置这些变量然后执行编译即可。它们包括：

  • LOCAL_SRC_FILES：当前模块包含的所有源代码文件。
  • LOCAL_MODULE：当前模块的名称，这个名称应当是唯一的，模块间的依赖关系就是通过这个名称来引用的。
  • LOCAL_C_INCLUDES：C 或 C++ 语言需要的头文件的路径。
  • LOCAL_STATIC_LIBRARIES：当前模块在静态链接时需要的库的名称。
  • LOCAL_SHARED_LIBRARIES：当前模块在运行时依赖的动态库的名称。
  • LOCAL_CFLAGS：提供给 C/C++ 编译器的额外编译参数。
  • LOCAL_JAVA_LIBRARIES：当前模块依赖的 Java 共享库。
  • LOCAL_STATIC_JAVA_LIBRARIES：当前模块依赖的 Java 静态库。
  • LOCAL_PACKAGE_NAME：当前 APK 应用的名称。
  • LOCAL_CERTIFICATE：签署当前应用的证书名称。
  • LOCAL_MODULE_TAGS：当前模块所包含的标签，一个模块可以包含多个标签。标签的值可能是 debug, eng, user，development 或者 optional。其中，optional 是默认标签。标签是提供给编译类型使用的。不同的编译类型会安装包含不同标签的模块，关于编译类型的说明如表 7 所示：
表 7. 编译类型的说明
名称 说明
eng 默认类型，该编译类型适用于开发阶段。
当选择这种类型时，编译结果将：
  • 安装包含 eng, debug, user，development 标签的模块
  • 安装所有没有标签的非 APK 模块
  • 安装所有产品定义文件中指定的 APK 模块
user 该编译类型适合用于最终发布阶段。
当选择这种类型时，编译结果将：
  • 安装所有带有 user 标签的模块
  • 安装所有没有标签的非 APK 模块
  • 安装所有产品定义文件中指定的 APK 模块，APK 模块的标签将被忽略
userdebug 该编译类型适合用于 debug 阶段。
该类型和 user 一样，除了：
  • 会安装包含 debug 标签的模块
  • 编译出的系统具有 root 访问权限

表 3 中的文件已经定义好了各种类型模块的编译方式。所以要执行编译，只需要引入表 3 中对应的 Make 文件即可（通过常量的方式）。例如，要编译一个 APK 文件，只需要在 Android.mk 文件中，加入“include $(BUILD_PACKAGE)

除此以外，Build 系统中还定义了一些便捷的函数以便在 Android.mk 中使用，包括：

  • $(call my-dir)：获取当前文件夹路径。
  • $(call all-java-files-under, <src>)：获取指定目录下的所有 Java 文件。
  • $(call all-c-files-under, <src>)：获取指定目录下的所有 C 语言文件。
  • $(call all-Iaidl-files-under, <src>)：获取指定目录下的所有 AIDL 文件。
  • $(call all-makefiles-under, <folder>)：获取指定目录下的所有 Make 文件。
  • $(call intermediates-dir-for, <class>, <app_name>, <host or target>, <common?> )：获取 Build 输出的目标文件夹路径。

清单 2 和清单 3 分别是编译 APK 文件和编译 Java 静态库的 Make 文件示例：

清单 2. 编译一个 APK 文件
  LOCAL_PATH := $(call my-dir) 
  include $(CLEAR_VARS) 
  # 获取所有子目录中的 Java 文件
  LOCAL_SRC_FILES := $(call all-subdir-java-files) 			
  # 当前模块依赖的静态 Java 库，如果有多个以空格分隔
  LOCAL_STATIC_JAVA_LIBRARIES := static-library 
  # 当前模块的名称
  LOCAL_PACKAGE_NAME := LocalPackage 
  # 编译 APK 文件
  include $(BUILD_PACKAGE)
清单 3. 编译一个 Java 的静态库
  LOCAL_PATH := $(call my-dir) 
  include $(CLEAR_VARS) 
   
  # 获取所有子目录中的 Java 文件
  LOCAL_SRC_FILES := $(call all-subdir-java-files) 
   
  # 当前模块依赖的动态 Java 库名称
  LOCAL_JAVA_LIBRARIES := android.test.runner 
   
  # 当前模块的名称
  LOCAL_MODULE := sample 
   
  # 将当前模块编译成一个静态的 Java 库
  include $(BUILD_STATIC_JAVA_LIBRARY)

结束语

整个 Build 系统包含了非常多的内容，由于篇幅所限，本文只能介绍其中最主要内容。

由于 Build 系统本身也是在随着 Android 平台不断的开发过程中，所以不同的版本其中的内容和定义可能会发生变化。网络上关于该部分的资料很零碎，并且很多资料中的一些内容已经过时不再适用，再加上缺少官方文档，所以该部分的学习存在一定的难度。

这就要求我们要有很强的代码阅读能力，毕竟代码是不会说谎的。要知道，对于我们这些开发人员来说，源代码就是我们最忠实的朋友。 Use the Source,Luke!


posted @ 2016-10-21 23:42  张同光  阅读(177)  评论(0)  编辑  收藏  举报