Система сборки поддерживает генерацию интерфейсов protobuf через тип модуля rust_protobuf .
 Базовая генерация кода Protobuf выполняется с помощью контейнера rust-protobuf . Документацию по этому использованию можно найти на странице проекта GitHub с соответствующими примерами Protobuf.
 Также поддерживаются буферы данных gRPC protobuf, генерация которых осуществляется с помощью контейнера grpc-rs . Документацию по этому использованию см. на странице соответствующего проекта gRPC на GitHub .
Использование базовой сборки rust_protobuf
 Ниже приведён пример определения модуля protobuf и использования этого модуля в качестве контейнера. Подробнее о важных свойствах и их использовании см. в разделе «Определение rust_protobuf .
 Если вам нужно использовать код, сгенерированный protobuf, через макрос include!() , например, для стороннего кода, см. пример на странице «Генератор исходного кода» . (В примере используется модуль rust_bindgen , но способ включения исходного кода одинаков для всех генераторов исходного кода.)
Определить модуль rust_protobuf Android.bp
 Предположим, что некий proto находится в src/protos/my.proto относительно вашего Android.bp; тогда модуль определяется следующим образом:
rust_protobuf {
    name: "libmy_proto",
    // Crate name that's used to generate the rust_library variants.
    crate_name: "my_proto",
    // Relative paths to the protobuf source files
    protos: ["src/protos/my.proto"],
    // If protobufs define gRPCs, then they should go in grpc_protos
    // instead.
    // grpc_protos: ["src/protos/my.proto"],
    // 'source_stem' controls the output filename.
    // This is the filename that's used in an include! macro.
    source_stem: "my_proto_source",
}
Библиотека, использующая этот контейнер, определяется путем ссылки на него, как если бы это была любая другая библиотечная зависимость:
rust_binary {
    name: "hello_rust_proto",
    srcs: ["src/main.rs"],
    rustlibs: ["libmy_proto"],
}
Структура ящика модулей rust_protobuf
 Каждый файл protobuf организован как отдельный модуль внутри контейнера, используя имя файла protobuf. Это означает, что все имена базовых файлов protobuf должны быть уникальными. Например, возьмём rust_protobuf определённый следующим образом:
rust_protobuf {
    name: "libfoo",
    crate_name: "foo",
    protos: ["a.proto", "b.proto"],
    grpc_protos: ["c.proto"],
    source_stem: "my_proto_source",
}
Доступ к различным прототипам в этом ящике будет осуществляться следующим образом:
// use <crate_name>::<proto_filename>
use foo::a; // protobuf interface defined in a.proto
use foo::b; // protobuf interface defined in b.proto
use foo::c; // protobuf interface defined in c.proto
use foo::c_grpc; // grpc interface defined in c.proto
Известные свойства rust_protobuf
 Свойства, определённые ниже, дополняют важные общие свойства , применимые ко всем модулям. Они либо особенно важны для модулей Rust protobuf, либо демонстрируют уникальное поведение, характерное для модуля типа rust_protobuf .
стебель, имя, имя_ящика
 rust_protobuf создаёт варианты библиотеки, поэтому к этим трём свойствам применяются те же требования, что и к модулям rust_library . Подробности см. в свойствах rust_library .
протос
 Это список относительных путей к файлам protobuf для генерации интерфейса protobuf. Базовые имена файлов должны быть уникальными в protos и grpc_protos .
grpc_protos
 Файл grpc_protos содержит список относительных путей к файлам protobuf, которые определяют grpcs для генерации интерфейса protobuf. Базовые имена файлов должны быть уникальными для protos и grpc_protos .
source_stem
 source_stem — это имя сгенерированного исходного файла , который может быть включён. Это обязательное определение поля, даже если вы используете привязки в качестве контейнера, поскольку свойство stem управляет только именем выходного файла для сгенерированных вариантов библиотеки. В отличие от других генераторов исходного кода, к имени файла добавляется префикс mod_ , что делает его итоговым именем mod_<stem> . Это предотвращает конфликты имён с сгенерированными исходными файлами из каждого прототипа.
Кроме того, как и модуль привязок bindgen, полный набор свойств библиотеки также доступен для управления компиляцией библиотеки, хотя их редко требуется определять или изменять.
