简述AOSP ROM Tree迁移CLO ROM Tree 源码实际上本质区别不大，只是多了高通的优化罢了，虽然CLO对高通设备友好，但是其他设备（MTK，Tensor等）只要想，运行qssi是一点没有问题的。本篇我们用基于AOSP系的LineageOS和基于CLO系的AOSPA来说明两套源码的小区别，并将LineageOS系设备树迁移到CLO系内核部分板载配置LineageOS：# Kernel (Build) BOARD_KERNEL_IMAGE_NAME := Image TARGET_KERNEL_CLANG_COMPILE := true TARGET_KERNEL_SOURCE := kernel/qcom/kona TARGET_KERNEL_CONFIG := vendor/kona_defconfigAOSPA：# Kernel (Build) KERNEL_DEFCONFIG := kona_defconfig TARGET_KERNEL_VERSION := 4.19 TARGET_USES_UNCOMPRESSED_KERNEL := true将其改为对应的构建标志即可注意： 1. 虽然AOSPA的构建系统兼容LineageOS系列构建标志，但是建议迁移到AOSPA的 2. 迁移到AOSPA的构建系统后内核请放在对应版本的文件夹，例如Kona和lito（内核版本4.19）都是kernel/msm-4.19，lahaina（内核5.4），放在kernel/msm-5.4内核头由于CLO系列使用qti_kernel_headers(和AOSP系列generated_kernel_headers一样是从内核中生成)，所以从AOSP迁移到clo需要将使用generated_kernel_headers的hardware改为qti_kernel_headers同时需要将内核中Androidbp改回Android.bp以重新使用qti_kernel_headers在部分机型的内核中，由于我们导入了厂商的更改，可能在生成内核头报错，所以在构建内核需要重新生成kenrel header blueprint例：4.19+：$ python kernel_headers.py --header_arch arm --gen_dir ${KERNEL_SOURCE_DIR} \ --arch_asm_kbuild ${KERNEL_SOURCE_DIR}/arch/arm/include/uapi/asm/Kbuild \ --arch_include_uapi ${KERNEL_SOURCE_DIR}/arch/arm/include/uapi/**/*.h \ --techpack_include_uapi ${KERNEL_SOURCE_DIR}/techpack/*/include/uapi/*/**/*.h \ --asm_generic_kbuild ${KERNEL_SOURCE_DIR}/include/uapi/asm-generic/Kbuild.asm blueprints $ python kernel_headers.py --header_arch arm64 --gen_dir ${KERNEL_SOURCE_DIR} \ --arch_asm_kbuild ${KERNEL_SOURCE_DIR}/arch/arm64/include/uapi/asm/Kbuild \ --arch_include_uapi ${KERNEL_SOURCE_DIR}/arch/arm64/include/uapi/**/*.h \ --techpack_include_uapi ${KERNEL_SOURCE_DIR}/techpack/*/include/uapi/*/**/*.h \ --asm_generic_kbuild ${KERNEL_SOURCE_DIR}/include/uapi/asm-generic/Kbuild.asm blueprints4.4~4.14:$ python kernel_headers.py --header_arch arm --gen_dir ${KERNEL_SOURCE_DIR} \ --arch_asm_kbuild ${KERNEL_SOURCE_DIR}/arch/arm/include/uapi/asm/Kbuild \ --arch_include_uapi ${KERNEL_SOURCE_DIR}/arch/arm/include/uapi/**/*.h \ --asm_generic_kbuild ${KERNEL_SOURCE_DIR}/include/uapi/asm-generic/Kbuild.asm blueprints $ python kernel_headers.py --header_arch arm64 --gen_dir ${KERNEL_SOURCE_DIR} \ --arch_asm_kbuild ${KERNEL_SOURCE_DIR}/arch/arm64/include/uapi/asm/Kbuild \ --arch_include_uapi ${KERNEL_SOURCE_DIR}/arch/arm64/include/uapi/**/*.h \ --asm_generic_kbuild ${KERNEL_SOURCE_DIR}/include/uapi/asm-generic/Kbuild.asm blueprintsKERNEL_SOURCE_DIR为内核目录注意：目前无法构建在构建系统时构建5.10+内核设备树和blobs部分实际上设备树的改动不大，主要就是解决部分条目与CLO源码内的条目冲突而已但是在AOSPA中，存在qcom common，这极大减轻了设备树编写难度，同时因为使用BSP，此套blobs并无厂商更改，当然不想用也可以（使用qcom common从device.mk中指定TARGET_BOARD_PLATFORM然后指定需要使用的components，这里（TARGET_COMMON_QTI_COMPONENTS）如果指定为all，则会设置以下条目adreno alarm audio av bt display gps init media nfc overlay perf telephony usb vibrator wfd wlan如果指定为all后，请视情况删除设备树相关条目，并且清理设备的vendor blobs在部分情况下，可能需要编写device_framework_matrix.xmlhardware配置CLO系列不需要pathmap，但是需要手动clone hardware，且目录与AOSP系列可能不同CLO clone hardware目录：audio：vendor/qcom/opensource/audio-hal/primary-haldisplay：hardware/qcom/displaymedia：hardware/qcom/media从AOSP NFC迁移回NXP NFC（仅适用于pn5xx和sn1xx，可选）在TARGET_COMMON_QTI_COMPONENTS添加nfc，然后恢复vintf相关条目，确定是pn5xx还是SN1xx，然后拉取正确的halimpl和hidlimpl注意：从13开始CLO并没有合并pn5xx相关提交（jni，utils等），需要从caf/nxpnfc-project/br_android_ncihalx_row_13 branch获取相关源码，如果需要和sn1xx共存，请修改相关命名空间和include的头文件等

