Android Automotive OS · VHAL · GAS
Android Auto と Android Automotive OS は、名前が似ているだけの別物です。 前者はスマホの画面を車に映すもの。後者は車そのもので動く Android。
この違いを飛ばしたまま資料を読むと、最後まで話が噛み合いません。 車両の信号がアプリに届くまでの経路を、下の層から順に追いかけます。
ここを混同したまま進む人が本当に多い。
| Android Auto | Android Automotive OS (AAOS) | |
|---|---|---|
| どこで動くか | スマホ | 車のヘッドユニット |
| 車にスマホが要るか | 要る(繋いで投影) | 要らない |
| 車両データに触れるか | ほぼ触れない | 触れる(空調・ギア・EV残量 …) |
| アプリの置き場 | スマホの Play | 車載の Play(GAS搭載車) |
| 作る人 | アプリ開発者 | OEM / Tier1 / アプリ開発者 |
AAOS は AOSP をベースにしたプラットフォームそのものです。OEM がこれを自社の車に載せ、その上に自社のシステムアプリを作る。だから「Android アプリを作る」話と「Android が動く車を作る」話が、同じ言葉で語られてしまいます。
この図の「境界線」が、そのまま組織の分担線になります。
図: AAOS の層構造。青枠の2つが車載固有の層
Honda の AAOS 採用事例について TECH PLAY に公開されている解説では、HAL より上のレイヤーを OEM 側が担当し、ハードウェア領域は従来どおり Tier1 が担当する、という分担が語られています。オーディオ周りでは AudioFlinger を中心に CarAudioManager が加わる構成、既存の AudioFocus やネイティブの AAudio の活用にも触れられています。
ここが車載Androidの心臓部です。
アプリは CAN 信号を直接読みません。VHAL が車両信号を「Vehicle Property」という統一された形に変換し、アプリはその property を読み書きします。だから車種やネットワークの違いが、アプリ側のコードに漏れてきません。
入口は Car クラスです。ここから各 Manager を取り出します。
// Car インスタンスから CarPropertyManager を取得する
Car car = Car.createCar(context);
CarPropertyManager mgr =
(CarPropertyManager) car.getCarManager(Car.PROPERTY_SERVICE);
// 単発で読む — 例: 車種名
String model = mgr.getProperty(
String.class, VehiclePropertyIds.INFO_MODEL, 0).getValue();
// 変化を購読する — 例: 現在のギア
mgr.registerCallback(callback,
VehiclePropertyIds.CURRENT_GEAR,
CarPropertyManager.SENSOR_RATE_ONCHANGE);押さえておく用語
android.car ─ 車載サービスへの入口となるパッケージCarPropertyManager ─ 車速・燃料・ギア・バッテリなど車両プロパティの取得と変更VehiclePropertyIds ─ INFO_MODEL CURRENT_GEAR など定義済みのIDAndroid 14 以降、system property の定義は VHAL のインタフェースから分離され、AIDL の android.hardware.automotive.vehicle.property に置かれるようになりました。あわせて CarPropertyManager / CarPropertyService 側にも、非同期の get/set API と fake VHAL モードを扱う API が追加されています。
fake VHAL は、実車がなくても property の読み書きを試せるという意味で、最初に触るときの入口になります。
03節の「プロパティを読む」だけでは、車載の仕事の半分も説明できません。スマホの Android に無くて AAOS にだけあるものを、実装で出会う順に並べます。
VHAL の各プロパティには、値のほかに設定（config）があります。アプリの挙動は、ほぼこの設定で決まります。
| 項目 | 取りうる値 | 意味 |
|---|---|---|
| access | READ / WRITE / READ_WRITE | 読めるだけか、書けるか。車速は読むだけ、空調の設定温度は読み書き |
| changeMode | STATIC / ON_CHANGE / CONTINUOUS | STATIC は起動後に変わらない（車種名など）。ON_CHANGE は変わった時だけ通知（ギアなど）。CONTINUOUS は連続的に変わり、決めた頻度で通知（車速など） |
| areaId | GLOBAL / 座席 / 窓 / ドア / ミラー / 車輪 | 同じ「シートヒーター」でも運転席と助手席は別のエリアとして扱う |
| status | AVAILABLE / UNAVAILABLE / ERROR | 値が取れない時は、値の代わりにこの状態が返る |
プロパティ ID は、ビットの組み合わせです。「グループ（SYSTEM か VENDOR か）｜エリアの種類｜値の型｜番号」を足し合わせた 32 ビットの値で、OEM 独自のプロパティは VENDOR グループに作ります。
// OEM 独自プロパティの ID の組み立て（例）
VehiclePropertyGroup.VENDOR // 0x20000000
| VehicleArea.GLOBAL // 0x01000000
| VehiclePropertyType.INT32 // 0x00400000
| 0x0101 // その OEM の中での通し番号権限はプロパティごとに決まっています。車種名やギアのように一般のアプリがそのまま読めるもの、車速のように実行時に利用者の許可が要るもの、空調の操作のように OEM のシステムアプリしか持てないものがあります。07b節の3日目の課題は、この段差を体で知るためのものです。
Android 13 から VHAL は AIDL になりました（それ以前は HIDL）。AOSP には基準実装があり、fake のハードウェア層（FakeVehicleHardware）が JSON に書かれたプロパティ定義を読んで動きます。エミュレータの fake VHAL の正体はこれです。OEM はこの層を自社の車両ネットワークにつなぐ実装に差し替えます。
AAOS には走行状態（PARKED ／ IDLING ／ MOVING）があり、状態ごとに UX 制限が決まります。制限の組み合わせは OEM が設定し、たとえば「アイドリング中は動画と初期設定を禁止、走行中は全面的に制限」のように書きます。
// 走行中も表示してよい画面だと宣言する（AndroidManifest.xml）
<activity android:name=".DistractionOptimizedMainActivity" ...>
<meta-data android:name="distractionOptimized" android:value="true"/>
</activity>この宣言が無い画面は、走行中は表示が止められます。宣言した画面も、CarUxRestrictionsManager から届く制限（文字数の上限、キーボード禁止、動画禁止など）に従って表示を減らす責任があります。「走行中に使える」とは、制限に合わせて自分で縮む画面のことです。
スマホは出力先が基本的に1つですが、車は運転席・後席・外部スピーカーなど出力先が複数あります。AAOS では車内をオーディオゾーンに分け、ゾーンごとに音量グループと出力デバイスを割り当てます。この対応は OEM が car_audio_configuration.xml に書きます。
AUDIO_DEVICE_OUT_BUS 型で、アドレスで区別される「バス」として扱う（例: bus_1 に音楽、bus_2 にナビ案内）CarAudioService の相互作用表で決まる。種類は3つ — Exclusive（後から来た方が取る）、Reject（後から来た方を断る）、Concurrent（両方鳴らす）。ナビ案内の間も音楽が小さく鳴り続けるのは Concurrent の例02節で触れた Honda の事例で AudioFlinger と CarAudioManager の話が出てくるのは、この層の設計が車ごとに違うからです。
AP_POWER_STATE_REQ ／ AP_POWER_STATE_REPORT）でやり取りして決める。エンジンを切ったらすぐ落ちるのではなく、サスペンドや終了の準備を段階的に進めるOEM は自社のデザインに合わせて画面を変えますが、AOSP のアプリのコードを毎回書き換えるわけではありません。Car UI ライブラリの部品（ツールバー、リストなど）を使ったアプリは、RRO（Runtime Resource Overlay）で色・大きさ・レイアウトを外から差し替えられます。「車種ごとに見た目が違うのに、中身は同じアプリ」という状態は、こうして作られています。
この節の要点
distractionOptimized で宣言し、UX 制限に合わせて縮むAAOS だけでは Google Maps も Play も付いてきません。
GAS(Google Automotive Services)は、AAOS の上に載せる Google のサービス群です。Google Maps、Google Play、アシスタントなどがこれにあたります。AAOS はオープンソースですが、GAS は OEM がライセンスして載せるもので、ここが分かれ目です。
「Google built-in」と書かれている車は、この GAS を積んだ車です。Play ストアからアプリを落とせるのも、GAS パートナーの車に限られます。
GAS を載せると、認証が要る
Google の互換性・性能・セキュリティ要件に準拠する必要があり、認証テストが伴います。よく名前が出るのは次の4つです。
この認証を代行できる Google 公認のラボも存在します(例: HARMAN の Automotive Engineering Services は GAS 認証の公認ラボとして発表しています)。
日本語の情報がほとんどない用語なので、ここに書いておきます。
Carma は Car Ready Mobile Apps プログラムの通称です。既存のスマホ向けアプリを、大きな改修なしに車載の大画面へ持ち込むための Google のプログラムで、次のような性質を持ちます。
要するに「運転中に使わせない代わりに、移植コストをほぼゼロにする」という割り切りです。車載向けに一から作り直す(Car App Library を使う)ルートとは、目的が違います。
| やりたいこと | 使うもの |
|---|---|
| 既存アプリを、駐車中に大画面で動かしたい | Carma(Car Ready Mobile Apps) |
| 運転中も使えるアプリを作りたい | androidx.car.app(Car App Library)のテンプレート |
| 車両データを読み書きしたい | android.car / CarPropertyManager |
アプリがこのプログラムに入るには。Google が公開している条件を短くまとめると：
2024年5月の I/O で発表され、2025年初頭から Google built-in の車への配信が始まりました。「CaRMA」で検索してここに来た方へ：Carma、CaRMA、Car Ready Mobile Apps はすべて同じプログラムの表記ゆれです。
仕様が動いている最中なので、古い記事を読むときは日付を見てください。
「Android Automotive OS」のニュース見出しを毎日自動で入れ替えて表示します（JavaScript が必要）。
車載の音声アシスタントが Google Assistant から Gemini へ移行しています。2026年4月には GM の約400万台への展開が報じられ、Google は Android Auto 対応車に続いて、Google built-in 搭載車へも順次展開すると公表しています(Lincoln Nautilus、Honda Passport、Chevrolet / Cadillac / GMC / Acura / Volvo の一部車種などが名前として挙がっています)。
Google built-in の車では、Gemini が車両システム・インフォテインメント設定・アプリの状態・EV情報・オーナーズマニュアル・車固有の UX 制限に、より近い位置に座ることになります。
Google は 「Android Automotive OS for Software Defined Vehicles」を発表しており、2026年後半に AOSP を通じたオープンソースのプログラムとして公開される予定とされています。インフォテインメントの枠を超えて、車両ソフトウェア全体に適用範囲を広げる動きです。
アプリ層より下は、ノートPCの上で全部試せます。2026年時点の Android Studio での手順です。
adb shell cmd car_service inject-vhal-event <propertyId> <value> でプロパティの変化を注入できます（adb shell cmd car_service help に一覧があります）。adb shell dumpsys car_service。アプリ側からは Car.createCar(context).getCarManager(Car.PROPERTY_SERVICE) で、03節の CarPropertyManager を取って読みます。認証段階のテスト（車向け CTS、GAS 要件）には OEM のベンチか認定ラボが要りますが、開発の最初の数か月で実車が必要になる場面はありません。
仕事として AAOS に関わりたい人向けには、立ち位置・スキル・年収・案件の探し方を Android Automotive エンジニアの仕事・年収・案件の探し方 に分けてまとめました。
このページの立場
すべて公開されている一次情報・公開記事のみから構成しています。特定の車種・案件・企業の非公開情報は含みません。仕様は変わるので、実装前には必ず AOSP の最新ドキュメントで確認してください。
07節の環境ができた前提で、1日1〜2時間。7日目に「自分の言葉で層構造を説明できる」状態を目標にします。
CarPropertyManager から車速（PERF_VEHICLE_SPEED）を取って画面に出す。Extended controls → Car data で値を変え、コールバックが呼ばれることを確認する。SecurityException をわざと出す。どの権限が「システムアプリ限定」かを AOSP の一覧で確認し、一般アプリに何が見えないかを書き出す。adb shell dumpsys car_service の出力と突き合わせる。02〜03節の図が、実物のログと一致する瞬間があります。12語だけ覚える用語
VHAL（車両 HAL。CAN 信号をプロパティに変換する層）／HAL（ハードウェア抽象化層）／CarService（プロパティを配るシステムサービス）／CarPropertyManager（アプリから車両プロパティを読む API）／GAS（Google Automotive Services。Maps・Play・Assistant などの束）／GMS（スマホ側の同種の束）／Car App Library（車向け UI をテンプレートで作るライブラリ）／DHU（Android Auto 用のデスクトップ・ヘッドユニット）／Carma（Car Ready Mobile Apps。既存アプリを駐車中だけ動かす枠）／OEM（自動車メーカー）／Tier1（メーカーに納める部品・ユニット会社）／CTS／ATS（互換性・車向けの認証テスト）
読むならこの本
[PR] Amazon・楽天の検索結果へのリンクです。当サイトはアフィリエイトで紹介料を得ることがあります。版や在庫は各ストアでご確認ください。
このページに来る人が検索している疑問に、短く答えます。