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