多开机界面适配，多dtbo合入

       

目录

1、多开机画面适配

2、多设备树叠加层合入(dtbo)

---

厂商分离，多样化也是android源码发展方向，这对于各OEM厂商方案商也是极好的。虽然这篇比较新，但依然不涉及专利，方案也算不上。应该是可以配图了。如题，这种多样化必须只用一个镜像，具体内容和第二条主线镜像分析有关，和刷机、安全无关。

1、多开机画面适配

1.1、作用

所有产品（尤其适用于不同屏幕的），刷机包使用同一个开机界面镜像。

1.2、方案简介

原方案：高通开机界面存储于splash.img，在启动阶段aboot加载。目前只支持一张。

修改方案：多张图片按定义格式存储于splash.img中，aboot根据设备信息加载指定图片。

1.3、方案详细分析

先用hexdump -C splash.img分析文件

        在aboot中只使用到偏移和图片尺寸0x01e0和0x0320。参照上篇分区表的格式，这个前面空的0x1000字节可以做图片索引和偏移。下图实例会很直观。

         其实关键点已经说完。图片还是在0x1000开始，这样做旧版本也是能够读到splash.img第一个图片。有的splash.img开头没有空的0x1000字节，只能说对不起了。

         如果需再详细分析镜像，镜像前面128字节是文件头，可定义幻数、版本、校验什么的，第16字节是图片个数；后面每个128字节存储一个图片信息，例如我存了两个图片，可以看到上图第二个128字节前32位是480*800的图片名，后接偏移量；第三个128字节前32位是1280*720的图片名，后接偏移量。源码方面，splash.img制作工具，需要记录图片名，图片写到的位置，图片个数，而偏移最好以512为单位。aboot源码先获取splash镜像头，匹配图片名，获取偏移，后面加载一样。

         是不是很简单，我这个数据头只能描述0x1000/0x80-1=31个图片，现在这样做是为了方便，旧版本也兼容。当然数据存放上可以更简便规范，也许以后方案商会有改进。

2、多设备树叠加层合入(dtbo)

1.1、基础

请务必先了解设备树

          dtbo是Android P的特性，https://source.android.com/devices/architecture/dto
         设备树Linux设备树详解(一) 基础知识_奇小葩的博客-CSDN博客_linux 设备树
         boot.img中提取dts可以参照android镜像分析

1.2、作用

所有产品（尤其适用于同一架构不同硬件/参数的产品），使用一个dtbo镜像。

