2026 年より、トランク安定版開発モデルに沿ってエコシステムのプラットフォームの安定性を確保するため、第 2 四半期と第 4 四半期に AOSP にソースコードを公開します。AOSP のビルドとコントリビューションには、aosp-main ではなく android-latest-release を使用することをおすすめします。android-latest-release マニフェストブランチは、常に AOSP にプッシュされた最新のリリースを参照します。詳細については、AOSP の変更点をご覧ください。

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

車両シグナルカタログ

Metrics Configuration Generator（MCG）は、シグナル名の確認、式に対する型チェックの実行、出力型の推論によって指標構成を検証します。MCG がこれらのタスクを実行するには、車両シグナルのプロトコルバッファ（protobuf）メッセージ定義にアクセスする必要があります。

SDV では、車両シグナルとサービスは Vehicle Service Interface Definition Language（VSIDL）を使用して定義されます。VSIDL は protobuf ファイルを使用してメッセージを指定します。これらの protobuf ファイルはシグナルカタログの基礎となります。

シグナル定義を MCG で使用できるようにするには、これらの VSIDL protobuf ファイルを protobuf FileDescriptorSet にパッケージ化して、MCG サービスにアップロードする必要があります。MCG では、アップロードされてバージョン管理された定義セットを車両シグナルカタログと呼びます（つまり、車両シグナルカタログは、VSIDL カタログ内の proto メッセージ定義をコンパイルしてアップロードしたものです）。

車両シグナルカタログとは

車両シグナルカタログは、検証用のシグナル定義を protobuf FileDescriptorSet としてパッケージ化して MCG に提供します。

MCG では、カタログはアップロード時に割り当てるバージョン文字列で識別されます。これにより、複数の異なるシグナル定義セットを管理できます。たとえば、ソフトウェアリリース（v1.0、v1.1、v2.0）や、さまざまな車両モデルまたはハードウェア構成（suv-my2025、sedan-my2025）に対して、異なるカタログバージョンを維持できます。各指標構成は vs_version フィールドを使用して特定のカタログを参照します。このカタログは、データソースとして使用できるシグナルを定義し、型推論と検証のためのシグナル定義を提供します。

FileDescriptorSet のインスタンスを作成する

メッセージと RPC サービスを定義するで説明したように、車両シグナルは protobuf ファイルで protobuf メッセージとして定義されます。SDV プロジェクトに参加している場合は、プロジェクトの VSIDL カタログの protobuf ファイルを使用して FileDescriptorSet のインスタンスを作成します。

MCG のカタログを作成するには、protoc を使用して protobuf ファイルを FileDescriptorSet バイナリファイルにバンドルします。すべての protobuf ファイルが 1 つのフォルダにある場合は、次のコマンドを実行して vehicle_signals.pb を生成します。

protoc --include_imports --descriptor_set_out=vehicle_signals.pb <var label="path to folder with .proto files">path/to/your/protos</var>/*.proto

カタログをアップロードして管理する

シグナル定義セットをカタログとしてアップロードすると、指標構成リクエストでバージョン名で参照できます。

カタログバージョンを追加または更新する

vehicle_signals.pb カタログファイルを生成したら、/api/v1/vs/ の MCG API エンドポイントを使用してアップロードして管理できます。カタログを追加または更新するエンドポイント POST /api/v1/vs/ では、FileDescriptorSet を JSON ペイロードで base64 エンコードされた文字列として渡す必要があります。

API で使用するために vehicle_signals.pb をエンコードするには、base64 コマンドを使用します。-w 0 フラグは行の折り返しを無効にするため、エンコードされた文字列は 1 行で表示されます。

VEHICLE_SIGNALS_BASE64=$(base64 -w 0 vehicle_signals.pb)

vehicle_signals.pb を新しいバージョン（v1.0 など）としてアップロードする場合や、既存のバージョンを更新する場合は、base64 エンコードされたコンテンツを含む POST リクエストを、一意のバージョン名を使用して /api/v1/vs/ エンドポイントに送信します。

リクエストの本文は、version 文字列と base64 エンコードされた vehicle_signals 文字列を含む JSON オブジェクトである必要があります。

{
  "version": "v1.0",
  "vehicle_signals": "Q2lSb1pYB3jCRkRt..."
}

次の例は、curl を使用して vehicle_signals.pb をバージョン v1.0 としてアップロードする方法を示しています。この例では、printf を使用して JSON ペイロードを作成し、それを curl にパイプ処理します。これにより、非常に長い 1 行の base64 文字列を含む JSON ファイルを作成する必要がなくなります。

# 1. Encode the FileDescriptorSet to a Base64 string
VEHICLE_SIGNALS_BASE64=$(base64 -w 0 vehicle_signals.pb)

# 2. Define catalog version and build JSON payload
VERSION="<var label="catalog version">v1.0</var>"
JSON_PAYLOAD=$(jq -n --arg v "$VERSION" --arg d "$VEHICLE_SIGNALS_BASE64" \
  '{version: $v, vehicle_signals: $d}')

# 3. POST the data to the API endpoint
echo "$JSON_PAYLOAD" | curl -H "Content-Type: application/json" --data-binary @- "$SERVICE_URL/api/v1/vs/"

バージョンを一覧表示して削除する

使用可能なすべてのカタログバージョンを一覧表示したり、特定のバージョンを削除したりできます。

バージョンを一覧表示する: アップロードされたすべてのカタログバージョンの ID のリストを表示するには、/api/v1/vs/ に GET リクエストを送信します。GET /api/v1/vs/ をご覧ください。
バージョンを削除する: カタログを削除するには、DELETE リクエストを /api/v1/vs/{version} に送信します。ここで、{version} はカタログのアップロード時に指定された ID です（v1.0 など）。DELETE /api/v1/vs/{version} をご覧ください。

すべてのエンドポイントの詳細については、API リファレンスをご覧ください。

指標構成でカタログを使用する

アップロードしたら、vs_version フィールドを使用して指標構成でカタログバージョンを参照します。

{ "vs_version": "v1.0", ... }

この JSON オブジェクトが /api/v1/generate_metrics_config エンドポイントまたは /api/v1/validate_metrics_config エンドポイントに送信されると、MCG は v1.0 カタログのシグナル定義を使用して検証と型推論を行います。