|  | Extensions: adding new types to traces | 
|  | ====================================== | 
|  |  | 
|  | NOTE: **extensions are work-in-progress and are not ready to be used at the | 
|  | moment** | 
|  |  | 
|  | Currently, it is not possible to add new types to traces while using Perfetto | 
|  | without modifying Perfetto proto message definitions upstream. | 
|  |  | 
|  | This page describes ongoing work to use [protobuf | 
|  | extensions](https://developers.google.com/protocol-buffers/docs/overview#extensions) | 
|  | in order to make it possible to define new typed messages outside of the | 
|  | Perfetto repository. | 
|  |  | 
|  | Protozero support | 
|  | ----------------- | 
|  |  | 
|  | Perfetto uses its own implementation of code generation for protocol buffer | 
|  | messages called [Protozero](/docs/design-docs/protozero.md), which is not a | 
|  | full-fledged protobuf implementation. Implementation of extensions is fairly | 
|  | limited, and all extensions are supposed to be nested inside a message that is | 
|  | used in order to provide the class name for generated code. | 
|  |  | 
|  | For example, | 
|  |  | 
|  | message MyEvent { | 
|  | extend TrackEvent { | 
|  | optional string custom_string = 1000; | 
|  | } | 
|  | } | 
|  |  | 
|  | Is going to generate a subclass of `TrackEvent` called `MyEvent`, that is going | 
|  | to have a new method to set `custom_string` in addition to all other protobuf | 
|  | fields defined in `TrackEvent`. | 
|  |  | 
|  | Deserialization | 
|  | --------------- | 
|  |  | 
|  | When analyzing traces, protos are not used directly and instead are parsed into | 
|  | database, which can be queried by SQL. In order to make it possible, Perfetto | 
|  | has to know field descriptors (the binary representation of the extended proto | 
|  | schema) of the extensions. Currently, the only way to do that is to add an | 
|  | [ExtensionDescriptor | 
|  | packet](reference/trace-packet-proto.autogen#ExtensionDescriptor). In the | 
|  | future, there is going to be a way to specify protobuf extensions at compile | 
|  | time in order to be able to avoid this overhead in every single trace. | 
|  |  | 
|  | However, an ability to specify extension descriptors in the trace itself will | 
|  | still be useful in order to be able to use a pre-compiled trace processor in the | 
|  | UI when adding new typed messages during local development. | 
|  |  | 
|  | Deserialization of protobuf extension are supported only for TrackEvent message | 
|  | at the moment, and is implemented in trace processor via ProtoToArgsUtils class. | 
|  | The extensions will appear in args table, similar to other trace event | 
|  | arguments. | 
|  |  | 
|  | Testing extensions support inside Perfetto | 
|  | ------------------------------------------ | 
|  |  | 
|  | Perfetto trace processor is mostly tested by integration tests, where input | 
|  | traces are specified most frequently in textproto format. Textproto format | 
|  | supports extensions, but the parser has to be aware of all the extensions used. | 
|  | In order to make it possible, all the extensions that are used in integration | 
|  | tests have to be specified in the `test_extensions.proto` file. Since this file | 
|  | is only used in the testing harness and is parsed by protoc, it does not have to | 
|  | adhere to the convention of all extensions being inside a wrapper message, which | 
|  | helps with making extension identifiers more concise. |