Why Google TV does not detect bt-mouse Bluetooth HID

Finding. The best match for the observed behavior is not “Google TV receives no advertisement.” It is “Google TV receives the discovery data, fails to classify the phone as an allowed input device, and removes it from the Remote & Accessories list.” A PC or phone usually shows a broad Bluetooth scan result; Google TV's pairing screen is a filtered accessory browser.

The physical-keyboard comparison is important. A real keyboard working on the same TV shows that Bluetooth scanning and HID-host support are present. The remaining difference is the identity published before pairing: a hardware keyboard normally identifies itself as a keyboard or pointing peripheral, while a phone can still look like a phone or an unclassified peripheral even when an app has opened an HID service.

Google TV does not show every discoverable Bluetooth device

Google's help page sends users to Settings → Remote & Accessories → Pair remote or accessory. In AOSP TvSettings, the class used for this screen accepts a device only when both conditions below are true:

major class == PERIPHERAL
and
minor class contains POINTING, KEYBOARD, JOYSTICK, GAMEPAD, or REMOTE

A peripheral with no accepted minor bit does not pass. A device whose major class is PHONE does not pass either. This filtering happens during discovery, before the TV has paired and read the full HID report descriptor. That is why a correct keyboard-and-mouse descriptor can work on a PC and still never reach the selection screen on a TV.

The BLE HOGP path has a concrete classification gap

bt-mouse first asks Android for the Classic HID Device profile. If the proxy is not ready within a bounded grace period, the shared HID layer can fall back to BLE HID over GATT (HOGP). The BLE advertisement contains the HID service UUID 0x1812, the device name when it fits, and optional Microsoft Swift Pair manufacturer data. It does not contain the Bluetooth Appearance advertising field.

AOSP's Bluetooth stack first looks for the Appearance field when it derives a Classic-style Class of Device from a BLE advertisement. The relevant assigned values are:

BLE Appearance	AOSP classification	Google TV result
`0x03C1` HID Keyboard	Peripheral + Keyboard	Accepted
`0x03C2` HID Mouse	Peripheral + Pointing	Accepted
No Appearance, service `0x1812` only	Peripheral + unclassified minor (`0`)	Rejected by the minor-class mask

This makes the BLE failure path direct: service UUID 0x1812 proves that the device offers HOGP, but it is not enough for TvSettings' input-device filter. Without an Appearance value, AOSP assigns the Peripheral major class and leaves the minor byte at zero; the next filter requires a non-zero keyboard, pointing, joystick, gamepad, or remote bit.

Why this is not a simple app-side one-line fix. Android's public AdvertiseData.Builder can add service UUIDs, service data, manufacturer data, and the device name, but it has no API for adding an arbitrary Appearance AD field. A system or vendor API, raw advertising control, or different peripheral hardware is needed to publish that field reliably.

Classic HID has a similar early-identity boundary

On the Classic path, bt-mouse registers BluetoothHidDevice.SUBCLASS1_COMBO with its HID SDP record. That correctly describes a keyboard-and-mouse combination to a host that performs SDP discovery. It is not, however, the same field as the Class of Device delivered in the initial Bluetooth inquiry result.

If a phone or vendor Bluetooth stack continues to advertise the local adapter as PHONE, or as PERIPHERAL without the keyboard/pointing minor bits, Google TV can discard it before querying that SDP record. The exact Classic result is therefore device-dependent: it must be confirmed by observing the phone's actual over-the-air Class of Device. This is a conditional explanation, unlike the missing BLE Appearance path, which is visible directly in the current bt-mouse advertisement construction.

Why a physical Bluetooth keyboard works

A dedicated keyboard controls its Bluetooth controller firmware and its complete discovery identity. A Classic keyboard normally publishes PERIPHERAL with Keyboard or Keyboard/Pointing bits. A BLE keyboard or mouse can publish Appearance 0x03C1 or 0x03C2. Both identities satisfy the same Google TV filter that rejects an unclassified phone-hosted HID service.

There is no contradiction between “Google TV supports physical Bluetooth keyboards” and “Google TV does not list bt-mouse.” HID support answers what the TV can use after connection. The discovery filter answers which devices are allowed to reach pairing in the first place.

How to verify the diagnosis

Identify the active transport. Capture bt-mouse logs while opening pairing. A ble-hogp selection makes the missing Appearance path the primary diagnosis; a Classic selection calls for measuring Class of Device.
Inspect the advertisement. Use a BLE scanner that exposes raw AD structures. Confirm service UUID 0x1812 and check whether AD type 0x19 (Appearance) is absent.
Compare with the working keyboard. Record its Classic Class of Device or BLE Appearance. It should carry the keyboard or pointing classification that the phone advertisement lacks.
Use TV logs when available. ADB logs from the pairing screen can show that the device was scanned but did not satisfy the input-device criteria. Vendor builds may rename or replace the AOSP components.

Practical compatibility options are to prefer a Classic HID path on phone/TV combinations that publish the correct input Class of Device, use a privileged or system-integrated BLE peripheral that can set Appearance, use dedicated HID hardware, or use a TV companion/network protocol instead of Bluetooth pairing. A normal Play-distributed app cannot assume that every phone exposes the low-level identity controls required by this TV filter.

Confidence. High for the BLE HOGP path: the bt-mouse advertisement, AOSP's BLE-to-Class-of-Device mapping, and TvSettings' filter form a complete rejection chain. Medium for Classic HID: the result depends on the phone's actual Class of Device and vendor changes. Google TV manufacturers can modify AOSP, so an over-the-air capture on the affected model remains the final proof.

Official sources

Bluetooth HID tech notes Why Korean/English labels drift bt-mouse product page bt-mouse user manual