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

Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

車両シグナルカタログ

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

SDV では、車両の信号とサービスは、車両サービスインターフェース定義言語（VSIDL）を使用して定義されます。VSIDL は protobuf ファイルを使用してメッセージを指定します。これらの protobuf ファイルは、シグナルカタログの基礎を形成します。

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

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

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

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 path/to/your/protos/*.proto

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

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

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

vehicle_signals.pb カタログファイルを生成したら、/api/v2/vs/ の MCG API エンドポイントを使用してアップロードして管理できます。カタログを追加または更新するエンドポイント POST /api/v2/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/v2/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="v1.0"
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/v2/vs/"

バージョンの一覧表示と削除

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

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

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

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

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

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

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