RFC-0115：建構類型

摘要

本文說明 Fuchsia 的不同產品建構類型：eng、userdebug 和 user。

Fuchsia 中的建構類型是指產品設定的建構時間和執行階段設定：

• 建構時間設定包括套件、工具、簽署設定，以及定義系統行為的標記。

• 執行階段設定包括傳遞至執行中核心或軟體的標記，可根據建構類型調節執行階段行為。

本文件的目的，是正式核准已採用這些建構類型的 Fuchsia 產品所做出的設計決策。這也是 Fuchsia 平台中不同建構類型的正式定義。

提振精神

Fuchsia 定義了幾種建構類型，供開發人員、測試人員和最終使用者等不同使用者使用。每個使用者群組都對執行中的 Fuchsia 系統行為有一定的期望。

特定建構類型會為不同用途 (例如開發或運送給最終使用者的產品) 編碼並保證特定 Fuchsia 系統行為。

此外，您可以根據產品建構類型做出建構時間決策，例如加入特定套件變化版本。如需詳細資訊和範例，請參閱「套件變種版本」一節。

因此，不同的建構類型可為 Fuchsia 平台及其使用者提供必要的彈性，支援 Fuchsia 產品的整個生命週期。

設計

本節將概略說明 Fuchsia 目前常見的建構類型慣例。並詳細說明各類型的不同屬性，以及適用的執行階段限制。

請注意，由於複雜性和實作成本，因此在定義的建構類型數量上也設有限制。詳情請參閱「缺點」一節。

為了滿足 Fuchsia 目前的需求，我們提供三種建構類型：

• user
• userdebug
• eng

如要進一步瞭解建構類型，請參閱下方的「定義」一節。

如要新增其他建構類型，您必須提出提案，並通過 RFC 程序，並獲得 Fuchsia Engineering Council (FEC) 的核准。

目標

設計的主要目標如下：

• 為建構類型制定正式的通用規則，以支援開發人員需求和最終產品出貨要求。
• 建構類型的實作方式應盡可能相似，以免產品行為出現額外的差異。
• 建構類型會根據相同的條件和週期發布及取得合格。

定義

user

user 建構類型適用於運送至最終使用者的正式版裝置。

對於 user 版本，平台會在執行階段強制執行最高安全性保證，並在建構期間只納入產品所需的元件。

userdebug

userdebug 建構類型的行為預設與 user 相同，但可支援其他偵錯和檢測行為。

userdebug 版本主要用於開發裝置，用於最終使用者產品測試和認證。

eng

eng 建構類型主要適用於開發人員和測試人員，並會啟動產品 工作階段所定義的完整產品體驗。

各種產品設定的 eng 版本可樹狀結構內使用，也可以做為預建系統映像檔，並與 Fuchsia SDK 搭配使用。

產品設定

建構類型定義為產品專屬設定。為了在各建構類型之間維持相似性，設定會繼承並納入 Fuchsia 的「核心」產品，並有選擇地新增或移除套件和設定。

建構類型關係可歸納如下：

圖 1：建構類型為產品設定。

注意：

• eng 建構類型會繼承 core，並可納入產品專屬的其他套件。

• user 建構類型會直接繼承 core，但會移除任何額外套件、偵錯功能和其他檢測屬性。

• userdebug 會繼承 user，兩者只有一點差異，即啟用偵錯和檢測所需的額外功能。

• userdebug 和 user 之間的反向繼承功能可確保對 user 所做的任何變更 (適用於最終使用者產品)，會自動反映在 userdebug 版本中。

• 這項設計大致反映產品週期，其中 eng 是定義的第一個產品設定，建立在 core Fuchsia 產品之上。接著，當產品進入生命週期的後半段時，就會定義 userdebug 和 user，以反映這些用途和需求。

實作

以下章節將根據平台的主要領域，說明各個建構類型的實作細節。

斷言

Zircon 是 Fuchsia 的核心平台，由核心和一小組使用者空間服務、驅動程式和程式庫組成。

整個程式碼庫中會使用多種類似斷言的機制。您可以根據建構類型啟用或停用核心和使用者模式斷言。舉例來說，ZX_ASSERT 一律會為所有建構類型啟用，且必須以較低的價格提供，以免影響效能。

在另一個範例中，assert_level 在 eng 版本中為 2，並啟用所有斷言，但在 userdebug 和 user 版本中為 0，這會停用標準 C assert() 和 ZX_DEBUG_ASSERT。

下表概略說明核心中的斷言：

復原分割區

Fuchsia 終端使用者產品會使用 A/B/R 更新和復原方案。

總而言之，系統會透過無線 (OTA) 機制更新，並利用 A/B 更新方案，其中包含兩個系統副本(一個處於活動狀態，另一個處於非活動狀態)。這樣可確保系統在更新失敗時有備用方案。不過，如果備用系統無法啟動，系統會使用儲存在復原分區中的復原映像檔，嘗試復原系統。

