El sistema de tipos de VSIDLC opera en dos niveles: Protobuf y VSIDL. Protobuf se usa para definir los mensajes que se intercambian entre el publicador y los suscriptores definidos por VSIDL. VSIDL hace referencia a los tipos declarados por protobuf.
En esta página, se explica cómo definir mensajes y métodos de llamada de procedimiento remoto (RPC) para llamar y responder a solicitudes.
Define mensajes
En esta sección, se explica cómo se definen los mensajes en VSIDL y protobuf.
En la siguiente muestra de código, se define un mensaje TirePressure:
syntax = "proto3";
package com.android.sdv.sample.vsidl;
message TirePressure {
uint32 pressure = 1;
}
Define servicios de RPC
En protobuf, un servicio de RPC define un conjunto de métodos que se pueden llamar de forma remota como si fueran llamadas a funciones locales. En el siguiente ejemplo, se definen los tipos de mensajes de solicitud y respuesta, y el método de servicio de RPC que se usa para realizar una solicitud y recibir una respuesta:
syntax = "proto3";
package com.google.sdv;
enum SeatHeatingLevel {
OFF = 0;
LOW = 1;
HIGH = 2;
}
// Request to set seat heating
message SetSeatHeatingRequest {
enum Seat {
DRIVER = 0;
PASSENGER = 1;
}
Seat seat = 1;
SeatHeatingLevel level = 2;
}
// Response to setting seat heating
message SetSeatHeatingResponse {
bool success = 1;
}
// Seat heating service
service SeatHeatingService {
rpc SetSeatHeating (SetSeatHeatingRequest) returns (SetSeatHeatingResponse);
}
En la que:
serviceidentifica una colección de métodos RPC relacionados.rpcidentifica un solo método de RPC con tipos de mensajes de entrada y salida (SetSeatHeatingRequestySetSeatHeatingResponse, respectivamente).
Configura la integración del sistema de compilación
Para permitir que vsidlc descubra tus definiciones de .proto y que el sistema de compilación de Android las compile, debes incluir un archivo Android.bp en la carpeta superior de tu directorio de catálogo.
Este archivo debe definir un destino rust_protobuf que agrupe tus archivos .proto (con una extensión .proto).
Todos los archivos de tu catálogo deben estar incluidos en un grupo de archivos. Si hay varios grupos de archivos en el archivo Android.bp, vsidlc toma el primero.
En el siguiente ejemplo, se muestra un destino rust_protobuf típico para un catálogo de VSIDL:
rust_protobuf {
name: "liboem_vehicle_messages",
crate_name: "oem_vehicle_messages",
source_stem: "oem_vehicle_messages_source",
protos: [
"**/*.proto",
],
rustlibs: [
"libvsidl_v1_proto_rs",
],
proto_flags: [
"-I external/protobuf/src",
],
apex_available: [
"//apex_available:platform",
"//apex_available:anyapex",
],
vendor_available: true,
product_available: true,
min_sdk_version: "35",
}
filegroup {
name: "catalog_oem_vehicle_messages",
srcs: ["**/*"],
}
En la que:
name: Es un identificador único para el destino de compilación. Por convención, comienza conlib.crate_name: Es el nombre del crate de Rust generado.protos: Es una lista de todos los archivos .proto del catálogo. Se admiten globs como**/*.proto.rustlibs: Debe incluirlibvsidl_v1_proto_rspara proporcionar las anotaciones y los tipos de SDV estándar.proto_flags: Se usa para especificar rutas de inclusión.-I external/protobuf/srcsuele ser necesario para resolver tipos de protobuf estándar.min_sdk_version: Se estableció en"35"(Android 15) para declarar la compatibilidad con las APIs de la plataforma de SDV correspondientes y los requisitos de la cadena de herramientas de Rust.filegroup: Se requiere para la detección en tiempo de compilación. Incluye todos los archivos VSIDL, protobuf yAndroid.bpensrcspara que el sistema de compilación pueda copiarlos en el espacio aislado de compilación.
¿Qué sigue?
Para continuar con la implementación de la arquitectura de tu servicio, consulta Cómo definir la arquitectura del servicio.