自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
安全的開發人員選項
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
根據 Android 相容性定義說明文件,原始設備製造商 (OEM) 必須提供啟用應用程式開發功能的方法。不過,在車內提供類似行動裝置的開發人員選項,會使車輛容易遭到攻擊。原始設備製造商 (OEM) 現在可以使用經過驗證的加密金鑰權杖機制,限制開發人員選項的存取權。具體來說,原始設備製造商可以:
- 在第一次開機前,設定所需的預設限制。
- 安全授權開發人員,並視需要使用加密權杖。
- 在開發人員完成驗證及授權程序後,套用限制變更。
本文將說明參考實作項目,其中包含偵錯限制控制器應用程式和遠端符記發出端點。
術語
除了術語,本文還會使用以下術語:
- JSON Web Signature (JWS),定義於 RFC 7515
- 國家標準暨技術研究院 (NIST)
設計
OEM 廠商可以使用 JSON Web Signature (JWS) 權杖 (RFC7515) 授權開發人員。在參考實作項目中,存取權杖由原始設備製造商 (OEM) 核發,並由限制控制器應用程式使用。存取權杖旨在抵禦重播攻擊和偽造的權杖。

圖 1. 設計
整合和設定
原始設備製造商必須在第一次啟動時指定所需的預設限制。這項操作會使用多個靜態資源疊加層,以便覆寫 Android 開放原始碼計畫架構中的預設值。
無頭系統使用者的預設限制可透過 frameworks/base/core/res/res/values/config.xml
中的 config_defaultFirstUserRestrictions
字串設定,例如:
<!-- User restrictions set when the first user is created.
Note: Also update appropriate overlay files. -->
<string-array translatable="false" name="config_defaultFirstUserRestrictions">
<item>no_debugging_features</item>
</string-array>
您可以在 frameworks/base/core/res/res/xml/config_user_types.xml
中設定駕駛人、乘客和隨行者的預設限制。OEM 可以重疊這些字串,為各類型使用者分別設定預設限制,例如:
<user-types>
<full-type name="android.os.usertype.full.SECONDARY" >
<default-restrictions no_debugging_features="true"/>
</full-type>
<full-type name="android.os.usertype.full.GUEST" >
<default-restrictions no_debugging_features="true"/>
</full-type>
</user-types>
您可以在 AOSP 的以下位置找到參考實作項目:
packages/apps/Car/DebuggingRestrictionController
測試
Google 建議原始設備製造商 (OEM) 從參考實作開始,然後再進行擴充。
- 在覆蓋檔案中設定所需限制後,請編譯 AAOS 並驗證定義的流程。使用參考應用程式和啟用 JWS 的本機服務,驗證存取設定。
- 設定系統以使用支援 JWS 的雲端服務 (選用)。確認您是否在後端服務中觀察到所需的流程。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[[["容易理解","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-07-27 (世界標準時間)。"],[],[],null,["# Secure developer options\n\nPer the [Android Compatibility Definition Document](/docs/compatibility/cdd),\nOEMs must provide a way to enable app development. However, providing mobile-like\ndeveloper options within cars leaves those cars vulnerable to attack. Access to developer\noptions can now be gated by an OEM using an authenticated cryptographic token mechanism.\nSpecifically, an OEM can:\n\n- Set desired default restrictions before the first boot.\n- Securely authorize developers, with crypto tokens if preferred.\n- Apply restriction changes once a developer is both authenticated and authorized.\n\nThis article describes a reference implementation consisting of a debugging restriction\ncontroller app and a remote token issuer endpoint.\n\nTerminology\n-----------\n\nIn addition to [Terminology](/docs/automotive/start/terms),\nthese terms are used in this article:\n\n- JSON Web Signature (JWS), defined in RFC 7515\n- National Institute of Standards and Technology (NIST)\n\nDesign\n------\n\nOEMs can authorize developers with JSON Web Signature (JWS) tokens (RFC7515). In the\nreference implementation, access tokens are issued by OEMs and consumed by the restriction\ncontroller app. Access tokens are designed to resist replay attacks and forged tokens.\n\n**Figure 1.** Design\n\nIntegration and configuration\n-----------------------------\n\nOEMs must specify the desired default restrictions on the first boot. This is done with\nseveral static resource overlays to override the defaults in the AOSP framework.\n\nThe default restrictions for the headless system user can be configured with the\n`config_defaultFirstUserRestrictions` string in\n`frameworks/base/core/res/res/values/config.xml`, for example: \n\n```scdoc\n\u003c!-- User restrictions set when the first user is created.\n Note: Also update appropriate overlay files. --\u003e\n \u003cstring-array translatable=\"false\" name=\"config_defaultFirstUserRestrictions\"\u003e\n \u003citem\u003eno_debugging_features\u003c/item\u003e\n \u003c/string-array\u003e\n```\n\nThe default restrictions for drivers, passengers, and guests can be configured in\n`frameworks/base/core/res/res/xml/config_user_types.xml`. An OEM can overlay\\|\nthese strings to set the default restrictions on each type of user respectively, for example: \n\n```carbon\n\u003cuser-types\u003e\n \u003cfull-type name=\"android.os.usertype.full.SECONDARY\" \u003e\n \u003cdefault-restrictions no_debugging_features=\"true\"/\u003e\n \u003c/full-type\u003e\n \u003cfull-type name=\"android.os.usertype.full.GUEST\" \u003e\n \u003cdefault-restrictions no_debugging_features=\"true\"/\u003e\n \u003c/full-type\u003e\n\u003c/user-types\u003e\n```\n\nA reference implementation is provided at the following location in AOSP: \n\n```carbon\npackages/apps/Car/DebuggingRestrictionController\n```\n\nTesting\n-------\n\nGoogle recommends that OEMs start with the reference implementation and build out from there.\n\n1. After configuring the desired restrictions in the overlay files, compile AAOS and validate the defined flows. Use the reference app and local JWS enabled service to verify your access settings.\n2. Configure the system to use your JWS enabled cloud service (optional). Verify you're observing the desired flow on your backend service."]]