## Device information

Providers can notify a Seeker about device information via the
[Message Stream](https://developers.google.com/nearby/fast-pair/specifications/extensions/nearby/fast-pair/specifications/extensions/messagestream#MessageStream "Message Stream").

| Message Group Name | Value |
|---|---|
| Device information event | 0x03 |

| Device Information Code Name | Value |
|---|---|
| Model ID | 0x01 |
| BLE address updated | 0x02 |
| Battery updated | 0x03 |
| Remaining battery time | 0x04 |
| Active components request | 0x05 |
| Active components response | 0x06 |
| (Deprecated)Capabilities | 0x07 |
| Platform type | 0x08 |
| Firmware version | 0x09 |
| Current FHN ephemeral identifier | 0x0B |

### Model ID

Model ID information (for
[Retroactively Writing AccountKey](https://developers.google.com/nearby/fast-pair/specifications/extensions/retroactiveacctkey#RetroactivelyWritingAccountKey "Retroactively Writing Account key")) should be
sent to the Seeker when Message Stream connects. For example, `0x03010003AABBCC`
would be:

- 0x03: Device information event
- 0x01: Model ID value
- 0x0003: Additional data, length 3
- 0xAABBCC: Additional data, model ID

### BLE address

BLE address information (for [Retroactively Writing AccountKey](https://developers.google.com/nearby/fast-pair/specifications/extensions/retroactiveacctkey#RetroactivelyWritingAccountKey "Retroactively Writing Account key")), if the
Provider can obtain it, shall also be sent to the Seeker when Message Stream
connects and whenever the address is rotated. For example,
`0x03020006AABBCCDDEEFF` would be:

- 0x03: Device information event
- 0x02: BLE address value
- 0x0006: Additional data, length 6
- 0xAABBCCDDEEFF: Additional data, BLE address

### Battery updated

For Providers that support [battery notifications](https://developers.google.com/nearby/fast-pair/specifications/extensions/batterynotification#BatteryNotification "Battery Notification"),
battery information can also be sent via Message Stream. When Message Stream
connects or the battery value changes, an update should be sent. The additional
data section of the packet should contain identical data to bytes
*s + 2* , *s + 3* , *s + 4* when advertising battery data over BLE. For example,
`0x0303000357417F` would be:

- 0x03: Device information event
- 0x03: Battery value
- 0x0003: Additional data, length 3
- 0x57417F: Additional data, battery values
  - 0x57: Left bud value, not charging, 87% battery
  - 0x41: Right bud value, not charging, 65% battery
  - 0x7F: Case value, not charging, unknown battery

Providers can also update remaining battery time (if known), For example,
`0x03040001F0` would be:

- 0x03: Device information event
- 0x04: Remaining battery time
- 0x0001: Additional data, length 1 (could be 2 for uint16 if needed.)
- 0xF0: Additional data, remaining battery time in minutes, 240 minutes

### Active components

Seekers may sometimes desire to know which components are currently active,
meaning that an action can be taken on them (see [Device actions](https://developers.google.com/nearby/fast-pair/specifications/extensions/deviceaction#DeviceAction "Message Stream: Device Actions")).
When the Provider receives a request containing the
*active components request* code (0x05), a response should be returned within 1
second indicating the Provider's current state. The response will use the
*active components response* code (0x06) and contain additional data indicating
which components are available.

For a Provider with a single component, the additional data should be set to
0x00 if it is not available. An example of this might be a low power mode where
media playback will not be performed. Otherwise, additional data should be set
to 0x01.

For headsets with multiple components (for example, a left and right bud), each
bit in the additional data represents whether that component is active. An
example of an inactive component might be a bud which is in the case and not in
use. Specifically for the left and right bud case:

- 0x00 (0b00000000): Neither bud active
- 0x01 (0b00000001): Right bud active, left inactive
- 0x02 (0b00000010): Left bud active, right inactive
- 0x03 (0b00000011): Both buds active

### Platform Type

Providers may want to perform differently based on the platform that they are
connected to. Fast Pair is currently only performed through Android, but support
may be expanded in the future.

The message will contain a first byte identifying platform type in the
additional data:

| Platform Name | Value |
|---|---|
| Android | 0x01 |

The second byte will be customized per platform. In Android, it will refer to the
[SDK version](https://source.android.com/setup/start/build-numbers). For
example, Android Pie will have a value of 28 (0x1C).

### Firmware version

The provider's firmware version as a string in utf-8 encoding.
It's the same information as in the [Firmware revision characteristic](https://developers.google.com/nearby/fast-pair/specifications/characteristics#FirmwareRevision "Firmware revision characteristic").

### Current FHN Ephemeral Identifier

Providers that advertise FHN frames should report the current FHN Ephemeral
Identifier (EID) with their current clock value to sync with the Seeker in case
of a clock drift (for example, due to drained battery).

For example:

- 0x03: Device information event
- 0x0B: Current FHN ephemeral identifier message
- 0x0018: Additional data, length 24 or 36 bytes
- 0x13F9EA80: Additional data (clock value; 4 bytes)
- 0x1122334455667788990011223344556677889900: Additional data (current EID; 20 or 32 bytes)