简单记录camera postproc因configureRpcThreadpool崩溃解决方法 因为在Android 12+之后已经不允许shrinking threadpool，如提交所示，从而导致相机崩溃。修复我们可以用IDA定位到configThreadpool (_ZN7android8hardware22configureRpcThreadpoolEmb) 的位置，如下然后我们选定它，然后Edit > Patch program > Change byte...然后可以看到BL ._ZN7android8hardware22configureRpcThreadpoolEmb它的HEX是1F 20 03 D5（部分blobs可能不一样，具体情况得汇编分析）我们将BL ._ZN7android8hardware22configureRpcThreadpoolEmb改为NOP，对应的HEX是1F 20 03 D5修正完成后如图extract-files配置function blob_fixup() { case "${1}" in vendor/lib64/[email protected]) hexdump -ve '1/1 "%.2X"' "${2}" | sed "s/210080521F0A0094/210080521F2003D5/g" | xxd -r -p > "${TMPDIR}/${1##*/}" mv "${TMPDIR}/${1##*/}" "${2}" ;; esac }或function blob_fixup() { case "${1}" in vendor/lib64/[email protected]) "${SIGSCAN}" -p "1F 0A 00 94" -P "1F 20 03 D5" -f "${2}" ;; esac }参考：https://github.com/LineageOS/android_device_xiaomi_gauguin/commit/07987caaf4d4fe35a7ada7fdd90cb567faf115b0https://github.com/LineageOS/android_device_oneplus_sm8250-common/commit/901baf95a955903be7138467e4d0082efd26ae1c

