廠商分離，多樣化也是android源碼發展方向，這對於各OEM廠商方案商也是極好的。雖然這篇比較新，但依然不涉及專利，方案也算不上。應該是可以配圖了。如題，這種多樣化必須只用一個鏡像，具體內容和第二條主線鏡像分析有關，和刷機、安全無關。
1、多開機畫面適配
開機畫面存儲於splash.img，由aboot去讀取。先用hexdump -C splash.img分析文件
在aboot中只使用到偏移和圖片尺寸0x01e0和0x0320。參照上篇分區表的格式，這個前面空的0x1000字節可以做圖片索引和偏移。下圖實例會很直觀。
其實關鍵點已經說完。圖片還是在0x1000開始，這樣做舊版本也是能夠讀到splash.img第一個圖片。有的splash.img開頭沒有空的0x1000字節，只能說對不起了。
如果需再詳細分析鏡像，鏡像前面128字節是文件頭，可定義幻數、版本、校驗什麼的，第16字節是圖片個數；第二個128字節前32位是圖片名，後接偏移量；第三個128字節前32位是圖片名，後接偏移量。源碼方面，splash.img製作工具，需要記錄圖片名，圖片寫到的位置，圖片個數，而偏移最好以512爲單位。aboot源碼先獲取splash鏡像頭，匹配圖片名，獲取偏移，後面加載一樣。
是不是很簡單，當然數據存放上可以更簡便、更規範，現在這樣做是爲了方便，舊版本也兼容。也許以後方案商會有改進。
2、多設備樹疊加層合入(dtbo)
dtbo是Android P的特性，https://source.android.com/devices/architecture/dto
設備樹https://blog.csdn.net/u012489236/article/details/97137007
boot.img中提取dts可以參照android鏡像分析
dt和dtbo基本知識看完後，奔主題了。先記下dt和dtbo加載流程圖：(圖片拉的官網，假如看不到去官網https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zb3VyY2UuYW5kcm9pZC5nb29nbGUuY24vZGV2aWNlcy9hcmNoaXRlY3R1cmUvaW1hZ2VzL3RyZWJsZV9kdG9fbXVsdGlwbGVfZHRfcnVudGltZS5wbmc?x-oss-process=image/format,png）
- Read the SoC ID and select the corresponding main device tree, and
- Read the board ID and select the set of overlay device trees accordingly.
這裏用英文讀更好，明確指出是支持多dtbo合入，官網這兩句後面一段也可以得出此結論。方案商也許和我之前理解一樣，只支持單個設備樹疊加層。再仔細看上圖流程，顯然支持多dtbo合入可以使dtbo.img適配更多的設備硬件變化，佔用的空間更小。之前還有個誤解就是以爲設備樹也在dtbo.img中。
要實現多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能夠匹配到將使用的設備樹疊加層，並且能夠merge到主設備樹。dtbo的merge功能google有提供庫;匹配疊加層，方案商只找最佳匹配項，dtbo的索引也只有一個int型。我們要實現官網一樣的效果，dtbo應該有Suitable,dev屬性，指定哪些設備可以使用該dtbo。如果aboot讀到當前設備在Suitable,dev屬性中，則merge該dtbo到主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， fastboot recovery的UI關閉，以及各種測試，基本圍繞android的安全和解耦。建議廠商代碼與system內容隔離；開啓所有安全措施，不留後門；保護好自己的簽名。
代碼完全隔離是有難度，但對於耦合嚴重的公司，移植是最大工作量，大大消耗程序員的時間和激情。與我來說這點是最深惡痛絕的。如果repo可以include，<google的manifest>，<方案商的manifest>，<自己的manifest>來共同管理一套源碼，這種工作環境不要太爽。
安全方面現有的免費的安全保護措施給你用，配置好即可，生產流程也沒有搞得多複雜。證書密鑰可以使用Jenkins或者搞工具規則限制，通過證書密鑰破解不要太簡單。再就是區塊鏈技術或可用於證書密鑰保護，甚至直接保護設備安全。
鏡像分析深入到反彙編，可以對破解與反破解有一定了解，設備安全方面也知道個“所以然”。同時可以認識到，機器只認識0和1，人在不停的定義和解釋。好像美劇《少年謝爾頓》小謝耳朵的夢中有出現0和1。
莫名其妙的想發此圖。