為配合主幹穩定開發模型,並確保生態系統的平台穩定性,我們將於 2026 年起,在第 2 季和第 4 季將原始碼發布至 AOSP。如要建構及貢獻 AOSP,建議使用 android-latest-release,而非 aosp-main。android-latest-release 資訊清單分支版本一律會參照推送至 AOSP 的最新版本。詳情請參閱「Android 開放原始碼計畫變更」一文。
Google uses AI technology to translate content into your preferred language. AI translations can contain errors.
為什麼要使用 AVF?
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
行動運算裝置處理的個人私密資料量越來越大。由於這類私密資料的存在,加上持續連線至外部世界,有心人士會因此更想利用漏洞達成目標,進而增加投資。
作業系統會透過硬體記憶體管理單元 (MMU),提供可將不相關程序彼此隔離的抽象化功能。只有屬於可信賴運算基礎 (TCB) 的元件,才能直接程式設計這些 MMU。
自 Unix 類作業系統推出以來,這個模型一直是隱私權和安全性的實作基礎。然而,這項規定已成為問題,因為現今的 TCB 過於龐大,包含大多數裝置和匯流排驅動程式、複雜的排程器、檔案系統、網路堆疊和通訊協定、快取、可執行檔剖析器和載入器,以及通訊端。確保這個複雜系統的每個角落都安全無虞,已變得非常困難。
Linux 核心的程式碼超過 2 千萬行,變更和重寫的速度驚人。這項成長對 Android 和我們的生態系統有莫大助益。但由於 TCB 很大,很難確保沒有可供利用的安全性漏洞。
硬體供應商已開發出解決方案,例如 Arm 的 TrustZone,可讓處理器以安全模式執行,並將記憶體交易標記為「安全」或「不安全」。在這種系統中,機密資料會儲存在安全世界中,且只有安全世界可以直接存取,並視需要向非安全世界提供服務。
這類解決方案的主要限制是網域過於粗略,僅限安全和不安全。隨著需要與作業系統隔離的用途越來越多,受攻擊面也會隨之擴大,而安全漏洞可能導致整部裝置遭到入侵。
現今解決方案的另一項限制是,這些方案是為相對靜態的世界設計,所有用途的資源都會事先計算和分配。這些解決方案不適合動態用途,也就是依需求分配資源的用途。
此外,在 Android 作業系統以外使用的 API 支離破碎,限制了我們在 Android 規模部署用途的能力,包括 Keymint 和 Gatekeeper 等基本功能。
為解決這些限制,並讓 Android 為新一代用途提供穩固基礎,Android 13 推出安全虛擬化技術,也就是 Android 虛擬化架構 (AVF)。
Android 虛擬化架構的主要目標是為新一代應用情境提供安全且私密的執行環境。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-12-03 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-12-03 (世界標準時間)。"],[],[]]