本指南說明 Google 建議的最佳做法，協助您套用 Android Compatibility Test Suite (CTS) 評估的安全修補程式。這項計畫適用於 Android 相容 OEM 設備的製造商，這些設備的支援時間將超過三年，例如車輛、電視、機上盒和家用電器。本指南不適用於一般使用者 (例如車主)。
特別銘謝和免責事項
本指南不具法律或合約效力，無法約束 Google 或其他製造商，也不會成為一組要求。本指南僅為教學輔助工具，說明建議做法。
意見回饋
本指南並非完整內容，我們預計會進行更多修訂。請將意見回饋傳送至 manufacturers-guide-android@googlegroups.com。
詞彙
| 字詞 | 定義 |
|---|---|
| ACC | Android 相容性承諾。先前稱為 Android 防碎片化協議 (AFA)。 |
| Android 開放原始碼計劃 | Android 開放原始碼計畫 |
| ASB | Android 安全性公告 |
| BSP | 開發板支援套件 |
| CDD | 相容性定義文件 |
| CTS | Compatibility Test Suite |
| FOTA | 韌體無線更新 |
| GPS | 全球定位系統 |
| MISRA | 汽車產業軟體可靠性協會 |
| NIST | 美國國家標準暨技術研究院 |
| OBD | 車載診斷 (OBD-II 在功能和標準化方面都比 OBD-I 更進步) |
| 原始設備製造商 (OEM) | 原始設備製造商 |
| 作業系統 | 作業系統 |
| SEI | 軟體工程研究所 |
| SoC | 晶片系統 |
| SOP | 開始製作 |
| SPL | 安全性修補程式等級 |
| TPMS | 胎壓偵測系統 |
關於 Android 作業系統
Android 是以 Linux 為基礎的開放原始碼完整軟體堆疊，適用於各種裝置和板型規格。自 2008 年首次發布以來，Android 已成為最受歡迎的作業系統 (OS)，全球有超過 14 億部裝置 (2016 年) 採用 Android。截至 2017 年 3 月，約有 67% 的裝置使用 Android 5.0 (Lollipop) 以上版本 (如需最新數據，請參閱 Android 資訊主頁)。雖然絕大多數裝置都是手機和平板電腦，但 Android 在智慧手錶、電視和車輛資訊娛樂 (IVI) 裝置的市占率也日益成長。
Google Play 商店提供的 Android 應用程式數量已達 220 萬以上 (2016 年)。Android 應用程式開發作業有 Android 相容性計畫做為後盾，該計畫透過相容性定義說明文件 (CDD) 定義一組需求，並透過相容性測試套件 (CTS) 提供測試工具。Android 相容性計畫可確保任何 Android 應用程式都能在支援應用程式所需功能的 Android 相容裝置上執行。
Google 會定期發布新版 OS、OS 安全性更新，以及發現的安全性弱點相關資訊。製造商應參閱 Android 安全性公告，瞭解這些更新是否適用於支援 Android OS 的產品。如要瞭解 Android 安全性、相容性和建構系統，請參閱下列內容：
關於連結的車輛 (標準長期產品)
自 1920 年代推出 AM 廣播後，車輛開始連網。從那時起，隨著監管機構和汽車製造商開始採用電子技術，以簡化診斷和維修程序 (例如 OBD-II 連接埠)、提升安全性 (例如 TPMS) 及達成燃油經濟性目標，外部實體和無線連線的數量也開始增加。下一波連線技術則推出駕駛人便利功能，例如遙控無鑰匙進入系統、車載資訊系統，以及藍牙、Wi-Fi 和智慧型手機投影等進階資訊娛樂功能。如今，整合式感應器和連線功能 (例如 GPS) 可支援安全和半自動駕駛系統。
車輛連線數量越多，潛在的車輛受攻擊面就越大。連線會帶來與消費性電子產品類似的一系列網路安全疑慮。不過，重新啟動、每日修補程式更新和無法解釋的行為是消費性電子產品的常態，但對於車輛等具有安全關鍵系統的產品而言，這些行為並不一致。
製造商必須主動確保產品在現場持續維持安全狀態。簡而言之，製造商必須瞭解產品中已知的安全漏洞，並採取風險控管方法來解決這些問題。
確保長期安全
連網車輛通常會有一或多個電子控制單元 (ECU)，其中包含多個軟體元件，例如作業系統、程式庫、公用程式等。製造商應追蹤這類元件，並透過主動分析找出已知的已發布安全漏洞，包括：
- 定期根據常見安全漏洞與弱點 (CVE) 資料庫評估產品。
- 收集與產品相關安全漏洞的情報。
- 安全性測試。
- 主動分析 Android 安全性公告。
OS 和安全性修補程式更新範例 (Android IVI)：
圖 1. 以下是車輛生命週期內的主要 OS 和安全性更新推出範例。
| # | 步驟 | 活動 |
|---|---|---|
|
① |
開發分支版本 | 製造商選取 Android 版本 (Android X)。在這個範例中，「Android X」會成為車輛出貨的基礎，而車輛出貨時間比初始量產開始 (SOP) 早兩年。 |
| ② | 首次發布 | 在 Android X 成為產品出貨時搭載的第一個 OS 版本前幾個月，安全性更新會取自 Android 安全性公告 (ASB)，以及製造商認為有價值的其他來源。y2 是 Android X 版本的第二個安全性公告，由製造商套用 (回溯移植) 至 Android X。這項更新會隨產品出貨，而生產時鐘會從 Android X.y2 的第 0 年開始計時。 在這個例子中，製造商決定不要出貨搭載較新 Android X+1 年度版本的裝置。出貨最新版本的原因包括新增功能、解決新的安全漏洞，以及/或出貨需要較新 Android 版本的 Google 或第三方服務。由於車輛開發和上市程序需要整合、測試及驗證變更，包括遵守所有法規和認證規定，因此沒有足夠時間，這是反對 在最新版本中出貨的原因。 |
| ③ | 完整 OS 更新 | SOP 後，製造商發布 Android X+2 OS 更新，也就是初始產品 (Android X0) 所用版本之後的兩個 Android 版本。ASB 安全性更新適用於 API 級別 (截至出貨日)，因此更新會在 SOP 後約 1.25 年發布為 X+2.y0。這項作業系統更新可能與現場產品相容，也可能不相容。如果是，可以建立計畫來更新已部署的車輛。 除非另有其他商業協議，否則是否要進行完整的 OS 更新，完全由製造商自行決定。 |
| ④ | 安全性更新 | 車輛生產兩年後，製造商會修補 Android X+2 OS。這項決定是根據製造商的風險評估結果做出。製造商選擇以第三個 ASB 安全性更新 (發布 X+2) 做為更新基礎。產品
獲得安全性更新後，現在採用 (X+2.y3) 作業系統 + Android 安全性修補程式等級。
雖然製造商可以從任何 ASB 中選取個別安全性修補程式，但必須修正公告中的所有必要問題，才能使用與公告相關聯的 Android 安全性修補程式等級 (SPL)，例如 2017-02-05。製造商有責任為支援的產品執行回溯移植和安全發布作業。 |
| ⑤ | 完整 OS 更新 | 重複步驟 3 (完整 OS 更新)，第二次完整 OS 更新會將產品升級至 Android X+4，此時車輛的生產生命週期已滿三年。製造商現在會根據產品中的硬體，以及更新 Android OS 為使用者帶來的優勢，來平衡新版 Android 的新硬體需求。製造商發布的更新未包含安全性更新，因此產品現在是 (X+4.y0) OS + Android 安全性修補程式等級。 在這個例子中，由於硬體限制，X+4 是這項產品最後一個 Android 主要版本，但車輛預計使用壽命超過 6 年，因此仍需要安全性支援。 |
| ⑥ | 安全性更新 | 重複步驟 4 (安全性更新)。製造商的任務是從較新版本的 Android (X+6) 取得 ASB 安全性更新，並將部分或所有更新移植回 Android X+4。製造商有責任合併、整合及執行更新 (或與第三方簽約)。此外，製造商應注意，Android 安全性公告不會涵蓋不再支援的 Android 版本安全問題。 |
| ⑦ | 安全性更新 | 車輛生產週期已達八年，自步驟 5 (完整 OS 更新) 的上次 OS 更新以來，已發布四個 Android 版本，且自指定 Android X 以來已達十年，因此對於 API 級別公開發布後超過三年的版本，管理及回溯移植安全性修補程式的負擔完全落在製造商身上。 |
安全性最佳做法
為降低安全漏洞風險，Google 建議並採用普遍接受的安全和軟體工程最佳做法，詳情請參閱「實作安全性」。
安全性指南
建議的安全做法包括：
- 使用最新版本的外部程式庫和開放原始碼元件。
- 請勿在 OS 的發布版本中加入侵入式偵錯功能。
- 移除未使用的功能 (減少不必要的攻擊面)。
- 遵循最低權限原則和其他 Android 應用程式開發最佳做法。
軟體開發指南
系統生命週期的安全軟體開發建議做法包括：
- 執行威脅模型建立作業，以評估及找出資產、威脅和潛在的緩解措施。
- 進行架構/設計審查，確保設計安全無虞。
- 定期進行程式碼審查，盡快找出反模式和錯誤。
- 設計、實作及執行高程式碼涵蓋率的單元測試，包括：
- 功能測試 (包括負面測試案例)
- 定期進行迴歸測試 (確保修正的錯誤不會再次出現)
- 模糊測試 (單元測試套件的一部分)
- 使用靜態原始碼分析工具 (scan-build、lint 等) 找出潛在問題。
- 使用動態原始碼分析工具 (例如 AddressSanitizer、UndefinedBehaviorSanitizer 和 FORTIFY_SOURCE (適用於原生元件))，在系統開發期間找出並減輕潛在問題。
- 制定軟體原始碼和發布設定/版本的管理策略。
- 制定軟體修補程式的產生和部署策略。
安全性回溯政策
Google 目前會針對發現及回報的安全漏洞，在API 級別公開發布後三年內，提供安全性反向移植的支援服務。有效支援包括：
- 接收並調查安全漏洞報告。
- 建立、測試及發布安全性更新。
- 定期發布安全性更新和安全性公告詳細資料。
- 根據既定準則進行嚴重程度評估。
API 級別公開發布三年後，Google 建議遵循下列準則：
- 如要為 API 發布後超過三年的舊版 OS 安全性更新提供回溯支援，請使用第三方 (例如 SoC 供應商或核心供應商)。
- 使用第三方，透過公開提供的 ASB 執行程式碼審查。ASB 會找出目前支援版本的安全漏洞，但製造商可能會使用提供的資訊，比較新發布的更新與先前的版本。這項資料可用於執行影響分析，並可能為 API 發布後超過三年的舊版 OS 產生類似修補程式。
- 在適當情況下，將安全性更新上傳至 Android 開放原始碼計畫 (AOSP)。
- 製造商必須協調處理供應商專屬程式碼 (例如專屬裝置專用程式碼) 的安全性更新。
- 製造商應加入 NDA Android 安全性公告合作夥伴搶先體驗通知群組 (須簽署開發人員保密協議等法律協議)。公告應包含：
- 公告事項
- 依修補程式等級列出的問題摘要，包括 CVE 和嚴重程度
- 適用的安全漏洞詳細資料
其他參考資料
如需安全編碼和軟體開發做法的操作說明，請參閱下列內容：
建議的產品做法
Google 鼓勵您採用下列建議做法。
一般發布指南
一般來說，建議使用最新版作業系統啟動任何連線產品，且製造商應嘗試使用最新版作業系統，再推出產品。雖然在測試和驗證前鎖定版本有助於提升穩定性，但製造商必須權衡舊版 OS 帶來的產品穩定性，以及新版 OS 較少已知安全漏洞和強化安全防護的優勢。
建議的指南包括：
- 由於車輛開發程序固有的開發前置時間較長，製造商可能需要使用 OS 版本 n-2 或更舊的版本推出產品。
- 針對每個發布的 Android OS 版本，透過無線 (OTA) 活動維持 Android 相容性。
- 實作支援 Android 韌體無線更新 (FOTA) 的產品，方便顧客快速更新。執行 FOTA 時，應採用程式碼簽署和產品與 IT 後端辦公室之間的 TLS 連線等安全最佳做法。
- 向 Android 安全性團隊提交自行發現的 Android 安全漏洞。
注意：Google 已在 Android 安全性公告中考量裝置類型或產業專屬通知。不過，由於 Google 不知道特定裝置 (車輛、電視、穿戴式裝置、手機等) 的核心、驅動程式或晶片組，因此無法以確定性的方式為任何裝置類型的安全性問題加上標籤。
產品週期指南
製造商應盡量在產品週期強化期間，使用最新 OS 版本或目前版本的安全性更新。更新作業可在定期產品更新期間執行，或用於解決品質和/或其他問題的修正程式。建議做法包括：
- 制定計畫，因應驅動程式、核心和通訊協定更新。
- 使用適合產業的方法，為已部署的車輛提供更新。
相容性定義說明文件 (CDD)
相容性定義說明文件 (CDD) 說明裝置必須符合哪些要求，才能視為 Android 相容裝置。CDD 是公開文件，所有人都能存取。您可以從 source.android.com 下載 Android 1.6 到最新版本的 CDD。
如要讓產品符合這些規定，基本步驟如下：
- 合作夥伴與 Google 簽署 Android 相容性承諾 (ACC)。接著，我們會指派技術解決方案顧問 (TSC) 做為指導。
- 合作夥伴完成產品 Android OS 版本的 CDD 審查。
- 合作夥伴執行並提交 CTS 結果 (如下所述)，直到結果符合 Android 相容性要求為止。
Compatibility Test Suite (CTS)
Compatibility Test Suite (CTS) 測試工具會驗證產品實作項目是否與 Android 相容，以及是否包含最新安全性修補程式。CTS 是公開的開放原始碼，所有人都能使用。您可以從 source.android.com 下載 Android 1.6 到最新版本的 CTS。
發布給大眾的每個 Android 軟體版本 (工廠安裝和現場更新映像檔)，都必須透過 CTS 結果證明 Android 相容性。舉例來說，如果裝置搭載 Android 7.1，在建立及測試發布意圖建構映像檔時，應參照 CDD 7.1 和 CTS 7.1 的最新對應版本。強烈建議製造商盡早且經常使用 CTS，找出並修正問題。
CTS 工作流程
CTS 工作流程包括設定測試環境、執行測試、解讀結果，以及瞭解 CTS 原始碼。以下指南旨在協助 CTS 使用者 (例如開發人員、製造商) 有效率地使用 CTS。
- 頻繁執行測試。CTS 是一項自動化工具，可整合至建構系統。頻繁執行 CTS 有助於在軟體效能降低或發生迴歸錯誤時，快速找出缺陷。
- 下載並檢查 CTS 原始碼。完整的 CTS 原始碼是開放原始碼軟體，任何人都可以下載及使用 (下載的原始碼完全可建構及執行)。如果裝置上的測試失敗，檢查原始碼的相關部分有助於找出原因。
- 取得最新版 CTS。新版 Android 可透過錯誤修正、改良項目和新測試更新 CTS。請經常查看 CTS 下載頁面，並視需要更新 CTS 計畫。製造商和 Google 應就產品發布時通過的 CTS 版本達成共識，因為 CTS 會持續更新，產品必須在某個時間點凍結。
通過 CTS
對於 Android 相容產品，Google 會確保裝置的 CTS 和 CTS 驗證器報告測試結果可接受。原則上，所有測試都必須通過。不過，如果測試失敗的原因並非裝置不符合 Android 相容性規定，則須通過 Google 審查。在這項程序期間：
- 製造商會向 Google 提供建議的 CTS 修補程式、修補程式驗證和正當理由，以證明論點。
- Google 會檢查提交的資料，如果接受，就會更新相關 CTS 測試，讓裝置在下一個 CTS 修訂版本中通過測試。
如果套用安全性修補程式後，CTS 測試突然失敗，製造商必須修改修補程式，確保不會破壞相容性，或是證明測試有誤並提供測試修正程式 (如上所述)。
CTS 仍開放測試修正的審查作業。舉例來說，Android 4.4 仍會接受修正 (請參閱 https://android-review.googlesource.com/c/platform/cts/+/273371)。
常見問題 (FAQ)
問：誰負責為特定 Android 實作項目套用安全性更新？
答：直接提供裝置的製造商須負責。這個實體不是 Google，Google 會在 Android 開放原始碼計畫中發布安全性更新，而非針對特定裝置 (例如車輛)。
問：Google 如何處理 Android 的安全性問題？
答：Google 會持續調查問題並開發可能的修正方式，然後在定期安全更新程序中，提供給所有支援的 API 級別。自 2015 年 8 月起，Google 定期發布公告和更新連結至 source.android.com，並在主要 OS 版本中發布安全性更新。另請參閱 安全後向移植政策。
問：如果製造商整合了 ASB 中的所有 AOSP 修補程式，但未整合同一公告中提及的 BSP 供應商修補程式，是否仍可提高安全性層級 (例如將對應的修補程式套用至 platform/build)？
答：如要宣告 Android 安全性修補程式等級 (SPL)，製造商必須解決 Android 安全性公告 (包括先前的公告) 中發布的所有必要問題，並對應至特定 Android SPL。舉例來說，如果製造商使用 2017 年 3 月安全性公告 (2017-03-01 SPL)，就表示已解決 2017 年 3 月公告中針對該 SPL 列出的所有必要問題，以及所有先前的更新 (包括所有先前 Android 安全性公告的裝置專屬更新，包括與 2017-02-05 SPL 相關的裝置專屬更新)。
問：如果製造商不同意 BSP 供應商提供的安全性更新，或是供應商未提供 ASB 規定的安全性更新，會發生什麼情況？
答：ASB 會說明安全漏洞 (以 CVE 清單列舉)，並經常提供相應的安全測試。目標是確保裝置不再出現所列的安全性漏洞，且能通過相關安全性測試。因此，問題並非在於採用 Google 或第三方供應商提供的安全性更新，而是製造商證明裝置不會受到 ASB 中 CVE 清單的影響。製造商可自由使用提供的安全性更新，或視裝置情況採用更合適的變更。
舉例來說，假設 Google 透過程式碼變更解決 Android 開放原始碼計畫安全漏洞，讓元件維持完整功能，並符合 CDD 規範。如果製造商判斷裝置不需要該元件，或 CDD (或相關認證測試) 未強制要求，製造商可以移除該元件，以減少日後的維修需求並縮小攻擊面。雖然製造商並未使用提供的安全性更新，但已確保裝置不會受到安全性公告中記錄的 CVE 影響。不過，如果製造商未採用建議的安全性更新，可能會錯誤解決問題、引發新的安全漏洞，或降低最終版本的效能。
雖然我們會與所有 SoC 合作夥伴合作，確保 ASB 中所有問題都能獲得修正，但我們建議製造商與 SoC 供應商簽訂裝置生命週期的服務協議。SoC 可能會比預期更早停止為晶片組提供服務，因此在選擇裝置晶片組前建立協議，是裝置發布程序的重要環節。
最後，如果無法直接取得或獨立建立 ASB 中記錄問題的修正程式，製造商可以維持先前的 Android SPL，並將新提供的修正程式新增至建構版本。不過，這種做法最終會導致建構認證問題 (因為 Android 會確保認證裝置提供最新的安全性修補程式等級)。Google 建議您事先與 SoC 合作，避免這種做法。
問：如果製造商判斷 ASB 項目不適用於其產品，是否仍須套用或修補該項目，才能符合其他 Google 規定或通過 CTS？
答：我們不會要求您採用修補程式，才能宣告 Android 安全性修補程式等級 (SPL)，但製造商必須證明其建構版本不會受到該問題影響。
舉例來說，如果修補的元件不存在於製造商的系統中，或是為瞭解決問題而從製造商的系統中移除元件，在這種情況下，系統可能符合規定，不需要製造商採取修補措施。
這與製造商只想修正重大修補程式，但不想採用其他適用修補程式 (因為會導致安全性測試失敗) 的情況截然不同。在這種情況下，系統會假設 SPL 未達標。