需求布景

现在Google现已开释Android 13的基线代码，其中包括了automotive的product，但芯片厂商针对automotive的Android 13基线并未开释，在开释前，下面的方案商无法得知芯片厂商的将会以哪个product来开释automotive基线，因此，需求提前预研在其他product上移植automotive功用。

相关概念

  • automotive

    翻译过来便是汽车的意思，它是基于Android渠道的车载信息文娱体系，简称IVI(In-Vehicle Infotainment)，在Android 13中，automotive长这样

Android13 automotive移植

  • product

    AOSP针对不同的设备，设置的不同的产品。咱们在编译源码时，履行lunch指令后展现的列表便是当时基线提供的一切product

    q@jason-OptiPlex-7080:/projects/AOSP_Android13$ source build/envsetup.sh
q@jason-OptiPlex-7080:/projects/AOSP_Android13$ lunch
You're building on Linux
Lunch menu .. Here are the common combinations:
     1. aosp_arm-eng
     2. aosp_arm64-eng
     3. aosp_barbet-userdebug
     4. aosp_bluejay-userdebug
     5. aosp_bluejay_car-userdebug
     6. aosp_bramble-userdebug
     7. aosp_bramble_car-userdebug
     8. aosp_car_arm-userdebug
     9. aosp_car_arm64-userdebug
     10. aosp_car_x86-userdebug
     11. aosp_car_x86_64-userdebug
     12. aosp_cf_arm64_auto-userdebug
     13. aosp_cf_arm64_phone-userdebug
     14. aosp_cf_x86_64_foldable-userdebug
     15. aosp_cf_x86_64_pc-userdebug
     16. aosp_cf_x86_64_phone-userdebug
     17. aosp_cf_x86_64_tv-userdebug
     18. aosp_cf_x86_auto-userdebug
     19. aosp_cf_x86_phone-userdebug
     20. aosp_cf_x86_tv-userdebug
     21. aosp_cheetah-userdebug
     22. aosp_cloudripper-userdebug
     23. aosp_coral-userdebug
     24. aosp_coral_car-userdebug
     25. aosp_flame-userdebug
     26. aosp_flame_car-userdebug
     27. aosp_oriole-userdebug
     28. aosp_oriole_car-userdebug
     29. aosp_panther-userdebug
     30. aosp_raven-userdebug
     31. aosp_raven_car-userdebug
     32. aosp_ravenclaw-userdebug
     33. aosp_redfin-userdebug
     34. aosp_redfin_car-userdebug
     35. aosp_redfin_vf-userdebug
     36. aosp_rice14-userdebug
     37. aosp_slider-userdebug
     38. aosp_sunfish-userdebug
     39. aosp_sunfish_car-userdebug
     40. aosp_trout_arm64-userdebug
     41. aosp_trout_x86-userdebug
     42. aosp_whitefin-userdebug
     43. aosp_x86-eng
     44. aosp_x86_64-eng
     45. arm_krait-eng
     46. arm_v7_v8-eng
     47. armv8-eng
     48. armv8_cortex_a55-eng
     49. armv8_kryo385-eng
     50. beagle_x15-userdebug
     51. beagle_x15_auto-userdebug
     52. car_ui_portrait-userdebug
     53. car_x86_64-userdebug
     54. db845c-userdebug
     55. gsi_car_arm64-userdebug
     56. gsi_car_x86_64-userdebug
     57. hikey-userdebug
     58. hikey64_only-userdebug
     59. hikey960-userdebug
     60. hikey960_tv-userdebug
     61. hikey_tv-userdebug
     62. poplar-eng
     63. poplar-user
     64. poplar-userdebug
     65. qemu_trusty_arm64-userdebug
     66. rb5-userdebug
     67. sdk_car_arm-userdebug
     68. sdk_car_arm64-userdebug
     69. sdk_car_portrait_x86_64-userdebug
     70. sdk_car_x86-userdebug
     71. sdk_car_x86_64-userdebug
     72. sdk_pc_x86_64-userdebug
     73. silvermont-eng
     74. uml-userdebug
     75. yukawa-userdebug
     76. yukawa_sei510-userdebug
Which would you like? [aosp_arm-eng]
Pick from common choices above (e.g. 13) or specify your own (e.g. aosp_barbet-eng):

    不同的product打包出来的镜像略有不同，最终在设备上展现的效果也不一样，比方，手机刷的镜像跟车载刷的镜像，Launcher，Settings等不尽相同。在上面lunch的product列表中，带有car标识的都是automotive product，其他的大部分是phone product。

  • automotive移植

    便是将automotive的功用移植到非automotive的product上，行将非automotive product改形成automotive product，本篇咱们将72. sdk_pc_x86_64-userdebug改形成71. sdk_car_x86_64-userdebug，72. sdk_pc_x86_64-userdebug长这样

