| RFC-0115：建構類型 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 產品建構類型的標準定義。 |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2021-07-06 |
| 審查日期 (年/月) | 2021-07-21 |
摘要
本文件說明 Fuchsia 適用的不同產品建構類型：eng、userdebug 和 user。
Fuchsia 中的建構類型是指產品設定的建構時間和執行階段設定：
建構時間設定包括用於定義系統行為的套件、工具、簽署設定和標記。
執行階段設定包含傳送至執行中核心的標記，或根據建構類型修改執行階段行為的軟體。
本文件旨在針對已使用這些建構類型的 Fuchsia 產品，正式製定相應的設計決策。這也能做為 Fuchsia 平台中不同建構類型的正式定義。
提振精神
Fuchsia 定義了幾種建構類型供各種使用者使用，包括開發人員、測試人員和使用者。每個使用者群組對執行中的 Fuchsia 系統行為都有特定期望。
特定建構類型可以編碼並保證不同 Fuchsia 系統行為，以因應不同的用途，例如開發或寄送給使用者的產品。
此外，也可以根據產品建構類型決定建構時間，例如納入特定的套件變種版本。如需詳細資訊和範例，請參閱「套件口味」一節。
因此，不同的建構類型可為 Fuchsia 平台及其使用者提供支援 Fuchsia 產品完整生命週期所需的彈性。
設計
本節將概略說明 CSS 上建構類型目前的常見慣例。並詳細說明每種類型的不同屬性，以及執行階段限制 (如適用)。
此外，對於因為複雜性和實作成本而定義的建構類型數量，系統也會留意限制。詳情請參閱「缺點」一節。
基於 Fuchsia 目前要求的目的，有三種建構類型：
useruserdebugeng
下列定義一節將進一步說明建構類型。
使用其他建構類型將需要通過 RFC 程序並經過 Fuchsia 工程委員會 (FEC) 核准的提案。
目標
設計的主要目標如下：
- 為支援開發人員需求的建構類型擬定通用慣例，以及最終產品運送規定。
- 建構類型會盡可能相似，避免產品行為受到其他差異。
- 建構類型會發布，且具備相同的條件和頻率。
定義
user
user 建構類型用於推送給使用者的正式版裝置。
對於 user 版本，平台會在執行階段強制執行最高安全性保證，且僅在建構期間納入產品的必要元件。
userdebug
根據預設，userdebug 建構類型的行為與 user 相同，但允許執行其他偵錯和檢測行為。
userdebug 版本主要用於開發裝置，用來測試及評估使用者產品。
eng
eng 建構類型主要用於開發人員和測試人員，並可啟動以產品「工作階段」定義的完整產品體驗。
各種產品設定的 eng 版本可樹狀結構內找到，也可做為 Fuchsia SDK 的預建系統映像檔。
產品設定
建構類型已定義為產品專屬的設定。為了在各建構類型之間維持相似性，這些設定會繼承 Fuchsia 的 core 產品，並選擇性新增或移除套件和設定。
建構類型關係可總結如下：
圖 1：建構類型做為產品設定。
注意事項：
eng 建構類型會繼承 core，可以包含產品專屬的其他套件。
user 建構類型直接沿用 core，但會移除所有額外套件、偵錯功能和其他檢測屬性。
然後，userdebug 會繼承 user，在啟用偵錯與檢測所需的額外功能則稍有不同。
userdebug 和 user 之間的反向繼承可確保使用者產品必要的任何 user 變更都會自動反映在 userdebug 版本中。
設計大致反映了產品週期，
eng是建構於coreFuchsia 產品之上的第一個產品設定。接著，當產品沿著生命週期進展時，定義userdebug和user以反映這些用途和需求。
實作
下一節將根據平台的主要部分，列出每種建構類型的實作詳細資料。
斷言
Zircon 是支援 Fuchsia 的核心平台，由核心和一小組使用者空間服務、驅動程式和程式庫組成。
在整個程式碼集中，有多種不同斷言的機制。核心和使用者模式斷言會視建構類型啟用或停用。舉例來說，所有建構類型的 ZX_ASSERT 一律為啟用狀態，成本較低，以免影響效能。
在另一個範例中，assert_level 是 eng 建構作業中的 2，且在 userdebug 和 user 版本中處於 0 時啟用所有斷言，這會停用標準 C assert() 和 ZX_DEBUG_ASSERT。
下表概略說明核心中的斷言：
| 屬性 | eng | 使用者偵錯、使用者 |
|---|---|---|
| 評估 | 開啟 | 開啟 |
| 偵錯 | 開啟 | 關閉 |
| assert() | 開啟 | 關閉 |
復原分區
Fuchsia 使用者產品採用 A/B/R 更新和復原配置。
簡單來說，透過無線更新 (OTA) 機制進行系統更新，採用 A/B 更新配置，其中包含兩個系統副本(一個有效，另一種則未啟用)。這樣可以確保在更新失敗時有備用項。但是，如果無法啟動備用方案，系統會使用復原分區中儲存的復原映像檔嘗試復原系統。
每項產品都可以定義自己的復原映像檔。根據預設，在 eng 建構作業中使用 zedboot。因為 zedboot 用於貼上 Fuchsia 系統，它提供偵錯連接埠及其他設施來復原系統。
在 userdebug 和 user 中，使用的是最小且符合使用者產品安全性需求的復原映像檔。
| 屬性 | eng | 使用者偵錯、使用者 |
|---|---|---|
| 復原 (R) | Zedboot | 最小復原映像檔 |
套件與更新
套件自動更新
在 eng 建構類型中，auto_update_packages 預設為啟用。因此，在解析元件時 (即透過執行元件)，嘗試更新元件套件時會先透過 fuchsia.pkg.PackageResolver 進行。
在日常開發作業中，此設施非常實用，可確保系統一律執行開發人員環境中的最新元件。
userdebug 和 user 建構了這項功能。如要對元件和套件進行任何變更，都必須透過系統更新完成，這會變更 base 系統中的套件，並觸發重新啟動作業。
| 屬性 | eng | 使用者偵錯、使用者 |
|---|---|---|
| auto_update_packages | true | false |
調味品組
套件變種版本可用來指定套件的 eng 變種版本，其中包含元件的 eng 變種版本。接著，該套件包含在定義 eng 建構類型的產品設定中。
例如：
package_flavor_selections += [
{
name = "my_component_pkg"
flavor = "eng"
},
]
同樣地，產品的 user 版本中包含套件的 user 變種版本。
系統更新
Fuchsia 使用無線更新 (OTA) 機制來運作系統更新。有兩個進入點：omaha-client 或 system-update-checker 元件：
| 屬性 | eng | 使用者偵錯、使用者 |
|---|---|---|
| 汽車系統 OTA | false | true |
| 更新檢查工具 | system-update-checker |
omaha-client |
| Omaha 設定 | 不適用 | 定義 |
Omaha Configuration 會定義用於執行系統更新的伺服器端設定，適用於 userdebug 和 user 等使用者建構作業。
Omaha 設定包含儲存在 VBMeta 中的資訊，確保軟體在執行前會驗證完整的信任根。
套件集、可執行的元件和許可清單
Fuchsia 主機板和產品定義擴增三種依附元件清單：Base、Cache 和 Universe。因此，這些組合中定義的套件決定了在 Fuchsia 中管理這些套件的方式。
舉例來說，如要對 base 組合中的套件做出變更，只能透過系統 OTA 更新程序。因此需要重新啟動系統。
universe 集允許存取整個 Fuchsia 軟體集，因此不允許在 user 版本中存取。
| 屬性 | eng | 使用者偵錯 | 使用者 |
|---|---|---|---|
| 可用的組合 | 基底, 快取, 宇宙 | 基底, 快取, 宇宙 | 底座 |
| 許可清單 | 允許所有套件 | 基礎 + 許可清單 | 僅限基數 |
「許可清單」是一種政策，用來決定哪些元件可以執行 (根據元件網址)，或哪些元件可在執行階段存取特定服務。舉例來說，這有助於確保 user 建構不會執行 eng 建構專用的開發元件或服務。
在另一個範例中，userdebug 建構作業可讓少數工具執行檢查系統 (例如 iquery)，藉此檢查執行中元件的屬性。
在 user 中，系統只會允許執行產品所需的軟體。在目前的設計中，這個軟體僅限於 base 組合所含的內容。
軟體來源
Fuchsia 軟體是透過軟體存放區託管的套件來提供。這些軟體來源必須由 Fuchsia 已知，並透過信任鏈加密驗證。
在 eng 版本中，哪些軟體來源可在執行階段新增至系統。
針對 userdebug 版本，只有在目標系統透過開發人員主機工作站的直接介面連線時，才能新增軟體來源。
user 版本中的軟體來源固定且無法修改。
偵錯、記錄和殼層
eng 版本可讓使用者完整存取 Fuchsia 系統，並提供所有偵錯通訊埠和記錄檔。user 版本會限制所有存取和記錄，而 userdebug 希望僅針對偵錯目的啟用有限存取權。
| 屬性 | eng | 使用者偵錯 | 使用者 |
|---|---|---|---|
| SSH | 已啟用 | 已啟用 | 已停用 |
| serial | 已啟用 | r/o 系統啟動載入程式和核心 | 系統啟動載入程式中的 R/o |
| 偵錯代理程式 | 已啟用 | 已停用 | 已停用 |
| k 指令 | 已啟用 | 已停用 | 已停用 |
| ffx 執行階段 | 已啟用 | 已啟用 | 已停用 |
當機回報
您可以透過 fuchsia.feedback
API 使用並提供當機回報服務。根據預設，eng 建構作業會停用當機上傳功能。針對 user 和 userdebug 版本，您必須明確提供使用者同意聲明，才能啟用當機報告上傳功能。
根據預設，系統仍會擷取當機報告，並儲存在本機當機報告資料庫中。
| 屬性 | eng | 使用者偵錯、使用者 |
|---|---|---|
| 當機回報 | 已啟用 | 已啟用 |
| 上傳異常終止 | 已停用 | 允許徵詢使用者同意 |
當機上傳包括系統和核心記錄檔，以及元件檢查資料，以協助分類問題。這些資料檔案可包含個人識別資訊 (PII)，會在上傳前模糊處理。
遙測
Fuchsia 平台提供記錄、收集和分析指標的服務。這項服務是由 fuchsia.metrics 提供。Cobalt 的兩大要素是保護使用者隱私，並提供高品質的匯總指標，滿足系統和元件軟體開發人員的需求。
| 屬性 | eng | 使用者偵錯、使用者 |
|---|---|---|
| 指標收集 | 已啟用 | 已啟用 |
| 上傳指標 | 已啟用 | 允許徵詢使用者同意 |
通過驗證的執行作業
已驗證的執行是 Fuchsia 安全性的核心設計，可確保所有執行的程式碼值得信賴。系統會採取不可變更的信任錨點，以遞迴方式驗證雜湊值和可驗證實體數位簽章，以遞迴方式宣告可信度。
驗證開機程序
驗證開機程序是驗證執行的階段，系統啟動載入程式會驗證 Fuchsia zbi 是否可由系統啟動載入程式執行。
本機建構作業 (無論是 eng、userdebug 或 user) 會使用樹狀結構內的開發金鑰，而針對發布產生的建構作業則是由從安全金鑰管理服務取得的更安全金鑰簽署。
預先建立的系統映像檔
您可在 Fuchsia SDK 中使用預先建構的 eng 映像檔，而 userdebug 和 user 版本可以直接從 Fuchsia 全球整合建構工具下載。
建構時間最佳化
針對 Fuchsia 平台，一般建構最佳化標記在所有建構類型中都會保持相同，以維持各建構作業的一致性。
在 eng 建構作業中，is_debug 會設為 true，該將預設標記設為 debug，而非 speed 於 user 和 userdebug 建構作業中設定。這些旗標會保留並用於全域 BUILD.gn 檔案中的各種設定。
對元件而言，eng 套件變種版本可包含使用特殊標記編譯的元件。舉例來說，DCHECK 斷言通常會在開發人員版本和機器人設定中啟用，協助找出 C++ 元件中的非預期問題。
效能
我們瞭解比起 userdebug 版本，eng 建構可能會導致效能降低，但實際懲罰方式會因產品和板型類型而異。其中的主要影響是啟用平台中的額外斷言。這會使用 /zircon/system/ulib/perftest 進行測試。
在元件中，如果在基準測試和測試期間大量使用這些元件，啟用 DCHECK 的 eng 變種版本也會對效能造成顯著影響。
userdebug 和 user 建構在效能上幾乎沒有差異。進行效能基準測試時，應使用 userdebug 版本，而非 eng 版本。此方法有一些缺點，詳情請參閱下方的「缺點」一節。
安全性考量
Fuchsia 建構類型設計時，安全性方面受到了嚴重考量。可以在所有情況下使用下列方法，對所有使用者強制執行最高等級的安全保證：
利用已驗證的執行作業，從開機建立完整的驗證信任鏈，為加密編譯簽名建立個別的簽署金鑰。
善用元件架構中的許可清單安全性政策，確保只有允許的元件會被解析並執行。
僅包含使用者建構作業所需的套件和元件。
停用使用者版本中的所有存取通訊埠和設施。
隱私權注意事項
在 Fuchsia 建構類型設計中，隱私權考量也成為嚴格考慮的因素。使用者版本中的所有記錄都會遭到 PII 封鎖，且「必須」提供使用者同意聲明，才能上傳當機、記錄和指標。
說明文件
我們將在「Fuchsia」>「Concepts」>「Build System」中進一步說明建構類型，因此您可以找到適用於 Fuchsia 產品的不同屬性和行為的標準參考資料。
測試
Android Emulator
如要測試不同建構類型的行為，最簡單的方法是使用 Fuchsia 模擬器。
使用模擬器模擬建構類型可讓開發人員比較及測試平台和應用程式的不同行為。缺點是目前無法在模擬器環境中測試系統的特定區域，例如系統更新或驗證開機屬性。
發布程序
Fuchsia 利用持續整合 (持續整合) 和 CQ (修訂佇列) 管道，確保在 CL (變更清單) 抵達前完成程式碼變更，以及在 CL 合併時完成最終整合期間才進行程式碼變更。
CQ 管道在 CL 實現前，在不同的產品設定和環境中建構並測試 CL。
CI 管道、建構及測試在相同整合修訂版本中針對不同產品設定進行檢查的程式碼。
由於建構類型也會做為產品設定實作，因此所有建構類型設定都會透過相同的 CI/CQ 管道同時進行建構、測試和發布。
請注意，只有 eng 建構類型產品設定會在 CI/CQ 中進行測試。不過，user 和 userdebug 仍在持續建構程序中。
設施
eng 和 userdebug 版本中的「宇宙」集有測試架構和設施。根據預設，系統不會啟用這些服務，但會加入許可清單，以便在執行階段進行解析和執行作業。
針對 user 版本，安全性政策未啟用或允許測試設施。
舉例來說，Fuchsia 提供用於端對端測試的 SL4F 架構，以及用於元件架構測試的 test_runner。
對於自動化測試用途，您可以使用上述架構。不過，如果需要其他套件或其他工具，建議您使用 eng 版本。
缺點、替代方案和未知
本 RFC 中記載的設計已實作，反映 Fuchsia 產品建構類型的目前狀態。
透過產品設定實作建構類型，您可以將現有的實作用於重複使用及重複使用。主要的缺點是此方法缺乏擴充性和彈性。舉例來說，每項新產品都需要至少三個與三種建構類型相符的產品設定。在實作的備援功能中，也會需要額外資源來啟動 Fuchsia 基礎架構所需的額外資源，進而啟動這些新設定的建構工具。
其他缺點包括測試 userdebug 版本。由於 userdebug 版本包含特定套件變種版本、不同的系統更新設定，且未啟用偵錯標記，因此您想要執行端對端測試。不過基於安全性限制，您無法在官方的 userdebug 版本中執行 SL4F。
獨立系統組件除了提供修改組合映像檔的功能，還可用來組合本機 userdebug 版本，這些版本允許存取測試架構且限制較少。
日後，我們應使用更可擴充的方法，以便將 eng、userdebug 和 user 建構類型設定檔套用至不同的產品設定。這可避免發生線性資源調度問題。新產品需要多項產品設定才能因應建構類型，
值得注意的是，目前的實作方式結合了產品和平台，並不是 Fuchsia 平台的長期需求。如先前所述，建議您日後再考慮更具彈性的設計。
先前的圖片和參考資料
Android 作業系統：