* BluetoothHciTimeoutReported is logged when Bluetooth controller
failed to respond to an HCI command in time
* BluetoothQualityReportReported is logged when Bluetooth controller
sends a link quality report event to Android host due to bad link
quality
* BluetoothManufacturerInfoReported is logged when we learn about
manufactuer defined metadata for a device such as manufactuer name
model number, software version, and hardware version
* BluetoothRemoteVersionInfoReported is logged when we learn about
the manufactuer and Bluetooth version of remote Bluetooth controller
and stack
* BluetoothSdpAttributeReported is logged when we learn about services
provided by the remote device and their metdata such as protocol
version and feature bitmask. Only profiles that use 16-bit UUIDs are
logged
* BluetoothBondStateChanged is logged when Bluetooth bonding state is
changed a a macro level such as none -> bonding, bonding -> bonded,
and user interaction events such as passkey confirmation
* BluetoothClassicPairingEventReported is logged from native layer
when Bluetooth classic pairing state changed due to HCI command
or events. This is a more verbose level logging compared to
BluetoothBondStateChanged
* BluetoothSmpPairingEventReported is logged from native layer when
Bluetooth Security Manager Protocol based pairing state changed due to
SMP command sent or received. Pairing failure reason code is also
logged as a pre-defined enum
Bug: 112969790
Test: test drive with statsd
Change-Id: I94d1530758f79ce6d5f119426b1379c76517afec
Merged-In: I94d1530758f79ce6d5f119426b1379c76517afec
(cherry picked from commit 1021a61081)
Conventions for the protos in this directory:
-
As in the rest of Android, use 4 spaces to indent instead of 2.
-
For protos based on Java files, use the same package as the Java file. For example,
com.android.server.thinginstead ofcom.android.server.thing.proto. -
If the proto describes the top level output of dumpsys, it should contain
Dump. This makes it easy to understand that the proto is the dumpsys output of a certain service, not the data structure of that service, e.g.WindowManagerServiceDumpProtovsWindowManagerServiceProto.- Inner messages whose containing messages have the
Protosuffix do not need to have aProtosuffix. E.g:
- Inner messages whose containing messages have the
message FooProto {
message Bar {
...
}
}
vs
message FooProto {
message BarProto {
...
}
}
-
If the proto represents the structure of an object, it should have
Protoas its suffix. Please also include the full package path of the original object as a comment to the proto message. -
Include units in the field names. For example,
screen_time_msvsscreen_time, orfile_size_bytesorfile_size_mebibytesvsfile_size. -
Leave field numbers 50,000 - 100,000 reserved for OEMs.