1.3、方案简介

         dt和dtbo基本知识看完后，奔主题了。先记下dt和dtbo加载流程图：(图片拉的官网，假如看不到去官网https://i-blog.csdnimg.cn/blog_migrate/636b0822d1c3bdbbfafe23e2ac7c9015.png）

1. Read the SoC ID and select the corresponding main device tree, and
2. Read the board ID and select the set of overlay device trees accordingly.

         这里用英文读更好，明确指出是支持多dtbo合入，官网这两句后面一段也可以得出此结论。方案商也许和我之前理解一样，只支持单个设备树叠加层。再仔细看上图流程，显然支持多dtbo合入可以使dtbo.img适配更多的设备硬件变化，占用的空间更小。之前还有个误解，以为设备树也存储在dtbo.img中。

1.4、方案详细分析

        我们要实现官网描述的多个dtbo合入到主设备树，即一个dtbo镜像包含很多很多个设备描述叠加层，它可能包括两个屏的设备树叠加层、三个充电IC的dtbo，也可能是同一个屏但包含不同刷新率的dtbo等等等，我们根据设备信息，以及重启时加载信息选择不同参数进行dtbo的叠加。

        1、ODM可以把每个支持的外设编写成单片DTBO（即两个屏的就生成两个dtbo、三个充电IC就生成三个dtbo、当然也可以同一款外设不同参数）。

        2、ODM给每个设备定义外设表，根据设备的外设信息表加载 屏的dtbo、充电IC的dtbo等等。

        如果这个外设信息表可以在售后维修端更改，那手机可以像电脑更换显卡、内存条、硬盘一样，可以选择更换不同的屏、充电IC、电池等等外设。这种模式也降低了新产品生产研发维修成本。(降低研发成本当然是大公司大批量超多种类，有完整驱动解耦的情况)

         从前面基础知道主设备树在boot中，dtbo在dtbo.img镜像中，dtbo合入到主设备树代码在aboot中。要实现多dtbo合入，那就需要dtbo.img支持，aboot识别。

步骤如下：

         第一步，先是编出包含多个叠加层的dtbo.img。下面（示例是两个叠加层）是创建和解析dtbo.img的命令。如果要源码直接编译，可在内核的kernel\msm-4.9\arch\arm64\boot\dts\**\Makefile中设置。

mkdtimg create dtbo.img dytest0.dtbo ***.dtbo

mkdtimg dump dtbo.img

dt_table_header:

               magic = d7b7ab1e

          total_size = 77055

         header_size = 32

       dt_entry_size = 32

      dt_entry_count = 2

   dt_entries_offset = 32

           page_size = 2048

             version = 0

dt_table_entry[0]:

             dt_size = 287

           dt_offset = 96

                  id = 00000000

                 rev = 00000000

           custom[0] = 00000000

           custom[1] = 00000000

           custom[2] = 00000000

           custom[3] = 00000000

           (FDT)size = 287

     (FDT)compatible = eeprom

dt_table_entry[1]:

             dt_size = 76672

           dt_offset = 383

                  id = 00000000

                 rev = 00000000

           custom[0] = 00000000

           custom[1] = 00000000

           custom[2] = 00000000

           custom[3] = 00000000

           (FDT)size = 76672

     (FDT)compatible = base

cat dytest0.dtsi

/dts-v1/;

/plugin/;



/ {

    Suitable,dev = "***，***，***";

//if device name in Suitable,dev, will merge this DTBO to Main DT. So that eeprom could not use.

    compatible = "eeprom";

};

&i2c_6 {

       status = "disabled";

};

         第二步，需要aboot能够匹配到需要使用的dtbo，并且能够merge到主设备树。dtbo的merge功能google有提供库;匹配叠加层，方案商只找最佳匹配项，dtbo的索引也只有一个int型。而我们要实现官网一样的效果，dtbo应该有Suitable,dev属性，指定哪些设备可以使用该dtbo。如果aboot读到当前设备在Suitable,dev属性中，则应该将检索到的dtbo merge到主dt。

         第三步，增加compatible信息。由于编译dtbo.img是用ls查看dtb输出目录下的所有dtbo后缀文件，光知道索引号是不知道具体加载了哪个dtbo(cmdline和设备属性中可以看到dtbo索引号，但没有解析dtbo.img是不知道dtbo顺序的)。所以每个dtbo的dtsi最好加上compatible信息。aboot匹配到dtbo后，也获取其compatible信息，将该信息放在设备属性或cmdline中。这步不是必须，但方便查看和调试，作用很大。

         从google官网知道，现在P是支持多dtbo的，所以aboot就后两步提到的修改，使用ufdt_apply_overlay依次merge匹配的dtbo，这里不附修改代码。官网还提到后merge的dtbo其值有效性更高，可以每个dtbo继续加入优先级信息，也可以在编译时排下序。不难实现，但我就懒得做了，dtsi里面相同信息注意下即可。

本博客总结：

         这两点改进，其实已经看到趋势，比如splash.img开头空的0x1000字节，google官网关于dtbo的说明。这里的实现也相当于临门一脚，也许方案商在考虑更全面的实现。

系列总结：

         每个版本升级中关键修改，其中包括verifyboot， 文件级加密，分区加密，vbmeta， dtbo， user版本的fastboot和recovery的UI关闭，以及各种测试，底层新特性基本围绕android的安全和解耦。建议厂商代码与system内容隔离；开启所有安全措施，不留后门；保护好自己的签名。

         代码完全隔离是有难度，但对于耦合严重的公司，移植是最大工作量，大大消耗程序员的时间和激情。与我来说这点是最深恶痛绝的。如果repo可以include，<google的manifest>，<方案商的manifest>，<自己的manifest>来共同管理一套源码，这种工作环境不要太爽。

         安全方面现有的免费的安全保护措施给你用，配置好即可，生产流程也没有搞得多复杂。证书密钥可以使用Jenkins或者搞工具规则限制，通过证书密钥破解不要太简单。再就是区块链技术或可用于证书密钥保护，甚至直接保护设备安全。

         镜像分析深入到反汇编，可以对破解与反破解有一定了解，设备安全方面也知道个“所以然”。同时可以认识到，机器只认识0和1，人在不停的定义和解释。好像美剧《少年谢尔顿》小谢耳朵的梦中有出现0和1。
         最后，反汇编到机器码更是对程序和数据的理解到新程度，眼里一切皆是01，这是心态上的提升，也是最重要的。这句话出现第二遍。觉得重要可以收藏以后再看第3/N遍。

莫名其妙的想发此图。