2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
車両システムの分離
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
自動車システムの整合性を確保するため、Android Automotive は、次のレベルで受信データを保護します。
図 1. システム サービス アーキテクチャ
- アプリ。システムは、アプリに自動車サブシステムと通信する権限があることを確認します。
- 明確に定義された API。汎用 API では、任意のデータ blob は使用できません(API を適切に定義する必要があります)。
- カーサービス。フルディスク暗号化と確認付きブートによる、OTA(または USB)を介したアップデートのみが許可されます。サイドローディングはできません。
- 車両 HAL。特定のメッセージが許可されていることを確認します。
アプリと API
Android Automotive は Android 上に構築されており、安全性が重視されている多くのサブシステムと直接やり取りします。また、車両が異なれば、Android に公開される機能も異なるさまざまなインターフェースを持つ可能性があります。こうした機能を安全で使いやすくするために、Android の他の部分とは別の抽象化レイヤで分離されています。車両 HAL と通信できるのは、車載ネットワークを介して送信されるメッセージが厳格な形式を持つ、明確に定義された API のみです。これにより、Android デベロッパー向けの予測可能なインターフェースが提供され、車両の他の部分との安全なインタラクションが可能となります。
車両 HAL メッセージは 2 つのレベルでフィルタされます。
- アプリレベル。システム以外のアプリは、適切な権限を持つ車のサービスを介して車両 HAL にアクセスできます。
- 車両 HAL レベル。追加の保護レイヤを実現し、車両サブシステムに送信されるメッセージが正当な送信元から発信されていることを保証します。また、メッセージのレート制限に使用され、悪意のあるアプリが CAN バスにフラッディングを引き起こしたり、車両サブシステムに干渉したりするのを防ぎます。
車両 HAL
車両 HAL は車両とやり取りする下位レイヤであり、ドライバ入出力制御(ioctl)呼び出しを介して、車載ネットワークやその他の車両ハードウェアと通信します。
車両 HAL は、IVI システムに接続されている Android Automotive の唯一のコンポーネントで、アプリ プロセッサ / マイクロコントローラに直接接続されるか、VMCU を介してゲート制御されます。車両 HAL へのアクセスを、SELinux ルールとカーネル インターフェースに対する適切な権限を使用して、システムアプリに制限する必要があります。
SELinux ポリシー
Android Automotive は SELinux を拡張して、ドライバへのアクセス(オープン、クローズ、読み取り、書き込み、ioctl 呼び出しを含む)をフィルタします。ioctl フィルタリング(ならびに他の SELinux 機能)を使用すると、車両 HAL で許可および受け入れられる CAN メッセージの種類が制限され、攻撃対象領域を大幅に削減できます。SELinux の詳細については、Android での Security-Enhanced Linux をご覧ください。
また、自動車のユースケースには、分離と制御が必要な新しいタイプの機密データが含まれます。機密データには個別の権限があります。暖房換気空調システムの制御やウィンドウ調整などの他の機能は、システムアプリにのみ提供する必要があります。Automotive 固有の SELinux ポリシーの例:
<permission-group
android:name=”android.support.car.permission.CAR_MONITORING />
<permission
android:name=”android.support.car.permission.CAR_MILEAGE”
android:protectionLevel=”signature|privileged” />
<permission
android:name=”android.support.car.permission.CAR_SPEED”
android:permissionGroup=”android.permission-group.LOCATION”
android:protectionLevel=”dangerous” />
<permission
android:name=”android.support.car.permission.CAR_VENDOR_EXTENSION”
android:permissionGroup=”android.support.car.permission.CAR_INFORMATION”
android:protectionLevel=”signature|privileged” />
CAR_MONITORING
権限グループは、自動車関連の権限用に作成されました。現在の速度は機密情報とみなされます。そのため、CAR_SPEED
権限は保護レベルが dangerous で作成されました。このレベルは情報が非公開であり、機密性が高いことを意味します。権限 CAR_VENDOR_EXTENSION
は、システムレベルの権限または署名レベルの権限(明示的にこの権限が付与されているシステムアプリまたは署名付きアプリに使用されます)で作成されました。
アプリとアクティビティのブロック
運転に集中できるように、Android Automotive では追加のコントロール(許可リスト)が用意されており、サイドローディングされたアプリを車両が動いているときに使用できないようにします。このようなアプリは、車両が駐車または停止された場合は実行できます。
許可リストは、車両が動いているときに使用できるアプリを指定します。許可リストを更新できるのは、信頼できるシステムアプリのみです。アップデートはネットワークを介して行われる可能性がありますが、アップデートの信頼性が高いとみなすべきではありません。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。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,["# Vehicle system isolation\n\nTo ensure car system integrity, Android Automotive protects incoming data at these levels:\n\n**Figure 1.** System Service Architecture\n\n- **Apps.** System verifies an app has permission to talk to Car subsystems.\n- **Well-defined APIs.** Generic APIs do not accept arbitrary data blobs (APIs must be well defined).\n- **Car Service.** Updates allowed only through OTA (or USB), with full-disk encryption and verified boot. Can't be sideloaded.\n- **Vehicle HAL.** Verifies specific messages are allowed.\n\n### Apps and APIs\n\nAndroid Automotive is built on Android and interacts directly with numerous safety-critical\nsubsystems. In addition, different vehicles may have different interfaces with different\nfunctionalities exposed to Android. To make these functionalities safe and streamlined, they are\nisolated in an abstraction layer, separate from the rest of Android. Only *well-defined* APIs\nwith strict formatting on messages sent through in-vehicle networks can communicate with the Vehicle\nHAL. This provides a predictable interface for Android developers and provides a secure interaction\nwith the rest of the vehicle.\n\nVehicle HAL messages are filtered at two levels:\n\n- **App level.** Non-system apps can access vehicle HAL through car service with proper permissions.\n- **Vehicle HAL level.** Allows for an additional layer of protection and assurance that messages sent to vehicle subsystems originate from a legitimate source. Can also be used to rate limit messages, preventing malicious apps from flooding the CAN bus and potentially interfering with vehicle subsystems.\n\n### Vehicle HAL\n\nVehicle HAL is a lower layer that interacts with the vehicle, communicating with in-vehicle\nnetworks and other vehicular hardware through driver input/output control (ioctl) calls.\n\nThe vehicle HAL is the only component in Android Automotive connected to the IVI system, either\nthrough direct app processor/MicroController connection or gated through a VMCU. Access to the\nVehicle HAL should be restricted to system apps using SELinux rules and proper permissions\non kernel interfaces.\n\n### SELinux policies\n\nAndroid Automotive extends SELinux to filter driver access including open, close, read, write,\nand ioctl calls. Using ioctl filtering (along with other SELinux functionality) limits the type of\nCAN messages allowed and accepted by the Vehicle HAL, drastically reducing the attack surface. For\ndetails on SELinux, see\n[Security-Enhanced Linux in Android](/security/selinux).\n\nAdditionally, automotive use cases include new types of sensitive data that should be isolated\nand controlled. Sensitive data has separate permissions; other capabilities such as HVAC controls\nand window adjustment should be given only to system apps. Example of an Automotive-specific\nSELinux policy: \n\n```\n\u003cpermission-group\n android:name=”android.support.car.permission.CAR_MONITORING /\u003e\n\n\u003cpermission\n android:name=”android.support.car.permission.CAR_MILEAGE”\n android:protectionLevel=”signature|privileged” /\u003e\n\u003cpermission\n android:name=”android.support.car.permission.CAR_SPEED”\n android:permissionGroup=”android.permission-group.LOCATION”\n android:protectionLevel=”dangerous” /\u003e\n\u003cpermission\n android:name=”android.support.car.permission.CAR_VENDOR_EXTENSION”\n android:permissionGroup=”android.support.car.permission.CAR_INFORMATION”\n android:protectionLevel=”signature|privileged” /\u003e\n```\n\nThe `CAR_MONITORING` permission group was created for automotive-related permissions.\nCurrent speed can be regarded as sensitive information. Therefore, `CAR_SPEED`\npermissions were created with a protection level of *dangerous* . This level means the\ninformation is private and sensitive. The permission `CAR_VENDOR_EXTENSION` was created\nwith the system- or signature-level permission, which is used for system apps or signed apps that\nare explicitly granted this permission.\n\n### App and activity blocking\n\nTo reduce distracted driving, Android Automotive provides additional controls (a allowlist) to\nensure sideloaded apps can't be used when the vehicle is in motion. These apps can still\nrun when a vehicle is parked or stopped.\n\nThe allowlist specifies apps that can be used when the vehicle is moving. Only trusted\nsystem apps can update the allowlist. While updates can occur over the network, updates should not\nbe considered reliable."]]