git小实战，内核添加subtree, 内核caf合并和subtree caf tag合并 CAF TAG是CodeAurora网站的源码,（不过今年可能要改成CLO，目前主角不是他，所以先不说）。CAF的标签对应的芯片组可以从wiki获取教程以msm-4.9的SDM710为蓝本进行教程。Subtree4.9内核的staging是不带Qcacld3.0等一系列的必需品(当然这玩意在内核源码外面又不是不能构架)如果我们需要把Qcacld3.0扔进内核，有两个办法1.下载Qcacld源码直接扔到对应目录（drivers/staging/qcacld-3.0）2.subtree到对应目录（drivers/staging/qcacld-3.0）subtree后期CAF TAG更新的时候直接merge即可，而第一种方法就emmm（自行体会）首先，我们找到内核源码对应tag的qcacld源码，然后进入内核源码目录例如我们内核源码tag是LA.UM.8.8.r1-09100-SDM710.0，所以我们qcacld也是这个tag然后我们输入命令git subtree add --prefix=drivers/staging/qcacld-3.0 https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qcacld-3.0.git LA.UM.8.8.r1-09100-SDM710.0然后就会发现qcacld-3.0已经在drivers/staging/qcacld-3.0里了，而且qcacld历史提交也在不过目前是无法构建qcacld的（因为这是教git，所以不在此篇文章范围之内）Subtree的合并例如caf又放出新的tag了LA.UM.8.8.r1-09400-SDM710.0，我们需要合并怎么办首先先fetch新的taggit fetch https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qcacld-3.0.git LA.UM.8.8.r1-09400-SDM710.0然后git merge -s subtree FETCH_HEAD解决冲突就像解决kernel版本更新一样解决，最后git add .，git commit或者git commit -a完成提交，如果你不明白，可以看caf tag合并，冲突解决的教程，因为都是一致的CAF TAG合并也是一样caf又放出新的tag了LA.UM.8.8.r1-09400-SDM710.0，我们需要合并怎么办先fetch新的taggit fetch https://source.codeaurora.org/quic/la/kernel/msm-4.8.git LA.UM.8.8.r1-09400-SDM710.0然后git merge FETCH_HEAD如果冲突了怎么办举个栗子自动合并 arch/arm64/boot/dts/qcom/sda845-sdxpoorwills.dtsi 冲突（内容）：合并冲突于 arch/arm64/boot/dts/qcom/sda845-sdxpoorwills.dtsi 自动合并失败，修正冲突然后提交修正的结果。我们看到它冲突了，我们先确定他那些文件冲突了git status 位于分支 lineage-18.1 您有尚未合并的路径。 （解决冲突并运行 "git commit"） （使用 "git merge --abort" 终止合并） 未合并的路径： （使用 "git add <文件>..." 标记解决方案） 双方修改： arch/arm64/boot/dts/qcom/sda845-sdxpoorwills.dtsi可以确定是sda845-sdxpoorwills.dtsi有冲突，我们打开看看那里冲突了，或者git diff查看<<<<<<< HEAD /* Copyright (c) 2017-2018, The Linux Foundation. All rights reserved. * Copyright (C) 2020 XiaoMi, Inc. ======= /* Copyright (c) 2017-2018, 2021 The Linux Foundation. All rights reserved. >>>>>>>emmm...这种的话解决成如下就行了/* Copyright (c) 2017-2018, 2021 The Linux Foundation. All rights reserved. * Copyright (C) 2020 XiaoMi, Inc.解决完成之后，git add .和git commit或者git commit -a提交完工最后如有错误，欢迎指出

