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