自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
安全的开发者选项
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
根据 Android 兼容性定义文档的规定,原始设备制造商 (OEM) 必须提供一种支持应用开发的方式。不过,如果在汽车内提供与移动设备类似的开发者选项,会导致汽车容易受到攻击。现在,OEM 可以使用经过身份验证的加密令牌机制控制开发者选项。具体来说,OEM 可以:
- 设置首次启动之前所需的默认限制。
- 如果愿意,可以使用加密令牌安全地向开发者授权。
- 在开发者通过身份验证并获得授权后,应用限制更改。
本文介绍了一项参考实现,其中包括 Debugging Restriction Controller 应用和远程 Token Issuer 端点。
术语
除术语部分的术语外,本文还使用了以下术语:
- JSON Web Signature (JWS),在 RFC 7515 中有定义
- 美国国家标准与技术研究院 (NIST)
设计
OEM 可以使用 JSON Web Signature (JWS) 令牌 (RFC7515) 为开发者授权。在参考实现中,访问令牌由 OEM 颁发,并由 Restriction Controller 应用使用。访问令牌旨在抵御重放攻击和防范伪造令牌。

图 1. 设计
集成和配置
OEM 必须指定首次启动时所需的默认限制。为此,需要使用多个静态资源叠加层,以便替换 AOSP 框架中的默认值。
无头系统用户的默认限制可以使用 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 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-27。
[null,null,["最后更新时间 (UTC):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."]]