Android13 automotive移植

​ 现在咱们要将它改形成上面automotive的样子

product编译装备

每个product的编译离不开四个文件：

  • AndroidProducts.mk：界说product的名字，以及对应的Makefile文件
  • product.mk：对应product的Makefile文件，比方sdk_pc_x86_64.mk，里边包含了product一切的软件装备
  • BoardConfig.mk：对应product的硬件装备信息
  • device.mk：芯片厂商自界说的硬件装备信息

​ 看一下咱们要改造的72. sdk_pc_x86_64-userdebug这四个文件的内容

#AndroidProducts.mk
PRODUCT_MAKEFILES := \
    $(LOCAL_DIR)/sdk_pc_x86_64.mk \
COMMON_LUNCH_CHOICES := \
    sdk_pc_x86_64-userdebug \

COMMON_LUNCH_CHOICES界说了lunch combo称号为sdk_pc_x86_64-userdebug，该称号包括产品名+构建形式，userdebug表明调试形式，此外还有user形式和eng形式，关于这三个形式的区别，这儿不做过多介绍，可自行查阅相关资料。PRODUCT_MAKEFILES指定了product的makefile文件，$(LOCAL_DIR)表明当时目录。

#sdk_pc_x86_64.mk
PRODUCT_COPY_FILES += device/generic/goldfish/pc/config.ini.pc:config.ini
$(call inherit-product, $(SRC_TARGET_DIR)/product/sdk_x86_64.mk)
PRODUCT_NAME := sdk_pc_x86_64
PRODUCT_DEVICE := emulator64_x86_64
PRODUCT_BRAND := Android
PRODUCT_MODEL := PC on x86_64 emulator
PRODUCT_PACKAGE_OVERLAYS := device/generic/goldfish/pc/overlay
PRODUCT_COPY_FILES += \
    device/generic/goldfish/pc/data/etc/pc.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/pc.xml
PRODUCT_SDK_ADDON_SYS_IMG_SOURCE_PROP := device/generic/goldfish/pc/images_source.prop_template

sdk_pc_x86_64.mk文件里界说了产品的name、device硬件装备、brand、model等信息，其中PRODUCT_DEVICE指向BoardConfig.mk和device.mk的父目录

Android13 automotive移植

$(call inherit-product, $(SRC_TARGET_DIR)/product/sdk_x86_64.mk)表明该文件承继自sdk_x86_64.mk，$(SRC_TARGET_DIR)指向build/target目录。

PRODUCT_COPY_FILES表明将源码中的文件复制到镜像分区中

#BoardConfig.mk
# x86_64 emulator specific definitions
TARGET_CPU_ABI := x86_64
TARGET_ARCH := x86_64
TARGET_ARCH_VARIANT := x86_64
TARGET_2ND_ARCH_VARIANT := x86_64
BOARD_DO_NOT_STRIP_VENDOR_MODULES := true
TARGET_PRELINK_MODULE := false
include build/make/target/board/BoardConfigGsiCommon.mk
include build/make/target/board/BoardConfigEmuCommon.mk
BOARD_USERDATAIMAGE_PARTITION_SIZE := 576716800
BOARD_SEPOLICY_DIRS += device/generic/goldfish/sepolicy/x86
# Wifi.
BOARD_WLAN_DEVICE           := emulator
BOARD_HOSTAPD_DRIVER        := NL80211
BOARD_WPA_SUPPLICANT_DRIVER := NL80211
BOARD_HOSTAPD_PRIVATE_LIB   := lib_driver_cmd_simulated
BOARD_WPA_SUPPLICANT_PRIVATE_LIB := lib_driver_cmd_simulated
WPA_SUPPLICANT_VERSION      := VER_0_8_X
WIFI_DRIVER_FW_PATH_PARAM   := "/dev/null"
WIFI_DRIVER_FW_PATH_STA     := "/dev/null"
WIFI_DRIVER_FW_PATH_AP      := "/dev/null"

BoardConfig.mk中界说了cpu的参数，wifi装备，而且经过include引用了BoardConfigGsiCommon.mk和BoardConfigEmuCommon.mk文件里的装备，前者用于通用体系映像的装备，后者用于模拟器的装备。

