Le système de typographie de VSIDLC fonctionne à deux niveaux : Protobuf et VSIDL. Protobuf est utilisé pour définir les messages échangés entre l'éditeur et les abonnés définis par VSIDL. VSIDL fait référence aux types déclarés par protobuf.
Cette page explique comment définir des messages et des méthodes d'appel de procédure à distance (RPC) pour appeler des requêtes et y répondre.
Définir les messages
Cette section explique comment les messages sont définis dans VSIDL et protobuf.
L'exemple de code suivant définit un message TirePressure :
syntax = "proto3";
package com.android.sdv.sample.vsidl;
message TirePressure {
uint32 pressure = 1;
}
Définir les services RPC
Dans protobuf, un service RPC définit un ensemble de méthodes qui peuvent être appelées à distance comme s'il s'agissait d'appels de fonction locaux. L'exemple suivant définit les types de messages de requête et de réponse, ainsi que la méthode de service RPC utilisée pour envoyer une requête et recevoir une réponse :
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);
}
Où :
serviceidentifie une collection de méthodes RPC associées.rpcidentifie une seule méthode RPC avec des types de messages d'entrée et de sortie (SetSeatHeatingRequestetSetSeatHeatingResponse, respectivement).
Configurer l'intégration du système de compilation
Pour permettre à vsidlc de découvrir vos définitions protobuf et au système de compilation Android de les compiler, vous devez inclure un fichier Android.bp dans le dossier le plus haut de votre répertoire de catalogue.
Ce fichier doit définir une cible rust_protobuf qui regroupe vos fichiers protobuf (avec une extension .proto).
Chaque fichier de votre catalogue doit être inclus dans un groupe de fichiers. S'il existe plusieurs groupes de fichiers dans le fichier Android.bp, vsidlc prend le premier.
L'exemple suivant montre une cible rust_protobuf type pour un catalogue 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: ["**/*"],
}
Où :
name: identifiant unique de la cible de compilation. Par convention, il commence parlib.crate_name: nom de la crate Rust générée.protos: liste de tous les fichiers protobuf du catalogue. Les globs tels que**/*.protosont acceptés.rustlibs: doit inclurelibvsidl_v1_proto_rspour fournir les annotations et les types SDV standards.proto_flags: permet de spécifier les chemins d'inclusion.-I external/protobuf/srcest souvent nécessaire pour résoudre les types protobuf standards.min_sdk_version: défini sur"35"(Android 15) pour déclarer la compatibilité avec les API de plate-forme SDV et les exigences de la chaîne d'outils Rust correspondantes.filegroup: obligatoire pour la découverte au moment de la compilation. Incluez chaque fichier VSIDL, protobuf etAndroid.bpdanssrcsafin que le système de compilation puisse les copier dans le bac à sable de compilation.
Étape suivante
Pour continuer à implémenter votre architecture de service, consultez Définir l'architecture de service.