Android构建系统中的PRODUCT_PACKAGES

1.Android构建系统中的PRODUCT_PACKAGES

在Android构建系统中，PRODUCT_PACKAGES扮演着至关重要的角色。它是一个变量，用于配置要包含在最终生成的设备系统镜像中的特定产品包。以下是对PRODUCT_PACKAGES的详细解释：

一、定义与位置

  • PRODUCT_PACKAGES通常在设备制造商的设备配置文件中进行定义，这些文件通常位于<设备制造商>/<设备型号>目录下。
  • 配置文件中的路径可以是相对路径或绝对路径，它们告诉编译系统哪些文件需要包含在设备系统镜像中。

二、作用与功能

  • PRODUCT_PACKAGES指定了要打包到系统镜像中的应用程序、框架和其他文件。这些包通常包含了设备特定的功能、驱动程序、预置应用程序等内容。
  • 通过在设备配置文件中设置PRODUCT_PACKAGES，制造商可以精确地控制哪些软件组件被包含在设备的系统镜像中，从而确保设备具有所需的功能和性能。

三、使用方式

  • 在Android编译系统中，通过调用m命令编译系统时，编译系统会读取设备配置文件（如device/<制造商>/<设备型号>/device.mk），从而了解哪些文件需要打包到系统镜像中。
  • 编译系统会相应地配置和构建系统镜像，将PRODUCT_PACKAGES中指定的所有包包含在内。

四、示例与说明

  • 假设制造商想要在其设备中预置一个名为“Test”的应用程序，他们可以在相应的设备配置文件中添加PRODUCT_PACKAGES += Test。
  • 然后，他们需要在packages/apps目录下创建一个名为“Test”的文件夹，并将该应用程序的APK文件和相关资源放入其中。
  • 在该文件夹下，还需要创建一个Android.mk文件，用于指定如何编译和打包该应用程序。
  • 在编译过程中，Android构建系统会读取PRODUCT_PACKAGES变量，并找到“Test”应用程序，然后将其打包到系统镜像中。

五、注意事项

  • PRODUCT_PACKAGES中指定的包应该是已经编译好的模块或应用程序，否则编译系统会报错。
  • 制造商可以根据其产品线和型号组织文件，并在设备配置文件中指定相应的路径。这有助于保持代码的组织性和可维护性。

综上所述，PRODUCT_PACKAGES在Android构建系统中具有重要的作用，它使得制造商能够精确地控制哪些软件组件被包含在设备的系统镜像中，从而确保设备具有所需的功能和性能。

 

2.Android.bp中的proprietary:和vendor

在Android的Soong构建系统中，Android.bp文件用于定义模块和它们的构建规则。关于proprietary和vendor这两个术语，在Android.bp文件中它们并不直接作为属性出现来指定模块的路径或命名空间。然而，这两个术语在Android的源代码管理和构建环境中有着特定的含义，并且与模块的放置位置有关。

  1. proprietary:
    • 这个术语通常指的是那些由设备制造商（OEM）提供且不希望开源的代码或模块。这些代码可能包含专有算法、驱动程序或与硬件紧密相关的实现，因此它们不被包含在AOSP（Android Open Source Project）中。
    • 在构建系统中，专有代码通常被放置在vendor分区或proprietary目录中（取决于项目的具体设置），并且不会被编译到系统镜像中，除非设备制造商明确选择这样做。
    • proprietary这个词本身在Android.bp文件中不直接用作属性，但它可能用于描述包含专有代码的目录或模块。
  2. vendor:
    • vendor分区是Android设备上的一个特殊分区，用于存放设备制造商提供的代码和库。这些代码可能包括设备特定的驱动程序、库文件、应用或服务。
    • 在Android.bp文件中，虽然vendor这个词不直接用作属性，但构建系统确实提供了机制来将模块放置在vendor分区中。这通常是通过在构建脚本中设置适当的install_path属性或使用特定的模块类型（如cc_library_shared_vendor）来实现的。
    • 需要注意的是，具体的模块类型和属性可能因Android版本和构建系统的更新而有所变化。