简述 extract-files.sh 和 setup-makefiles.sh 作用 extract-files和setup-makefiles算是比较重要的脚本，爱来自LineageOS，对于很多入坑的小可爱们并不知道它是干啥的，所以本章讲述它的重要性，和为什么需要它。功能介绍extracr-files适用于依据blobs list来提取blobs然后运行setup-makefiles来生成makefile复制blobs，这样可以节约维护者大量手动复制blobs和写makefiles的痛苦。同时它也支持了复制部分blobs的功能，例如cne有问题需要升级，我们就可以使用这个功能。同时还支持pin blobs，一旦这个blobs并没有必要更新，就可以选择pin sha1来解决setup-makefiles，就没啥好说的了，只是帮助生成makefiles而已使用方法首先通过脚本代码了解功能# 这是一个common tree下的extract-files的功能 while [ "${#}" -gt 0 ]; do case "${1}" in --only-common ) ONLY_COMMON=true ;; --only-target ) ONLY_TARGET=true ;; -n | --no-cleanup ) CLEAN_VENDOR=false ;; -k | --kang ) KANG="--kang" ;; -s | --section ) SECTION="${2}"; shift CLEAN_VENDOR=false ;; * ) SRC="${1}" ;; esac shift done--only-common意思很简单，就是只拉取并生成common供应商树--only-target也很简单，就是只拉取并生成target的供应商树，target不理解的话，可以举个例子，例如你的设备树是tama，加了这个就是获取tama的供应商树-n | --no-cleanup不清理供应商树，这个也很好理解-k | --kang指显示获取的blobs的sha1，这里的kang并不是指偷窃代码，这种应用场景很多，例如你要升级CNE的blobs又想pin，就可以用它-s | --section是用于选择你需要获取的blobs，场景使用大多数和-k一样ADB提取，因为繁琐暂时不提他使用的时候需要解包好的ROM，用于提取blobs例如我们要生成一个vendor tree就需要:bash extract-files.sh #解包好的ROM目录然后就可以获得一个vendor tree如果我们需要取一部分blobs，那么只需这样: bash extract-files.sh #解包好的ROM目录 -s "你需要提取的项目"注意：你必须需要为blobs list进行分类，不然等同虚设要显示sha1也很简单，只需要加-k就可以了修补blobsblobs并不是一直都会正常工作的，肯定会随着一次次更新，而不再可用，这我们extract-files脚本也就派上用场了案例：libsecureuisvc_jni.so提示缺symbols因为新的库中已经移除了_ZN7android21SurfaceComposerClient11Transaction5applyEb()这个符号。因为已经不需要，所以我们可以使用shim来修复它。首先创建libsecureshim.c，然后：void _ZN7android21SurfaceComposerClient11Transaction5applyEb() {}然后创建blueprint，然后：cc_library_shared { name: "lib-secureuishim", srcs: ["lib-secureuishim.c"], product_specific: true, }最后，将其加入device.mk构建它当然这样还远远不够，还需要patch libsecureuisvc_jni.so。这里写出手动打patch的命令patchelf --add-needed "lib-secureuishim.so" product/lib64/libsecureuisvc_jni.so如果需要在跑extract-files就打上patch则需要对extract-files.sh添加blob_fixup，代码如下function blob_fixup() { case "${1}" in product/lib64/libsecureuisvc_jni.so) "${PATCHELF}" --add-needed "lib-secureuishim.so" "${2}" ;; esac }然后重新运行extract-files

