Android R(11)将HIDL服务添加到系统镜像(七)

1.添加自定义makefile文件到产品

  前面几章介绍的方法一般用于开发阶段，在功能开发完成后，则需要集成到系统镜像中去。我们使用的产品则是aosp_x86_64

TARGET_PRODUCT=aosp_x86_64

  所以需要将自定义的makefile文件添加到产品的配置makefile中去，

--- a/target/product/aosp_x86_64.mk
+++ b/target/product/aosp_x86_64.mk
@@ -63,6 +63,7 @@ $(call inherit-product, $(SRC_TARGET_DIR)/board/generic_x86_64/device.mk)
 ifeq (aosp_x86_64,$(TARGET_PRODUCT))
 $(call inherit-product, $(SRC_TARGET_DIR)/product/gsi_release.mk)
 endif
+$(call inherit-product, test/flagstaffTest/device.mk)

  aosp_x86_64的配置位置比较特别并非位于device下，一般产品的配置文件多会被放置到device下

flagstaff@flagstaff-pc:~/aosp_r.lns$ tree  -L 1 device/google/cuttlefish
device/google/cuttlefish
├── Android.bp
├── Android.mk
├── AndroidProducts.mk
├── CleanSpec.mk
├── common
├── default-permissions.xml
...

  此处的Android.mk文件其实和每个模块的Android.bp/mk也是一样的，用来描述对应设备的构成以及如何构成，一般产品的顶层makefile了，其内部再会包含各个模块的makefile

flagstaff@flagstaff-pc:~/aosp_r.lns$ cat device/google/cuttlefish/Android.mk 
ifneq ($(filter vsoc_arm64 vsoc_x86 vsoc_x86_64, $(TARGET_BOARD_PLATFORM)),)
LOCAL_PATH:= $(call my-dir)

include $(CLEAR_VARS)
include $(LOCAL_PATH)/fetcher.mk

include $(CLEAR_VARS)
include $(LOCAL_PATH)/host_package.mk

include $(call first-makefiles-under,$(LOCAL_PATH))
endif

  可见只有在 TARGET_BOARD_PLATFORM 中包含字段vsoc_arm64 vsoc_x86 vsoc_x86_64的时候该模块才会被包含。
  其中AndroidProduct.mk会包含lunch时供选择的产品名称以及其对应的makefile路径

flagstaff@flagstaff-pc:~/aosp_r.lns$ cat device/google/cuttlefish/AndroidProducts.mk 
PRODUCT_MAKEFILES := \
	aosp_cf_arm64_auto:$(LOCAL_DIR)/vsoc_arm64/auto/aosp_cf.mk \
    ...

COMMON_LUNCH_CHOICES := \
	aosp_cf_arm64_auto-userdebug \
    ...

2.添加 hidl service

//file:test/flagstaffTest/device.mk
PRODUCT_PACKAGES += \
	flagstaff.hardware.custom_hardware@1.0-service

  名字被添加到PRODUCT_PACKAGES变量中的模块，在整编译的时候会被包含到系统镜像中去。模块名字则来自于对应模块的name字段

flagstaff@flagstaff-pc:~/aosp_r.lns$ cat test/flagstaffTest/hardware/interfaces/custom_hardware/1.0/default/Android.bp 
cc_binary {
    name: "[email protected]",
    ...
    vendor: true,
}

3.编译

~/aosp_r.lns$ source build/envsetup.sh
~/aosp_r.lns$ lunch 30
~/aosp_r.lns$ make

  待编译好后，模块内容则会被包含在vendor.img中，因为hidl service的bp文件中指定了放置到vendor中去。

flagstaff@flagstaff-pc:~/aosp_r.lns$ ls out/target/product/generic_x86_64/*.img
out/target/product/generic_x86_64/cache.img
out/target/product/generic_x86_64/dtb.img
out/target/product/generic_x86_64/encryptionkey.img
out/target/product/generic_x86_64/ramdisk.img
out/target/product/generic_x86_64/super.img
out/target/product/generic_x86_64/system.img
out/target/product/generic_x86_64/userdata.img
out/target/product/generic_x86_64/vbmeta.img
out/target/product/generic_x86_64/vendor_boot.img
out/target/product/generic_x86_64/vendor.img

  实际上system.img/vendor.img都被打包进了surper.img了。
  当然在使用镜像前，也可以确认下hidlservice是否被正确包含，此时看下vendor目录即可，其内容和vendor.img是一致的，当然前提是全编译前删除了vendor目录。

flagstaff@flagstaff-pc:~/aosp_r.lns$ find  out/target/product/generic_x86_64/vendor -name "*flagstaff*"
out/target/product/generic_x86_64/vendor/etc/vintf/manifest/flagstaff.hardware.custom_hardware@1.0.xml
out/target/product/generic_x86_64/vendor/etc/init/flagstaff.hardware.custom_hardware@1.0-service.rc
out/target/product/generic_x86_64/vendor/bin/hw/flagstaff.hardware.custom_hardware@1.0-service
out/target/product/generic_x86_64/vendor/lib64/flagstaff.hardware.custom_hardware@1.0.so

  另外如果有问题，欢迎留言或者email([email protected])我，技术升级在于交流~~