問題的歷史可以在這裡找到：
1）如何在智慧型手機（ARM 或 x86）上安裝 lxc 的 ubuntu 伺服器？
2）Ubuntu Touch (UBports) 和 Android 對 LXC/LXD 容器的支援（用於運行 Ubuntu）：當前狀態
子問題：
1）應該使用哪些SDK組件？
2) 如何準備/轉換可啟動映像以供載入？
3）如何替換原來的bootloader來啟動另一個核心（如何將其指向新路徑）？
4) 還應該執行哪些其他步驟？
我會嘗試自己回答這個問題，但通常更喜歡那些已經遵循這條道路的人提供的一些指導或資訊。我找到了以前嘗試的鏈接，但它們相當舊。 Linux 伺服器安裝的過程有很好的文件記錄（我依賴 Debian 和 Ubuntu 文件）。智慧型手機供應商（如華碩）在其網站上提供了用於解鎖引導程式的工具，但這不足以完成任務。該工具只是解鎖引導程序，但不會更改引導選單，這意味著應該使用外部 SDK 工具（選單中根本沒有從 SD 卡或網路引導的選項）。即引導程式本身應該由 SDK 更改。任何連結或資訊將不勝感激。
答案1
我在研究解決方案方面取得了一些進展：
1）清除用於實驗的裝置中的所有使用者資料（以恢復模式啟動>清除快取/清除資料/恢復原廠設定）
2）查看非官方來源
網路上有許多文章和論壇貼文。其中一些很有用。其中大多數都相當舊，而且上次更新是很久以前的事了。不好的是，它們中的大多數包含有關對設備進行root 的資訊（即，透過故意安裝利用已知漏洞來升級其權限的rootkit 來破壞作業系統安全）以及包含此類rootkit 的不受信任/低信譽腳本的連結。這些潛在有害的信息與有用的部分混合在一起，提供了可用選項的總體概述。
許多文章發表在 xda-developers.com 網站上，其論壇部分和維基百科。
一些有用的維基文章：
這些 wiki 文章通常維護得相當糟糕（最後一次編輯是在 2015 年）。
3）選擇平台（x86、ASUS Zenfone2）
就我而言，我是從自己使用過的 Android 裝置池中進行選擇。他們中的大多數都有基於 ARM 的 CPU。最新、最強大的是採用 x86 Intel CPU（64 位元指令集）的華碩。選擇 x86 的另一個原因是更好的 Linux 支援以及運行基於 x86/AMD64 的 lxc 容器的要求。選擇 ARM 需要開發單獨的容器分支或使用某種類比/轉換工具（不確定此類工具是否有效率/維護/支援良好）。
4）意識到使用官方（供應商支援的）工具可能無法實現該目標
我向華碩技術支援發送了有關其引導程式解鎖工具的使用的郵件。但答案很簡單：「該工具只是解鎖引導程序，我們無法幫助您執行進一步的步驟，我們甚至無法告訴您如果使用該工具會發生什麼」。即該工具是無用的（我什至不知道它是否在我的情況下以某種方式工作以及它與什麼不同fastboot oem unlock）。為了啟動該工具，我首先必須降級到 Android 5.0，因為較新版本的 ROM 不支援它。所有與更改引導程式和引導其他映像有關的事情都是非官方的、不受支援的、不建議的、違反保固等的。
5) [選用：註 1] 選擇並安裝恢復（手機或作業系統供應商不正式支援）
'恢復'- 是引導程式/BIOS 的Android 術語（裝置記憶體中的一個單獨分區，用於保存基於Linux 的輕量級系統，該系統首先啟動並顯示引導程式選單，其中包含「備份」、「擦除快取」、「恢復出廠設定」等可用工具）載入自訂 ROM' 等）。原始 OEM 復原不允許刷新自訂 ROM 或啟動自訂作業系統。
該專案似乎成熟、結構良好、維護積極，整體給人留下了一個有價值的全球開源專案的印象。支援的設備和供應商的數量非常多卓越。當然，我更願意使用由手機供應商維護和認可並從他們的官方網站（在我的例子中是華碩）下載的恢復版本。
註1：安裝 TWRP 並獲取有關 SDK 工具的更多資訊後，我意識到可以在不安裝自訂恢復的情況下刷新自訂 ROM（透過利用 SDK 平台工具包中的 adb 和 fastboot 工具）。
筆記2：每個型號的安裝過程都有詳細記錄。我使用“快速啟動安裝方法”。方法簡要說明（請參閱 TWRP 網站上與您的裝置相關的頁面）： 1) 安裝 Android SDK 工具（您只需要 platform-tools 套件中的 adb 和 fastboot 元件），2) 啟動「開發者模式」透過在“設定”>“關於”選單中的“內部版本號”行上點擊7 次，3) 在“設定”>“開發者選項”中啟用“USB 偵錯”，4) 透過USB 連接到您的PC， 5) 在您的PC 上，您可以檢查透過傳遞命令來連接設備adb devices，6) 運行adb reboot bootloader以進入fastboot 模式，7) 將從TWRP 網站下載並重新命名為「twrp.img」的正確映像檔放入包含adb 和fastboot 二進位檔案的資料夾中（通常為「platform-tools」資料夾） ), 8) 運行fastboot flash recovery twrp.img。就我而言，儘管 adb 報告了錯誤，但圖像已成功刷新FAILED (remote: Permission denied), 9) 運行fastboot reboot。您也可以從 TWRP 選單重新啟動裝置。重要的是讓 TWRP 修補您的庫存 ROM（與 Android 作業系統分區），以防止它擦除 TWRP 並在啟動後將其替換為庫存恢復。否則您將不得不重複該過程。是的，這太可怕了，因此步驟#1。
6）深入了解AOSP官方文檔
在失去了使用 Android 作業系統黑盒方法來實現目標的希望後，我開始回顧有關 Android 作業系統架構和支援設備的要求的一般部分。
好圖（建築）：
引導程式和安全資訊：
主要結論：Android 確實引入了有用的作業系統功能，可以在具有寬鬆硬體標準的各種專有（快速消費品世界）裝置上運行精簡的 Linux 核心。主流 Linux 可以而且可能應該採用的最有用的功能之一是 HAL 抽象層，允許以合理的方式處理大量的驅動程式。模組化內核將內核分為與 SoC 相關的部分和與主機板相關的部分，省電功能和安全功能也很引人注目。
好消息：Linux 核心開發人員和一些發行版供應商非常了解所有這些好的部分，並正在盡最大努力引入相應的變更。官方統計（見圖2）相應的 AOSP 文檔部分）顯示了 AOSP 程式碼和主流 Linux 之間收斂的良好證據。融合對雙方（AOSP 和 Linux 社群）都會產生明確的正面經濟影響。當談到谷歌和硬體生產商等保護其投資的利益相關者時，他們似乎朝著相反的方向發展。谷歌保護他們對生態系統和用戶群的投資，硬體生產商保護他們對開發和生產高端硬體的投資。這兩個力之間的摩擦力產生某種正向量。在我看來，Google和硬體生產商之間應該達成某種協議，以明智的方式規範這種摩擦。例如，硬體生產商可能會延遲將其特定於主機板的驅動程式 blob 提交到 Linux 核心中，例如 2-3 年（對於特定於 SoC 的驅動程式 blob，這個期限可能應該更短）。這將向 Google 和 AOSP 開發者保證，Android 生態系統會從市場上獲得所有精華（所有新的現代高階硬體設備購買、廣告收入、來自高階用戶的付費軟體和服務）。 2-3 年後，透過將驅動程式 blob 提交到 Linux 中，裝置（不再被視為高端）將免費發布（最高級的硬體供應商當然更願意提交原始程式碼）。該期限的長度非常接近硬體供應商為大多數設備設定的通常保固期以及這些供應商分發的官方 Android 更新（包括安全更新）的期限。很公平。
壞消息：談判這樣的交易似乎真的很難（以下簡稱「交易」）以明智而明確的方式。主要問題在於其全球性。考慮可能的法律考慮因素（各個司法管轄區的反壟斷法、跨境稅務問題等）、硬體供應商（OEM、ODM、SoC 生產商等）的數量以及涉及的其他利益相關者（Google、AOSP、 Android）開發人員、Linux、Linux 發行版供應商（伺服器、桌面和可能的行動裝置、其他基於 Linux 的專案、GNU、FSF 等，直至最終用戶）。缺乏協議肯定會減緩 Linux 和 AOSP 之間的融合，這是我們（用戶）共同的遺憾。從硬體的角度來看，幾年前，當主流 [多核心 x86 CPU / > 2Gb RAM / > 16Gb 快閃磁碟機] 裝置進入市場時，完全整合就成為可能。當硬體無法用於運行標準 Linux 核心（伺服器發行版，甚至桌面版）時，問題就很明顯。安裝程式不存在，刷新工具沒有得到供應商的正式支持，文件稀缺且分散。 2019 年 6 月，情況可能會好得多…
7) 下一步將是監控領先的轉換驅動社群和支援供應商所做的努力，以及硬體供應商和 AOSP / Google 為談判交易所採取的步驟。