每項產品都可以定義自己的復原映像檔。根據預設，在 eng 版本中會使用 zedboot。由於 zedboot 用於鋪設 Fuchsia 系統，因此會提供偵錯埠和其他復原系統的設施。

在 userdebug 和 user 中，系統會使用不同的復原映像檔，該映像檔會盡可能減少復原作業，並符合終端使用者產品的安全性規定。

套件和更新

套件自動更新

在 eng 建構類型中，auto_update_packages 預設為啟用。因此，在解析元件 (即透過執行元件) 時，系統會先透過 fuchsia.pkg.PackageResolver 嘗試更新元件的套件。

在日常開發作業中，這項功能可確保系統一律執行開發人員環境中的最新元件。

對於 userdebug 和 user 版本，這項功能已停用。您必須透過系統更新來變更元件和套件，這項作業會變更 base 系統中的套件，並觸發重新啟動。

套件變化版本

套件變種可用來指定套件的 eng 變種，然後再納入元件的 eng 變種。接著，套件會納入定義 eng 建構類型的產品設定。

例如：

package_flavor_selections += [
  {
    name = "my_component_pkg"
    flavor = "eng"
  },
]

同樣地，產品的 user 版本也包含套件的 user 變種版本。

系統更新

Fuchsia 會使用無線更新 (OTA) 機制執行系統更新。有兩個進入點，omaha-client 或 system-update-checker 元件：

Omaha 設定定義了用於執行系統更新的伺服器端設定，適合 userdebug 和 user 等使用者版本。

Omaha 設定包含儲存在 VBMeta 中的資訊，可確保在執行前驗證軟體的完整信任根。

套件組合、可執行元件和許可清單

Fuchsia 電路板和產品定義會擴充三個依附元件清單：Base、Cache 和 Universe。因此，在這些集合中定義的套件會決定這些套件在 Fuchsia 中的管理方式。

舉例來說，您只能透過系統 OTA 更新來變更 base 組合中的套件。因此，需要重新啟動系統。

由於 universe 集合可存取整個 Fuchsia 軟體集合，因此在 user 版本中不允許使用。

許可清單是一種政策，可決定哪些元件可以執行 (根據元件網址)，或哪些元件可以在執行階段存取特定服務。這項功能可用於確保 user 版本不會執行 eng 版本的開發元件或服務。

舉另一個例子來說，userdebug 版本允許執行一組有限的工具來檢查系統，例如 iquery，以便檢查執行中元件的屬性。

在 user 中，系統只允許執行產品所需的軟體。在目前的設計中，這項軟體僅限於 base 組合中包含的內容。

軟體來源

Fuchsia 軟體會透過軟體存放區中代管的套件提供。這些軟體來源必須為 Fuchsia 所知，並透過信任鏈進行密碼編譯驗證。

針對 eng 版本，系統在執行階段可新增的軟體來源沒有任何限制。

針對 userdebug 版本，只有在目標系統透過直接介面連線至開發人員的主機工作站時，才能新增軟體來源。

user 版本中的軟體來源是固定且無法修改的。

偵錯、記錄和 Shell

eng 版本可讓您完全存取 Fuchsia 系統，並提供所有偵錯埠和記錄。user 版本會限制所有存取權和記錄，而 userdebug 則會只針對偵錯目的啟用有限的存取權。

當機回報

fuchsia.feedback API 提供可用的當機回報服務。根據預設，系統會停用 eng 版本的當機上傳功能。對於 user 和 userdebug 版本，您必須明確提供使用者同意聲明，才能啟用當機報告上傳功能。

根據預設，系統仍會擷取當機報告並儲存在所有版本的本機當機報告資料庫中。

當機上傳內容包含系統和核心記錄檔案，以及元件檢查資料，可協助進行問題分類。這些資料檔案可能含有個人識別資訊 (PII)，並會在上傳前進行清除。

遙測

Fuchsia 平台提供記錄、收集及分析指標的服務。這項服務由 fuchsia.metrics 提供。Cobalt 的兩大支柱是保護使用者隱私權，以及提供高品質的匯總指標，以滿足系統和元件軟體開發人員的需求。

已驗證的執行作業

經過驗證的執行作業是 Fuchsia 安全性設計的核心，可確保所有執行的程式碼皆可信賴。可信度會透過遞迴方式驗證雜湊，並驗證可信實體的數位簽章，從不可變動的信任錨點開始。

驗證開機程序

驗證開機程序是驗證執行階段，系統啟動載入程式會驗證 Fuchsia zbi 是否可供系統啟動載入程式執行。

本機版本 (無論是 eng、userdebug 還是 user) 都會使用樹狀結構內的開發金鑰，而用於發布的版本則會由從安全金鑰管理服務取得的更安全金鑰簽署。

預先建構的系統映像檔

預先建構的 eng 映像檔可在 Fuchsia SDK 中使用，而 userdebug 和 user 版本則可直接從 Fuchsia Global Integration 建構工具下載。

建構時間最佳化

Fuchsia 平台的一般建構最佳化標記在所有建構類型中都維持一致，以便在各建構中保持一致。

