Definiowanie wiadomości i usług RPC

System typów VSIDLC działa na 2 poziomach: Protobuf i VSIDL. Protobuf służy do definiowania wiadomości wymienianych między wydawcą a subskrybentami zdefiniowanymi przez VSIDL. VSIDL odwołuje się do typów zadeklarowanych przez Protobuf.

Z tej strony dowiesz się, jak definiować wiadomości i metody zdalnego wywoływania procedur (RPC) do wywoływania żądań i odpowiadania na nie.

Definiowanie wiadomości

Z tej sekcji dowiesz się, jak definiować wiadomości w VSIDL i Protobuf.

Poniższy przykład kodu definiuje wiadomość TirePressure:

syntax = "proto3";

package com.android.sdv.sample.vsidl;

message TirePressure {
  uint32 pressure = 1;
}

Definiowanie usług RPC

W Protobuf usługa RPC definiuje zestaw metod, które można wywoływać zdalnie tak, jakby były lokalnymi wywołaniami funkcji. W tym przykładzie zdefiniowano typy wiadomości żądania i odpowiedzi oraz metodę usługi RPC używaną do wysyłania żądania i odbierania odpowiedzi:

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

Gdzie:

  • service identyfikuje zbiór powiązanych metod RPC.
  • rpc identyfikuje pojedynczą metodę RPC z typami wiadomości wejściowych i wyjściowych (odpowiednio SetSeatHeatingRequest i SetSeatHeatingResponse).

Konfigurowanie integracji systemu kompilacji

Aby umożliwić vsidlc wykrywanie definicji Protobuf i zezwolić systemowi kompilacji Androida na ich kompilowanie, musisz umieścić plik Android.bp w najwyższym folderze katalogu.

Ten plik musi definiować cel rust_protobuf, który grupuje pliki Protobuf (z rozszerzeniem .proto). Każdy plik w katalogu musi być uwzględniony w grupie plików. Jeśli w pliku Android.bp jest kilka grup plików, vsidlc wybiera pierwszą z nich.

Ten przykład przedstawia typowy cel rust_protobuf dla katalogu 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: ["**/*"],
  }

Gdzie:

  • name: unikalny identyfikator celu kompilacji. Zgodnie z konwencją zaczyna się od lib.
  • crate_name: nazwa wygenerowanego pakietu Rust.
  • protos: lista wszystkich plików Protobuf w katalogu. Obsługiwane są globy, np. **/*.proto.
  • rustlibs: musi zawierać libvsidl_v1_proto_rs, aby udostępniać standardowe adnotacje i typy SDV.
  • proto_flags: służy do określania ścieżek dołączania. Aby rozwiązać standardowe typy Protobuf, często wymagany jest parametr -I external/protobuf/src.
  • min_sdk_version: ustaw na "35" (Android 15), aby zadeklarować zgodność z odpowiednimi interfejsami API platformy SDV i wymaganiami łańcucha narzędzi Rust.
  • filegroup: wymagane do wykrywania w czasie kompilacji. Dołącz wszystkie pliki VSIDL, Protobuf i Android.bp do srcs, aby system kompilacji mógł je skopiować do piaskownicy kompilacji.

Co dalej?

Aby kontynuować implementowanie architektury usługi, zapoznaj się z artykułem Definiowanie architektury usługi.