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 の読み書きを試せるという意味で、最初に触るときの入口になります。
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 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 を通じたオープンソースのプログラムとして公開される予定とされています。インフォテインメントの枠を超えて、車両ソフトウェア全体に適用範囲を広げる動きです。
このページの立場
すべて公開されている一次情報・公開記事のみから構成しています。特定の車種・案件・企業の非公開情報は含みません。仕様は変わるので、実装前には必ず AOSP の最新ドキュメントで確認してください。