[yorha59]

Problem

After BLE key storage is reloaded, subsequent successful pairings can stop being persisted to /int/.bt.keys. This occurs when changed/missing/invalid keys cause the keys-reload path to recreate BleGlue. Subsequent NVM notifications are skipped until the callback is registered again; a reboot can therefore lose newly established bonds while peers retain their keys.

Root cause

Source references below are against upstream dev at 3060cee9bac71d332dc7629191ae1aeb1edaac33 (before this patch):

• applications/services/bt/bt_service/bt.c:64-75 schedules a keys/settings reload when the SD card mounts. bt_handle_reload_keys_settings() (498-502) calls bt_load_keys() (449-465), which clears bt->current_profile when the keys change, then bt_start_application() (467-482) calls furi_hal_bt_change_app().
• targets/f7/furi_hal/furi_hal_bt.c:241-249: furi_hal_bt_change_app() calls furi_hal_bt_reinit() (202-239), which calls ble_glue_stop() and then furi_hal_bt_init() → ble_glue_init() (59).
• targets/f7/ble_glue/ble_glue.c:39-47,54-62 stores the callback/context in the heap-allocated BleGlue instance. ble_glue_stop() frees it (258-259); ble_glue_init() allocates a new instance (73). The callback registration is therefore lost across reinitialization.
• The explicit profile-switch path re-registers the callback (bt.c:414), but the keys-reload path does not. The SHCI_SUB_EVT_BLE_NVM_RAM_UPDATE handler (ble_glue.c:360-369) silently skips delivery if the callback is NULL.
• Initial service startup also registers the callback only after bt_init_keys_settings() (bt.c:533-534), leaving later updates within that keys/settings initialization without a registered listener. This patch does not claim to capture every cold-start SHCI event before the first radio-stack startup.

User-visible trigger

SD remount via USB MSC → keys reload (when key storage is missing or changed) → BLE profile/stack reinitialization → subsequent NVM updates are not saved until callback re-registration → a reboot can lose the newly established bonds. SD remount alone does not guarantee reinitialization: the keys-changed condition must be satisfied. A missing or changed .bt.keys can trigger the same reload path.

Previously reported peer-side symptoms (from the old fork; not specific proof of this root cause) include macOS CBError Code 14 ("Peer removed pairing information") and device-side SMP status 3 (ENCRYPT_FAILED).

Evidence — prior 1.4.3-based fork hardware observations

The reporter validated this on a fork based on official 1.4.3:

• Instrumented logs showed two pairing-related NVM updates (88 B and 324 B) arriving with a NULL callback, even though pairing completed.
• With the fix (1.4.3-based commit 423b1490), /int/.bt.keys was non-zero (448 bytes), and encrypted automatic reconnection worked after reboot.

These are prior reporter-provided hardware/serial-log observations from the old 1.4.3-based fork (including its Just Works configuration), not new tests performed for this dev port or proof of default-security behavior. The 448-byte non-zero file demonstrates a write only; its size is not an acceptance criterion for current dev, whose storage format includes root security keys. Reusing the original bond without pairing again is the required functional assertion.

Fix

• Retain the key-storage callback and context in HAL-level static storage when registered.
• Restore them immediately after ble_glue_init(), before radio-stack startup and subsequent GAP/profile/advertising setup during reinitialization.
• Register the initial BtSrv callback before bt_init_keys_settings().

Only these two source files are changed. No new logs or pairing-security/Just Works changes are included.

Reproduction and acceptance steps (target dev; hardware execution pending)

Use a dedicated test device and test peer, record host/firmware versions, and retain event/result logs without key material. Run with upstream default pairing security (confirmation/passkey as applicable); this patch changes no MITM, bonding, IO-capability or encryption settings. Old-fork Just Works results do not establish this coverage.

1. Baseline: cold boot, pair using default security, observe NVM callback → BtSrv queue → successful key save. Reboot and verify encrypted reconnect uses the original bond without a new pairing request.
2. With unchanged valid keys, remount SD: confirm it does not force keys-driven reinitialization and the original bond remains usable.
3. Reproduction: in an isolated test setup, make key storage missing/changed, then remount SD. Confirm the keys-changed check actually triggers BleGlue reinitialization. Pair afterward. Before the fix, subsequent NVM delivery is skipped until re-registration; after the fix, verify reinit → callback → BtSrv queue → save success, then reboot and reuse the bond without pairing again.
4. Repeat serial ↔ HID profile switches and keys reloads. Verify callback restoration each time, with no hangs, crashes or unexpected pairing requests; stress repeated updates/restarts to exercise initialization queue pressure.
5. Boot with SD unavailable, then mount it: verify delayed keys/settings initialization, saving and subsequent encrypted reconnect.

No target-dev hardware regression or queue-stress result is claimed; all five cases remain pending. No physical-device operations were performed for this port.

Build evidence

• Upstream dev base: 3060cee9bac71d332dc7629191ae1aeb1edaac33; built/pushed fix head: 5958aace36095ef8da5979aabbc86c529a8ca84f.
• macOS arm64, bundled fbt toolchain v39; command: ./fbt firmware_all TARGET_HW=7 COMPACT=1 DEBUG=0. Clean build in an isolated upstream worktree with recursively initialized pinned submodules, no old-fork options or security changes.
• Result: exit 0, 53.36 seconds (includes fbt startup/submodule verification). Produced build/f7-firmware-C/firmware.elf, .bin, .hex, .dfu (plus map/metadata); BIN 787848 bytes, SHA-256 dc2659013df9bee3b425e920fe838e73ee1af9628b6033361f641bd589f90572. No flashing performed.
• git diff upstream/dev HEAD --check: passed. Both changed files passed clang-format 23.1.5 --Werror --style=file --dry-run locally. The earlier PR reported a separate clang-format 18.1.8 check; this update does not claim to rerun that version.
• Upstream CI for this exact new head, queried after push: Unit tests: action_required; Lint sources & check submodule integrity: action_required; Static C/C++ analysis with PVS-Studio: action_required; Generate documentation with Doxygen: action_required; Compact build: action_required; Updater test: action_required; Build: action_required. Maintainer action/approval is required before these workflows can validate the new head. Only task-list-completed is currently reported successful by the PR checks; local compilation is not upstream CI or unit-test success. Previous-head workflows required maintainer approval (action_required).
• Target-dev hardware acceptance remains pending as described above; earlier fork evidence is preserved separately.

Why retain the callback in HAL?

The permanent BtSrv owns the callback/context and outlives the BleGlue instance; a source comment documents that lifetime. HAL already exposes registration and controls radio reinitialization. Keeping the registration there covers keys reload, profile restart and direct radio reinit, restoring it before the restarted radio stack runs. Registering only after keys reload would miss startup notifications and other reinitialization callers. This does not add general concurrent replacement or unregister support.