在 eng 版本中，is_debug 會設為 true，而 true 會將預設旗標設為 debug，而不是 user 和 userdebug 版本中設定的 speed。這些旗標會在全域 BUILD.gn 檔案的各種設定中攜帶及使用。

針對元件，eng 套件變種可納入使用特殊標記編譯的元件。舉例來說，開發人員的建構作業和機器人設定通常會啟用 DCHECK 斷言，以便找出 C++ 元件中的意外問題。

成效

我們瞭解，與 userdebug 版本相比，eng 版本可能會導致效能處罰，但實際處罰程度會因產品和主機板類型而異。主要影響來自在平台中啟用額外的斷言。這項功能會使用 /zircon/system/ulib/perftest 進行測試。

在元件中，如果 eng 變種版本啟用 DCHECK，在基準測試和測試期間大量使用這些元件時，也會對效能造成重大影響。

userdebug 和 user 版本之間的效能差異很小。在效能基準測試時，請優先使用 userdebug 版本，而非 eng 版本。這種做法有缺點，請參閱下方的「缺點」一節。

安全性考量

在設計 Fuchsia 建構類型時，我們非常重視安全性影響。我們會在整個過程中採用下列方法，為所有使用者提供最高等級的安全保證：

• 利用經過驗證的執行作業，從啟動作業建立完整的驗證信任鏈結，並使用加密簽章的獨立簽署金鑰。

• 在元件架構中使用許可清單安全性政策，確保只解析及執行允許的元件。

• 只包含適用於使用者建構作業的必要套件和元件。

• 在使用者版本中停用所有存取端口和設施。

隱私權注意事項

在設計 Fuchsia 建構類型時，我們也非常重視隱私權考量。使用者端版本中的所有記錄都會經過清除，以便移除 PII，且必須取得使用者同意才能上傳當機記錄、記錄和指標。

說明文件

我們會在 Fuchsia > Concepts > Build System 中進一步說明建構類型，以便您在 Fuchsia 中為產品套用不同屬性和行為時，能參考標準參考資料。

測試

模擬器

如要測試不同建構類型的行為，最簡單且最直接的方法就是利用 Fuchsia Emulator。

開發人員可以使用模擬器模擬建構類型，比較及測試平台和應用程式的不同行為。缺點是，目前無法在模擬器環境中測試系統的特定部分，例如系統更新或驗證開機屬性。

發布程序

Fuchsia 會運用 CI (持續整合) 和 CQ (提交佇列) 管道，確保在 CL (變更清單) 上線前，以及在 CL 合併時的最終整合期間，建構並測試程式碼變更。

• CQ 管道會在 CL 上線前，針對不同的產品設定和環境建構及測試 CL。

• 在不同的產品設定中，CI 管道會建構及測試已在相同整合修訂版本中檢查的程式碼。

由於建構類型也以產品設定的形式實作，因此所有建構類型設定都會透過相同的 CI/CQ 管道建構、測試及發布。

請注意，CI/CQ 只會測試 eng 建構類型產品設定。不過，user 和 userdebug 仍是持續建構程序的一部分。

設施

在 eng 和 userdebug 版本中設定的universe 中，可使用測試架構和設施。這些服務並未預設啟用，但在執行階段可列入允許清單，以便解析及執行。

對於 user 版本，安全性政策不會啟用或允許測試設施。

舉例來說，Fuchsia 有用於端對端測試的 SL4F 架構，以及用於元件架構測試的 test_runner。

如要進行自動化測試，可以使用上述架構。但如果需要額外的套件或工具，建議使用 eng 版本。

缺點、替代方案和未知事項

本 RFC 中記錄的設計已實作，並反映 Fuchsia 產品建構類型的目前狀態。

透過利用產品設定來實作建構類型，即可利用及重複使用現有的實作項目。主要缺點是這種做法缺乏擴充性和彈性。舉例來說，每項新產品都必須至少有三個產品設定，且與三種建構類型相符。這種做法會產生成本，因為實作內容會備援，而 Fuchsia 基礎架構中需要額外的資源，才能為這些新設定啟動建構工具。

其他缺點包括測試 userdebug 版本。由於 userdebug 版本包含特定版本的套件、不同的系統更新設定，且不會啟用偵錯標記，因此非常適合執行端對端測試。但由於安全性限制，無法在官方 userdebug 版本中執行 SL4F。

您也可以改用獨立系統組合，這項工具可修改已組合的映像檔，並用於組合可存取測試架構且限制較少的本機 userdebug 版本。

日後，我們應採用更具彈性的做法，讓 eng、userdebug 和 user 建構類型設定檔可套用至不同的產品設定。這樣一來，就能避免新產品需要多個產品設定來配合建構類型的線性縮放問題。

另外值得一提的是，目前的實作方式會混合產品和平台，這並非 Fuchsia 平台的長期目標。如前所述，建議您日後考慮採用更靈活的設計。

既有技術與參考資料

Android 作業系統：

• 定義 eng、userdebug 和 user 版本。
• 發布指南，說明修改 userdebug 版本的最佳做法。