Définir des messages et des services RPC

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ù :

  • service identifie une collection de méthodes RPC associées.
  • rpc identifie une seule méthode RPC avec des types de messages d'entrée et de sortie (SetSeatHeatingRequest et SetSeatHeatingResponse, 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 par lib.
  • crate_name : nom de la crate Rust générée.
  • protos : liste de tous les fichiers protobuf du catalogue. Les globs tels que **/*.proto sont acceptés.
  • rustlibs : doit inclure libvsidl_v1_proto_rs pour fournir les annotations et les types SDV standards.
  • proto_flags : permet de spécifier les chemins d'inclusion. -I external/protobuf/src est 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 et Android.bp dans srcs afin 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.