Definir mensagens e serviços RPC

O sistema de tipos do VSIDLC opera em dois níveis: Protobuf e VSIDL. O Protobuf é usado para definir mensagens trocadas entre o editor e os assinantes definidos pelo VSIDL. O VSIDL faz referência a tipos declarados pelo Protobuf.

Esta página explica como definir mensagens e métodos de chamada de procedimento remoto (RPC) para chamar e responder a solicitações.

Definir mensagens

Esta seção explica como as mensagens são definidas no VSIDL e no Protobuf.

O exemplo de código a seguir define uma mensagem TirePressure:

syntax = "proto3";

package com.android.sdv.sample.vsidl;

message TirePressure {
  uint32 pressure = 1;
}

Definir serviços RPC

No Protobuf, um serviço RPC define um conjunto de métodos que podem ser chamados remotamente como se fossem chamadas de função local. O exemplo a seguir define um tipo de mensagem de solicitação e resposta e o método de serviço RPC usado para fazer uma solicitação e receber uma resposta:

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);
}

Em que:

• service identifica uma coleção de métodos RPC relacionados.
• rpc identifica um único método RPC com tipos de mensagem de entrada e saída (SetSeatHeatingRequest e SetSeatHeatingResponse, respectivamente).

Configurar a integração do sistema de build

Para permitir que o vsidlc descubra suas definições do Protobuf e permitir que o sistema de build do Android as compile, inclua um arquivo Android.bp na pasta mais alta do diretório do catálogo.

Esse arquivo precisa definir um destino rust_protobuf que agrupa seus arquivos do Protobuf (com uma extensão .proto). Cada arquivo no catálogo precisa ser contabilizado em um grupo de arquivos. Se houver vários grupos de arquivos no arquivo Android.bp, o vsidlc vai usar o primeiro.

O exemplo a seguir mostra um destino rust_protobuf típico para um catálogo 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: ["**/*"],
  }

Em que:

• name: um identificador exclusivo para o destino do build. Por convenção, ele começa com lib.
• crate_name: o nome da caixa Rust gerada.
• protos: uma lista de todos os arquivos do Protobuf no catálogo. Globs como **/*.proto são aceitos.
• rustlibs: precisa incluir libvsidl_v1_proto_rs para fornecer as anotações e os tipos SDV padrão.
• proto_flags: usado para especificar caminhos de inclusão. -I external/protobuf/src geralmente é necessário para resolver tipos de Protobuf padrão.
• min_sdk_version: definido como "35" (Android 15) para declarar a compatibilidade com as APIs da plataforma SDV correspondentes e os requisitos da cadeia de ferramentas Rust.
• filegroup: obrigatório para a descoberta no momento do build. Inclua todos os arquivos VSIDL, Protobuf e Android.bp em srcs para que o sistema de build possa copiá-los para a sandbox de compilação.

A seguir

Para continuar implementando a arquitetura de serviço, consulte Definir a arquitetura de serviço.