تحديد الرسائل وخدمات RPC

يعمل نظام الأنواع في VSIDLC على مستويَين: Protobuf وVSIDL. يتم استخدام Protobuf لتحديد الرسائل التي يتم تبادلها بين الناشر والمشتركين المحددين بواسطة VSIDL. تشير VSIDL إلى الأنواع التي تم تعريفها بواسطة بروتوكول buffer.

توضّح هذه الصفحة كيفية تحديد الرسائل وطُرق استدعاء الإجراء عن بُعد (RPC) والردّ على الطلبات.

تحديد الرسائل

يوضّح هذا القسم كيفية تحديد الرسائل في VSIDL وprotobuf.

يحدّد نموذج الرمز التالي رسالة TirePressure:

syntax = "proto3";

package com.android.sdv.sample.vsidl;

message TirePressure {
  uint32 pressure = 1;
}

تحديد خدمات RPC

في مخزن البروتوكولات المؤقتة، تحدّد خدمة استدعاء الإجراء عن بُعد (RPC) مجموعة من الطرق التي يمكن استدعاؤها عن بُعد كما لو كانت عمليات استدعاء دالة محلية. يحدّد المثال التالي أنواع رسائل الطلبات والردود وطريقة خدمة استدعاء الإجراء عن بُعد المستخدَمة لتقديم طلب وتلقّي رد:

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

المكان:

• يمثّل service مجموعة من طرق RPC ذات الصلة.
• يحدّد rpc طريقة واحدة لاستدعاء الإجراء عن بُعد مع أنواع رسائل الإدخال والإخراج (SetSeatHeatingRequest وSetSeatHeatingResponse على التوالي).

ضبط عملية دمج نظام التصميم

لتمكين vsidlc من اكتشاف تعريفات protobuf والسماح لنظام التصميم في Android بتجميعها، يجب تضمين ملف Android.bp في المجلد الأعلى مستوى في دليل الكتالوج.

يجب أن يحدّد هذا الملف هدف rust_protobuf يجمع ملفات protobuf الخاصة بك (مع الامتداد .proto). يجب أن يكون كل ملف في الكتالوج مضمّنًا في مجموعة ملفات. إذا كانت هناك عدة مجموعات ملفات في ملف Android.bp، سيختار vsidlc المجموعة الأولى.

يعرض المثال التالي استهدافًا نموذجيًا rust_protobuf لكتالوج 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: ["**/*"],
  }

المكان:

• name: معرّف فريد لهدف الإصدار، ويبدأ عادةً بـ lib.
• ‫crate_name: اسم حزمة Rust التي تم إنشاؤها.
• protos: قائمة بجميع ملفات protobuf في الكتالوج يمكن استخدام أنماط مطابقة عامة مثل **/*.proto.
• rustlibs: يجب تضمين libvsidl_v1_proto_rs لتوفير التعليقات التوضيحية والأنواع العادية لـ SDV.
• ‫proto_flags: تُستخدَم لتحديد مسارات التضمين، وغالبًا ما يكون -I external/protobuf/src مطلوبًا لحلّ أنواع protobuf العادية.
• استبدِل min_sdk_version بالقيمة "35" (Android 15) لتحديد التوافق مع واجهات برمجة التطبيقات الخاصة بمنصة المركبات المحدّدة البرامج ومتطلبات مجموعة أدوات Rust.
• filegroup: مطلوبة لاكتشاف العناصر في وقت التصميم. يجب تضمين كل ملف VSIDL وprotobuf وAndroid.bp في srcs كي يتمكّن نظام التصميم من نسخها إلى بيئة الاختبار المعزولة الخاصة بالتجميع.

الخطوات التالية

لمواصلة تنفيذ بنية الخدمة، اطّلِع على تحديد بنية الخدمة.