device.mk是芯片厂商自界说的装备，这儿咱们看的是原生代码，剖析此文件没啥意义。

上述是72. sdk_pc_x86_64-userdebug的编译装备文件，同理可析71. sdk_car_x86_64-userdebug

product编译流程

当咱们履行source build/envsetup.sh指令时，会将envsetup.sh文件中界说的函数加载到当时shell环境，建立shell指令，比方lunch、make、croot等。

当履行lunch指令时，会履行envsetup.sh中的lunch()函数

function lunch()
{
	# 界说局部变量`answer`来寄存用户经过`lunch`指令传进来的参数（即`lunch-combo`，可所以字符串或数字）
    local answer
    if [[ $# -gt 1 ]]; then
        echo "usage: lunch [target]" >&2
        return 1
    fi
    local used_lunch_menu=0
    if [ "$1" ]; then
        answer=$1
    else
    	# 假如用户没有没有传进来任何值，则打印出`lunch-combo`列表，提示用户输入
        print_lunch_menu
        echo "Which would you like? [aosp_arm-eng]"
        echo -n "Pick from common choices above (e.g. 13) or specify your own (e.g. aosp_barbet-eng): "
        read answer
        used_lunch_menu=1
    fi
    local selection=
    if [ -z "$answer" ]
    then
    	#假如用户没有挑选，则默认挑选为aosp_arm-eng
        selection=aosp_arm-eng
    elif (echo -n $answer | grep -q -e "^[0-9][0-9]*$")
    then
        local choices=($(TARGET_BUILD_APPS= get_build_var COMMON_LUNCH_CHOICES))
        if [ $answer -le ${#choices[@]} ]
        then
            # array in zsh starts from 1 instead of 0.
            if [ -n "$ZSH_VERSION" ]
            then
                selection=${choices[$(($answer))]}
            else
                selection=${choices[$(($answer-1))]}
            fi
        fi
    else
        selection=$answer
    fi
    #省掉部分代码
    TARGET_PRODUCT=$product \
    TARGET_BUILD_VARIANT=$variant \
    TARGET_PLATFORM_VERSION=$version \
    #build_build_var_cache()最终会履行到soong_ui.bash
    build_build_var_cache
    if [ $? -ne 0 ]
    then
        if [[ "$product" =~ .*_(eng|user|userdebug) ]]
        then
            echo "Did you mean -${product/*_/}? (dash instead of underscore)"
        fi
        return 1
    fi
    #get_build_var()最终会履行到soong_ui.bash
    export TARGET_PRODUCT=$(get_build_var TARGET_PRODUCT)
    export TARGET_BUILD_VARIANT=$(get_build_var TARGET_BUILD_VARIANT)
    if [ -n "$version" ]; then
      export TARGET_PLATFORM_VERSION=$(get_build_var TARGET_PLATFORM_VERSION)
    else
      unset TARGET_PLATFORM_VERSION
    fi
    #省掉部分代码
}

# Get the exact value of a build variable.
function get_build_var()
{
    if [ "$BUILD_VAR_CACHE_READY" = "true" ]
    then
        eval "echo \"\${var_cache_$1}\""
        return 0
    fi
    local T=$(gettop)
    if [ ! "$T" ]; then
        echo "Couldn't locate the top of the tree.  Try setting TOP." >&2
        return 1
    fi
    #履行soong_ui.bash
    (\cd $T; build/soong/soong_ui.bash --dumpvar-mode $1)
}

lunch()函数最终会履行build/soong/soong_ui.bash脚本

#记录了开始构建时的准确时间戳，以毫秒为单位
export TRACE_BEGIN_SOONG=$(date +%s%N)
# Function to find top of the source tree (if $TOP isn't set) by walking up the
# tree.
#界说gettop函数
function gettop
{
	#找到源代码树的根目录,假如环境变量 TOP 现已设置而且对应的途径存在 build/soong/root.bp 文件，那么函数将回来该途径；否则，它将从当时目录向上查找，直到找到名为 build/soong/root.bp 的文件。
    local TOPFILE=build/soong/root.bp
    if [ -n "${TOP-}" -a -f "${TOP-}/${TOPFILE}" ] ; then
        # The following circumlocution ensures we remove symlinks from TOP.
        (cd $TOP; PWD= /bin/pwd)
    else
        if [ -f $TOPFILE ] ; then
            # The following circumlocution (repeated below as well) ensures
            # that we record the true directory name and not one that is
            # faked up with symlink names.
            PWD= /bin/pwd
        else
            local HERE=$PWD
            T=
            while [ \( ! \( -f $TOPFILE \) \) -a \( $PWD != "/" \) ]; do
                \cd ..
                T=`PWD= /bin/pwd -P`
            done
            \cd $HERE
            if [ -f "$T/$TOPFILE" ]; then
                echo $T
            fi
        fi
    fi
}
#将当时工作目录（PWD）保存到环境变量 ORIGINAL_PWD 中
# Save the current PWD for use in soong_ui
export ORIGINAL_PWD=${PWD}
#调用 gettop 函数，并将回来的结果保存到环境变量 TOP 中
export TOP=$(gettop)
#加载 microfactory.bash 脚本，该脚本应该坐落 TOP 环境变量所指示的途径中
source ${TOP}/build/soong/scripts/microfactory.bash
#调用 Android 构建体系的soong_ui，具体构建和运行某些组件
soong_build_go soong_ui android/soong/cmd/soong_ui
soong_build_go mk2rbc android/soong/mk2rbc/cmd
soong_build_go rbcrun rbcrun/cmd
#将当时目录切换到 TOP 环境变量所指示的途径
cd ${TOP}
#履行 soong_ui 程序，其途径为 getoutdir 环境变量的值，参数为 $@（表明一切传入的指令行参数）
exec "$(getoutdir)/soong_ui" "$@"

上面在履行soong_build_go soong_ui android/soong/cmd/soong_ui时，会履行/build/soong/cmd/soong_ui/main.go中的main()函数

func main() {
    //省掉部分代码，省掉的代码为结构build.Findsources()函数所需求的参数
	// Create a source finder.
	f := build.NewSourceFinder(buildCtx, config)
	defer f.Shutdown()
    //寻觅资源文件
	build.FindSources(buildCtx, config, f)
	c.run(buildCtx, config, args, logsDir)
}

在/build/soong/cmd/soong_ui/main.go中的main()函数中，中心主要是经过build.FindSources()去寻觅一切的makefile文件和bp文件

// FindSources searches for source files known to <f> and writes them to the filesystem for
// use later.
func FindSources(ctx Context, config Config, f *finder.Finder) {
	// note that dumpDir in FindSources may be different than dumpDir in NewSourceFinder
	// if a caller such as multiproduct_kati wants to share one Finder among several builds
	dumpDir := config.FileListDir()
	os.MkdirAll(dumpDir, 0777)
	// Stop searching a subdirectory recursively after finding an Android.mk.
    //寻觅一切的Android.mk文件，并添加到Android.mk.list中
	androidMks := f.FindFirstNamedAt(".", "Android.mk")
	err := dumpListToFile(ctx, config, androidMks, filepath.Join(dumpDir, "Android.mk.list"))
	if err != nil {
		ctx.Fatalf("Could not export module list: %v", err)
	}
	// Gate collecting/reporting mk metrics on builds that specifically request
	// it, as identifying the total number of mk files adds 4-5ms onto null
	// builds.
	if config.reportMkMetrics {
		androidMksTotal := f.FindNamedAt(".", "Android.mk")
		ctx.Metrics.SetToplevelMakefiles(len(androidMks))
		ctx.Metrics.SetTotalMakefiles(len(androidMksTotal))
		ctx.Metrics.DumpMkMetrics(config.MkMetrics())
	}
	// Stop searching a subdirectory recursively after finding a CleanSpec.mk.
    //寻觅一切的CleanSpec.mk文件，并添加到CleanSpec.mk.list中
	cleanSpecs := f.FindFirstNamedAt(".", "CleanSpec.mk")
	err = dumpListToFile(ctx, config, cleanSpecs, filepath.Join(dumpDir, "CleanSpec.mk.list"))
	if err != nil {
		ctx.Fatalf("Could not export module list: %v", err)
	}
	// Only consider AndroidProducts.mk in device/, vendor/ and product/, recursively in these directories.
    //寻觅一切的AndroidProducts.mk文件，并添加到AndroidProducts.mk.list中
	androidProductsMks := f.FindNamedAt("device", "AndroidProducts.mk")
	androidProductsMks = append(androidProductsMks, f.FindNamedAt("vendor", "AndroidProducts.mk")...)
	androidProductsMks = append(androidProductsMks, f.FindNamedAt("product", "AndroidProducts.mk")...)
	err = dumpListToFile(ctx, config, androidProductsMks, filepath.Join(dumpDir, "AndroidProducts.mk.list"))
	if err != nil {
		ctx.Fatalf("Could not export product list: %v", err)
	}
	// Recursively look for all Bazel related files.
	bazelFiles := f.FindMatching(".", findBazelFiles)
	err = dumpListToFile(ctx, config, bazelFiles, filepath.Join(dumpDir, "bazel.list"))
	if err != nil {
		ctx.Fatalf("Could not export bazel BUILD list: %v", err)
	}
	// Recursively look for all OWNERS files.
	owners := f.FindNamedAt(".", "OWNERS")
	err = dumpListToFile(ctx, config, owners, filepath.Join(dumpDir, "OWNERS.list"))
	if err != nil {
		ctx.Fatalf("Could not find OWNERS: %v", err)
	}
	// Recursively look for all TEST_MAPPING files.
	testMappings := f.FindNamedAt(".", "TEST_MAPPING")
	err = dumpListToFile(ctx, config, testMappings, filepath.Join(dumpDir, "TEST_MAPPING.list"))
	if err != nil {
		ctx.Fatalf("Could not find TEST_MAPPING: %v", err)
	}
	// Recursively look for all Android.bp files
    //寻觅一切的Android.bp文件，并添加到Android.bp.list中
	androidBps := f.FindNamedAt(".", "Android.bp")
	if len(androidBps) == 0 {
		ctx.Fatalf("No Android.bp found")
	}
	err = dumpListToFile(ctx, config, androidBps, filepath.Join(dumpDir, "Android.bp.list"))
	if err != nil {
		ctx.Fatalf("Could not find modules: %v", err)
	}
	// Recursively look for all product/board config files.
	configurationFiles := f.FindMatching(".", findProductAndBoardConfigFiles)
	err = dumpListToFile(ctx, config, configurationFiles, filepath.Join(dumpDir, "configuration.list"))
	if err != nil {
		ctx.Fatalf("Could not export product/board configuration list: %v", err)
	}
	if config.Dist() {
		f.WaitForDbDump()
		// Dist the files.db plain text database.
		distFile(ctx, config, f.DbPath, "module_paths")
	}
}

履行完build.FindSources()后，一切的AndroidProduct.mk文件都将被发现，这时就能展现一切的lunch combo项，然后依据用户挑选的combo，挑选对应的AndroidProduct.mk。

最终履行make -j16指令后，调用build/envsetup.sh里边的make()函数，最终会依据对应AndroidProduct.mk的规则，挑选对应的product.mk进行编译。

移植思路

了解了product编译流程后，自然而然咱们能想到的移植思路是，在72. sdk_pc_x86_64-userdebug的AndroidProduct.mk文件里装备71. sdk_car_x86_64-userdebug的product.mk，也便是将72. sdk_pc_x86_64-userdebug的编译流程改向71. sdk_car_x86_64-userdebug的编译流程，这样咱们的方针product就会按照车载product的装备进行编译了。检查车载product的编译装备，即翻开sdk_car_x86_64.mk文件

PRODUCT_PACKAGE_OVERLAYS := device/generic/car/common/overlay
$(call inherit-product, device/generic/car/emulator/aosp_car_emulator.mk)
$(call inherit-product, $(SRC_TARGET_DIR)/product/sdk_x86_64.mk)
EMULATOR_VENDOR_NO_SOUND := true
PRODUCT_NAME := sdk_car_x86_64
PRODUCT_DEVICE := emulator_car_x86_64
PRODUCT_BRAND := Android
PRODUCT_MODEL := Car on x86_64 emulator

能够看到，这儿仅仅承继了device/generic/car/emulator/aosp_car_emulator.mk和$(SRC_TARGET_DIR)/product/sdk_x86_64.mk这两个makefile文件，以及添加了PRODUCT_PACKAGE_OVERLAYS和EMULATOR_VENDOR_NO_SOUND两项装备，咱们将这些装备全部复制到sdk_pc_x86_64.mk中

Android13 automotive移植

当然，PRODUCT_NAME是不能变的，而且PRODUCT_DEVICE挑选车载的硬件装备。

最终履行编译

source build/envsetup.sh
lunch sdk_pc_x86_64-userdebug
make -j16

等候编译完结，启动模拟器

emulator

完美进入automotive，而且Model显示咱们自界说的称号

Android13 automotive移植

Android13 automotive移植

参考资料

blog.csdn.net/daoshuti/ar…

写给应用开发的 Android Framework 教程——玩转 AOSP 篇之添加 Product