BLE OTA Compatibility Testing: Older Apps, Bonded Phones and Firmware Rollback

A clean phone connecting to new firmware proves little about an existing customer’s upgrade. That customer may retain an old app, a bond, a discovered database and active subscription history. BLE OTA acceptance should preserve those conditions and verify the operations the product promises. This article defines a test and evidence framework. All matrix rows are proposed cases, with execution results left unfilled.

Declare Supported Versions and State Histories

Name the supported phone models, OS builds, app releases, hardware revisions and firmware transitions. Define “older app” using a release identifier rather than a relative label. Include the oldest app still supported and any intermediate release with a different parser or connection manager. Keep unsupported combinations in the plan when their refusal behavior matters to users.

Then define history: newly installed, previously connected without a bond, bonded before the update, subscribed before disconnect, or restored from the app’s own persisted state. Record which side retains which information. A test begins with this history, not merely with a firmware version. Cache behavior has explicit conditions in Bluetooth Core 6.3 GATT §2.5.2; an acceptance plan must not assume all phones use the same mechanism.

Write the product promise in operational terms: for example, supported legacy clients must read the original measurement and execute an authorized setting change without clearing user state.

Build a Risk-Based Compatibility Matrix

Avoid both extremes: testing only the newest phone, or claiming to cover every Cartesian combination without resources. Select mandatory crossings from protocol changes, installed population and consequence of failure. Pairwise reduction can help with lower-risk dimensions, but it should not eliminate a known interaction such as old app, changed database and retained bond.

For each omitted combination, record the reason and the risk owner. A matching Bluetooth chipset alone is a weak reason to treat two phone software stacks as interchangeable. Keep phone availability gaps visible rather than replacing an untested device with a presumed equivalent.

Preserve the Pre-Update State

Build the old state through the real app. Discover services, establish the product’s required security, complete a known read and enable a business subscription. Save the returned service list, selected characteristic references, relevant CCCD observations and a recognizable data sequence. Establish that the baseline works before attempting the transition.

1. Assign a case ID and record all versions plus the intended initial history.
2. Capture baseline business operations on the old firmware and save the database manifest.
3. Perform the actual supported update while retaining the specified phone and device state.
4. Run the first post-update connection without clearing app data or deleting bonds.
5. Archive evidence before any recovery action, then record that action as a distinct experiment.

Flashing through a debugger may erase settings or change the boot path. If that is used for setup, document its effect and still exercise the production update path for the release claim.

Define Rediscovery and Business-Level Pass Criteria

Define pass criteria above the connection callback. The discovery result must contain the expected service instances and required characteristics. Reads must have the correct length, unit, sign and validity interpretation. A permitted write must produce the specified device effect and completion evidence. Notifications must resume with the expected content and ordering policy over a declared observation window.

For Android API 31 and later, onServiceChanged documentation provides a rediscovery callback contract. Capture the callback, discovery completion and replacement of application references where applicable. On other supported platforms, instrument the platform’s documented flow; do not require this Android callback universally.

Set recovery deadlines from the product requirement before execution. Record the timing start event, end event and exclusion rules. A timer that starts after rediscovery has already completed cannot measure total recovery. Also exercise rejected control operations: an unsupported or unauthorized write must leave the controlled state unchanged, with an understandable error path.

Test Interrupted Sessions and Supported Rollback

Cover an update while the phone is disconnected, first connection after reboot, app background-to-foreground recovery and interrupted business sessions around the transition. Specify whether an in-flight command is canceled, completed or reported as indeterminate. Avoid automatically replaying a non-idempotent command simply because a connection was re-established.

Run firmware rollback only when the bootloader, security-version policy and product support rules permit it. The relevant case begins with state produced by the newer firmware and ends with the older supported contract. Check whether capabilities, subscriptions, stored app data and authorized operations still agree. Keep an explicitly forbidden rollback out of the execution plan and verify its supported refusal path elsewhere.

This is GATT and app-state acceptance. Image transport, signature validation and general power-loss rollback safety require their own tests; success here cannot stand in for them. Likewise, multi-sensor gateway capacity testing measures a different load and reconnection problem.

Capture Evidence for Each Failure

Use a structured record for every run: case ID, initial-state evidence, phone and OS, app build, firmware hashes, database manifests, exact actions, expected result, observed result, timestamps, logs, captures, cleanup and disposition. Results should remain “not run” until the relevant evidence exists. Keep failure traces even when the next run passes.

A usable failure bundle links the first unexpected event to the preceding successful boundary. Attach the app event stream, device log and available HCI or air capture using a shared marker. Name missing capture layers and clock uncertainty. Sanitize identifiers and payloads before sharing outside the authorized team; do not remove the state information that explains the bug.

If deleting a bond restores operation, record both the original failed case and the successful workaround. They answer different questions. Route the original evidence to the cache and bond diagnostic procedure rather than overwriting the failure with a green rerun.

Define Release Blockers and Regression Entry Points

Agree release blockers before testing. Suggested blockers include a wrong control action, silently misinterpreted measurements, unrecoverable security state within a supported path, and loss of required functionality without the promised recovery. A cosmetic issue and a command with a changed meaning should not share an undifferentiated “minor defect” category.

For every fix, return to the original failing history, then test adjacent high-risk matrix rows. Confirm the implementation still matches the declared GATT compatibility contract. Report executed sample counts, open defects, untested combinations and approved exceptions. Passing selected devices is evidence within that declared scope, not universal compatibility or certification.

To prepare an Obeita compatibility assessment, provide the target phone population, supported app and firmware list, rollback policy and critical business operations. Those inputs make the release decision concrete without inventing timing results or success percentages.