feat(android): report key missing and link encryption results (0.1.8, 0.1.9)

[originalix]

Summary

Android 16+ no longer removes a bond whose keys the device has lost (device wiped, bond removed on the device). It keeps the bond and only broadcasts android.bluetooth.device.action.KEY_MISSING; GATT just shows a peer disconnect. This release reports that broadcast to JS so the SDK can tell a stale bond from an ordinary disconnect and guide the user to forget the device, instead of looping on "Bluetooth unpaired".

Changes

0.1.8 (this change)

• Register ACTION_KEY_MISSING on API 36+ (string literal, so older compileSdk still builds) and emit a new event onDeviceKeyMissing with the device address.
• New constant supportsKeyMissingEvent / supportsDeviceKeyMissing(): false on older Android and on native builds without this change, so JS never waits for an event that cannot fire.
• pairDevice additionally returns initiated, to tell a bonding this call started from one the system started by itself (Android 17 re-pairs on its own after a lost bond).
• onDeviceKeyMissing subscriptions are removed individually; onDeviceBondState is unchanged.

0.1.7 (already on npm, never merged)

• 2371f8f was published to npm as 0.1.7 from fix/electron-ble-scan-cache without a PR, so main is behind the registry. This branch is stacked on it and brings it into main: it forwards the hidden EXTRA_UNBOND_REASON int on BOND_NONE, which hd-transport-react-native already consumes to classify pairing cancel / timeout.

Compatibility

Additive only: one new event, one new constant, one new optional result field. iOS is untouched. With an older native binary the new JS helpers report unsupported and behave as a no-op.

Verification

• yarn lint, yarn typecheck, yarn test pass.
• :onekeyfe_react-native-ble-utils:compileDebugKotlin builds in the example app.
• Behaviour it relies on was captured on a Pixel 9a (Android 17) with logcat + dumpsys activity broadcasts: KEY_MISSING is an implicit ordered broadcast requiring only BLUETOOTH_CONNECT, enqueued ~15 ms after the ACL drop. Not yet exercised end to end on a device with this native build.

0.1.9 — link encryption results

On Android 16+ the system encrypts a bonded LE link on its own right after connecting. If a request that needs encryption (the notification CCCD write) is sent before that attempt finishes, the framework retries it by encrypting again with the same stale key; Pro 2 firmware tolerates one key failure per link and drops the second, before the system re-pair can finish. HCI captures on a Pixel 9a (Android 17) show this is the whole difference between a dropped attempt and one where the pairing request completes.

• Register ACTION_ENCRYPTION_CHANGE (API 36) and emit onDeviceEncryptionChange { id, status, enabled } for LE links. status is the HCI status: 0 on success, 6 when the peer lost the bond. Verified on device that the broadcast fires ~7 ms after both successful and failed encryptions.
• Register ACTION_ACL_DISCONNECTED and emit onDeviceAclDisconnected { id }, so JS knows when an earlier encryption result stops describing the current link (unlike a GATT disconnect, it does not fire while the system keeps the link for another client).
• New constant supportsEncryptionChangeEvent / supportsDeviceEncryptionChange(); false below API 36 and on older native builds, where neither event fires.
• Constant strings and API levels were read from the API 36 android.jar / api-versions.xml (ACTION_ENCRYPTION_CHANGE, EXTRA_ENCRYPTION_STATUS, EXTRA_ENCRYPTION_ENABLED, ACTION_KEY_MISSING since 36; EXTRA_TRANSPORT since 33). Literals keep older compileSdk building.

Published as 0.1.9 from cc86db8. Consumed by OneKeyHQ/hardware-js-sdk#951.