Protobuf modules

The build system supports generating protobuf interfaces through the rust_protobuf module type.

Basic protobuf code generation is performed with the rust-protobuf crate. To view documentation on this usage, see the GitHub project page with corresponding protobuf examples.

gRPC protobufs are also supported, with generation provided by the grpc-rs crate. To view documentation on this usage, see the documentation on the corresponding gRPC GitHub project page.

Basic rust_protobuf build usage

The following provides an example of defining a protobuf module and using that module as a crate. More details on important properties and how they're used are in the Defining a rust_protobuf section.

If you need to use protobuf generated code through an include!() macro, such as for third-party code, see the Source Generators page for an example. (The example uses a rust_bindgen module, but the means of source inclusion is the same for all source generators.)

Define a rust_protobuf Android.bp module

Assume some proto at src/protos/my.proto relative to your Android.bp; the module is then defined as the following:

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",

A library that uses this crate is defined by referencing it as if it were any other library dependency:

rust_binary {
    name: "hello_rust_proto",
    srcs: ["src/"],
    rustlibs: ["libmy_proto"],

Crate structure of rust_protobuf modules

Each protobuf file is organized as its own module within the crate, taking the name of the protobuf file. This means all proto base filenames must be unique. For example, take a rust_protobuf defined as follows:

rust_protobuf {
    name: "libfoo",
    crate_name: "foo",
    protos: ["a.proto", "b.proto"],
    grpc_protos: ["c.proto"],
    source_stem: "my_proto_source",

The different protos within this crate would be accessed as follows:

// 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

Notable rust_protobuf properties

The properties defined below are in addition to the Important common properties that apply to all modules. These are either particularly important to Rust protobuf modules, or exhibit unique behavior specific to the rust_protobuf module type.

stem, name, crate_name

rust_protobuf produces library variants, so the same requirements exist for these three properties as they do for the rust_library modules. See the rust_library properties for details.


This is a list of relative paths to the protobuf files to generate the protobuf interface. The base filenames must be unique across protos and grpc_protos.


The grpc_protos consists of a list of relative paths to the protobuf files that define grpcs to generate the protobuf interface. The base filenames must be unique across protos and grpc_protos.


source_stem is the filename for the generated source file that can be included. This is a required field definition, even if you're using the bindings as a crate, since the stem property only controls the output filename for the generated library variants. Unlike other source generators, the filename gets prefixed by mod_, making the final filename mod_<stem>. This prevents name collisions with generated sources from each proto.

Additionally, like the bindgen bindings module, the full set of library properties is also available to control the library compilation, although these rarely need to be defined or changed.