2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
安全な開発者向けオプション
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Android 互換性定義ドキュメントに記載されているとおり、OEM はアプリ開発を可能にする方法を提供する必要があります。ただし、車内にモバイル同然の開発者向けオプションがあれば、その自動車は攻撃を受けやすくなります。そこで、OEM は認証済みの暗号トークンのメカニズムを使用して、開発者向けオプションへのアクセスを制限できるようになりました。具体的に、OEM は次のことを行えます。
- 初回起動前に必要なデフォルトの制限を設定する。
- 必要に応じて暗号鍵を使用して開発者を承認し、セキュリティを保護する。
- 開発者が認証および承認されたら、制限の変更を適用する。
この記事では、デバッグ制限コントローラ アプリとリモート トークン発行者エンドポイントで構成されるリファレンス実装について説明します。
用語
用語に加えて、この記事では、以下の用語も使用されています。
- RFC 7515 で定義されている JSON Web Signature(JWS)
- 国立標準技術研究所(NIST)
設計
OEM は JSON Web Signature(JWS)トークン(RFC7515)を使用して、開発者を承認できます。リファレンス実装では、OEM がアクセス トークンを発行し、制限コントローラ アプリが使用します。アクセス トークンはリプレイ攻撃と偽造トークンに対抗するように設計されています。

図 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 および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[[["わかりやすい","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 UTC。"],[],[],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."]]