实战改造动态分区 动态分区是使用 Linux 内核中的 dm-linear device-mapper 模块实现的。super 分区包含列出了 super 中每个动态分区的名称和块范围的元数据。在第一阶段 init 期间，系统会解析并验证此元数据，并创建虚拟块设备来表示每个动态分区。[Android 开源项目 | 动态分区]为什么建议改造因为旧的机型空间分配不均匀，而且随着Android版本的迭代，增加的新特性越来越多，对系统空间占用也越来越高。所以改造动态分区就很有必要了。改造示意图 from Google:从图中可以看到，我们的system,product,system_ext,vendor和odm已经合并为一个大分区，名为super。改造的动态分区优点有很多，首先我们不用改动分区表，这个对于个人维护者也很方便，改造失败也容易救回。改造前的准备AOSP源码要求为Android10+，这里使用Android 13的源码必须要改为first stage mount, 而不是内核dtbo fstab来完成第一阶段启动不得使用SAR（System as root）开始改造device.mk部分添加以下flag：PRODUCT_USE_DYNAMIC_PARTITIONS := true PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true这些操作用于启用动态分区，第二个flag为改造动态分区，都需要进行启用。然后我们需要构建fastbootd以刷入这些逻辑分区PRODUCT_PACKAGES += \ fastbootdfstab移除厂商原来的system和vendor挂载点，例如/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1 wait,first_stage_mount /dev/block/bootdevice/by-name/vendor /vendor ext4 ro,barrier=1 wait,first_stage_mount改造为system /system ext4 ro,barrier=1 wait,avb=vbmeta,logical,first_stage_mount system_ext /system_ext ext4 ro,barrier=1 wait,avb,logical,first_stage_mount vendor /vendor ext4 ro,barrier=1 wait,avb,logical,first_stage_mount product /product ext4 ro,barrier=1 wait,avb,logical,first_stage_mount这时候细心的小可爱发现了，我在原来system和vendor基础上添加了product和system_ext，因为目前情况下我们已经把system和vendor的所有空间改装成了一个super分区，所以现在的system，vendor，product，system_ext都为逻辑分区。做个比方，super相当于一块硬盘，我们从super切出一块一块分区。BoardConfig(板级配置)修改这里我们需要添加以下flag：BOARD_SUPER_PARTITION_SIZE # 改造super分区大小，如果你的设备有system和vendor，那么super分区大小为总和，如果是AB分区，则为所有AB分区总和/2 BOARD_SUPER_PARTITION_GROUPS # Super分区组，命名打个比方如果机型为oneplus，可以设置为op_dynamic_partitions，接下来的就以op_dynamic_partitions来介绍 BOARD_SUPER_PARTITION_METADATA_DEVICE # metadata设备，设置为system BOARD_SUPER_PARTITION_BLOCK_DEVICES # Super分区要利用的挂载点，如果你的设备有system和vendor，那么设置为system vendor(中间空格隔开或者\换行) BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE # System分区大小 BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE # Vendor分区大小 BOARD_OP_DYNAMIC_PARTITIONS_PARTITION_LIST # 逻辑分区组我们设置为system system_ext product vendor(中间空格隔开或者\换行)，依照fstab添加分区来更改 BOARD_OP_DYNAMIC_PARTITIONS_SIZE # Super盘大小，这里数值建议(BOARD_SUPER_PARTITION_SIZE - 4MB)，以免出现奇怪问题以下为设置分区格式(ext4/erofs[内核需支持])BOARD_PRODUCTIMAGE_FILE_SYSTEM_TYPE := ext4 BOARD_SYSTEM_EXTIMAGE_FILE_SYSTEM_TYPE := ext4 BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE := ext4设置输出位置(无需解释)TARGET_COPY_OUT_PRODUCT := product TARGET_COPY_OUT_SYSTEM_EXT := system_ext TARGET_COPY_OUT_VENDOR := vendorSELinux政策改造动态分区存储设备必须使用 super_block_device_type 属性进行标记。例如，如果设备已经有 system 和 vendor 分区，并且您希望将它们用作块存储设备来存储改造动态分区的 extent，并且其按名称符号链接标记为 system_block_device：/dev/block/platform/soc/10000\.ufshc/by-name/system u:object_r:system_block_device:s0 /dev/block/platform/soc/10000\.ufshc/by-name/vendor u:object_r:system_block_device:s0然后，将以下行添加到 device.te：typeattribute system_block_device super_block_device_type;第一次刷入改造动态分区首先我们需要刷入改造动态分区后构建的recovery并且进入然后选择Enter fastboot，进入fastbootd模式然后刷入super_empty.img开始使用动态分区fastboot wipe-super super_empty.img注意：如果fastboot提示没有找到命令，则需要升级最新版本fastboot，若有提示权限问题，请忽略。若提示报错，请检查BOARD_SUPER_PARTITION_BLOCK_DEVICES标志第一分区是否为BOARD_SUPER_PARTITION_METADATA_DEVICE指定的分区。然后选择enter recovery，进行正常刷机步骤即可体验动态分区