如果你想要将一个.so文件放置在/vendor/lib64目录中，你应该在Android.bp文件中指定正确的install_path属性，或者使用为vendor分区设计的模块类型（如果可用）。例如：

cc_library_shared_vendor {  
    name: "my_vendor_library",  
    srcs: ["my_vendor_library.c"],  
    // 其他属性...  
}

然而，请注意cc_library_shared_vendor可能不是所有Android版本或构建系统都支持的标准模块类型。如果你的构建系统不支持这种模块类型，你可能需要手动设置install_path属性：

cc_library_shared {  
    name: "my_vendor_library",  
    srcs: ["my_vendor_library.c"],  
    install_path: "/vendor/lib64",  
    // 其他属性...  
}

请确保你的构建环境和项目设置支持这种配置，并且你已经正确地设置了所有必要的路径和依赖项。

 

3.Android.bp中的soc_specific: true

在Android.bp文件中，soc_specific: true这一配置项通常用于指示某个模块或组件是特定于某个系统级芯片（SoC）的。Android.bp文件是Android构建系统（从Android 9.0 Pie开始引入的Blueprint构建系统）使用的配置文件，用于描述如何构建项目的不同部分。

具体来说，soc_specific: true意味着：

  • 该模块或组件是为特定的SoC设计和优化的。
  • 它可能依赖于SoC特定的硬件特性、驱动程序或库。
  • 在构建过程中，构建系统可能会根据目标设备的SoC来包含或排除这个模块。

这种机制允许Android设备制造商为不同的SoC平台提供定制化的实现，同时保持构建系统的灵活性和可扩展性。

例如，如果有一个针对特定SoC的图形处理模块，它可能会在其Android.bp文件中被标记为soc_specific: true，以确保它只在目标SoC与该模块兼容的设备上被构建和包含。

请注意，soc_specific: true的确切含义和效果可能会根据Android版本、构建系统的更新以及具体项目的配置而有所变化。因此，在实际使用中，建议参考最新的Android官方文档或构建系统的相关指南，以获取最准确的信息。

 

4.Android.bp中的compile_multilib

在Android.bp文件中，compile_multilib配置项用于指定模块是否应该针对多种库（multilib）进行编译。Multilib支持允许在同一设备上同时运行32位和64位二进制文件，这对于保持向后兼容性和支持不同架构的应用程序非常重要。

具体来说，compile_multilib可以有以下几种设置：

  1. 不设置或设置为默认值：这通常意味着模块将按照默认设置进行编译，这可能取决于构建系统的全局配置或目标设备的架构。

  2. 设置为both：这表示模块应该同时为32位和64位架构编译。这有助于确保模块能够与目标设备上的所有应用程序兼容，无论它们是32位还是64位。

  3. 设置为32或64：这分别表示模块应该只为32位或64位架构编译。这种设置可能用于优化性能、减少构建时间或满足特定项目的需求。

需要注意的是，compile_multilib的设置可能会影响模块的构建方式和依赖关系。例如，如果模块设置为both，则可能需要为两种架构分别编译和链接依赖库。

此外，compile_multilib的具体效果和可用性可能会受到Android版本、构建系统的更新以及具体项目的配置的影响。因此，在实际使用中，建议参考最新的Android官方文档或构建系统的相关指南，以获取最准确的信息和最佳实践。

总的来说，compile_multilib是一个重要的配置项，它允许开发者根据目标设备的架构和应用程序的兼容性需求来定制模块的编译方式。

 

5. 如何把生成的.so打包进image镜像中

找到device/xxx/xxx/device-common.mk,加入想要加的.so的Android.bp中的name，使用PRODUCT_PACKAGES

比如：

PRODUCT_PACKAGES += \
    libLayer_GLES_Lenovo

如果是一些资源文件，比如prebuilts或者xml这些，可以用PRODUCT_COPY_FILES

PRODUCT_COPY_FILES += \
$(LOCAL_PATH)/fstab.mahakala.avb.ab:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.mahakala

 

posted @ 2024-11-01 17:42  青山牧云人  阅读(296)  评论(0)  编辑  收藏  举报