chore(app): remove legacy flutter_blue_plus BLE transport#7895
Conversation
Greptile SummaryRemoves the legacy
Confidence Score: 5/5Safe to merge — the change is straightforward dead-code removal plus a well-contained new native method; the concurrent-call concern from the previous round has been addressed. The only live behavior change is swapping FlutterBluePlus.turnOn() for BleHostApi().enableBluetooth(), which is correctly guarded, handles all edge cases (already-on, no-activity, launch exception), and resolves via the existing onActivityResult plumbing. Request codes 42 (companion) and 43 (BT enable) don't collide. The rest of the diff is pure deletion of code that was already unreachable. app/android/app/src/main/kotlin/com/friend/ios/BleHostApiImpl.kt — the new enableBluetooth path is the only code not yet validated on a physical Android device per the PR description. Important Files Changed
Sequence DiagramsequenceDiagram
participant Dart as OnboardingProvider (Dart)
participant Pigeon as BleHostApi (Pigeon channel)
participant Native as BleHostApiImpl (Kotlin)
participant Android as Android OS
Dart->>Pigeon: enableBluetooth()
Pigeon->>Native: enableBluetooth(callback)
alt Bluetooth already on
Native-->>Dart: Result.success(true)
else Another request in flight
Native-->>Dart: Result.success(false)
else No activity
Native-->>Dart: Result.success(false)
else Normal path
Native->>Android: startActivityForResult(ACTION_REQUEST_ENABLE, 43)
Android-->>Native: onActivityResult(43, RESULT_OK/CANCELED)
Native-->>Dart: Result.success(true / false)
end
Dart->>Dart: Permission.bluetoothScan.request()
Dart->>Dart: Permission.bluetoothConnect.request()
Reviews (2): Last reviewed commit: "fix(android): guard enableBluetooth agai..." | Re-trigger Greptile |
…ing pending callback
|
@greptile-apps re-review |
What
Removes the legacy
flutter_blue_plus-based BLE transport from the app. Native BLE (NativeBleTransport+NativeBluetoothDiscoverervia Pigeon →OmiBleManageron iOS/Android) has been the only live BLE path for a while; theflutter_blue_plusimplementation was left behind fully intact but disconnected.Why
Dead code reduction. The legacy transport, discoverer, adapter facade, and device-type helpers were never instantiated/called at runtime — the discoverer registry only wires
NativeBluetoothDiscoverer, and the connection factory only buildsNativeBleTransport.Changes
Deleted (dead code):
ble_transport.dart— legacyBleTransport, never instantiatedbluetooth_discoverer.dart— legacyBluetoothDeviceDiscoverer, not in the discoverer registrybluetooth_adapter.dart— theflutter_blue_plusfacadeStripped dead members (files kept):
bt_device.dart— removedgetTypeOfBluetoothDevice,isSupportedDevice,fromScanResult,fromBluetoothDevice, and allis*Device*/*FromDevicehelpers (~195 lines).BtDevice/DeviceType/BleAudioCodecintact.models.dart— removed uncalledgetBleServices/getServiceByUuid/getCharacteristicByUuid. All UUID constants kept.flutter_blue_plusimports inmain.dart,speech_profile_provider.dart,devices.dart.One real refactor — onboarding "enable Bluetooth":
enableBluetooth()to the PigeonBleHostApi(regenerated Dart/Swift/Kotlin stubs). Android firesACTION_REQUEST_ENABLEvia the existing activity-result plumbing; iOS returns the adapter power state.onboarding_provider.dartnow callsBleHostApi().enableBluetooth()instead ofFlutterBluePlus.turnOn()/adapterStateNow.Dependency:
flutter_blue_plusfrompubspec.yaml; marked ittransitivein the lock.Note: package stays transitively
flutter_blue_pluscannot be fully removed —frame_sdk(Frame glasses, used byframe_transport.dart) depends on it transitively. This PR removes our direct dependency and all of our direct usage;lib/now has zeroflutter_blue_plusreferences.Verification
flutter analyze lib→ 0 errors.device_provider_test.dart(BLE-adjacent suite) → 14/14 pass.🤖 Generated with Claude Code