Hi,
First of all, thank you for BTMicFix. The core audio-routing functionality works extremely well on my device and solves a problem that I could not solve with several Play Store audio-routing apps.
Environment:
- BTMicFix v0.2.0
- Realme GT Neo 2 (RMX3370)
- Android 13 / Realme UI 4
- soundcore Liberty 5 Pro earbuds
- Shizuku is not used
Manual routing works correctly:
- "Enable Routing" / "Test Routing" switches the device to BT SCO.
- The earbuds microphone then works system-wide.
- I verified this with the standard Android Recorder and with Gboard voice typing.
- I also left the phone in another room and walked around the apartment while recording; the voice continued to be recorded clearly, confirming that the earbuds microphone was being used.
So the normal setCommunicationDevice() routing path appears to work perfectly on this device.
The problem is the automatic background mode.
Steps to reproduce:
- Connect the Bluetooth earbuds normally.
- Open BTMicFix -> Setup -> Pair Device.
- Put the earbuds into pairing/discoverable mode so that they appear in the Companion Device picker.
- Select the earbuds.
- The picker closes, but the Setup screen does not visibly indicate that the device has been associated.
- Stop the manually enabled routing and close BTMicFix.
- Disconnect and reconnect the earbuds.
Expected:
BTCompanionService should be started by Android when the associated earbuds reconnect, the foreground routing notification should appear, and Bluetooth mic routing should be enabled automatically.
Actual:
Nothing happens in the background. There is no BTMicFix notification and the Bluetooth microphone is not routed. Opening BTMicFix and enabling routing manually immediately makes it work again.
I looked through the v0.2.0 source and noticed something that might explain the problem.
In DeviceCompanionManager.kt, onAssociationCreated() eventually calls:
startObservingPresence(associationInfo.id)
and startObservingPresence() does:
cdm.startObservingDevicePresence(associationId.toString())
Unless I am misunderstanding the API, on Android 13 the String overload of startObservingDevicePresence() expects the address of a previously associated device, not the association ID.
AssociationInfo on API 33 also provides getDeviceMacAddress(), so perhaps this should use something along the lines of:
associationInfo.deviceMacAddress?.toString()
when registering device-presence observation.
There may also be a small UI/state issue: SetupScreen determines whether pairing is complete from preferences.pairedDeviceName, but I could not find where pairedDeviceName / pairedDeviceAddress are populated during the CompanionDeviceManager association flow. This may explain why selecting the earbuds produces no visible "paired" state even if Android actually creates the association.
It might also be useful to surface an error in the UI if startObservingDevicePresence() throws, since currently the exception appears to be caught and only logged.
I would be happy to test a patched APK on this Android 13 / Realme device if that would be useful.
Thanks again for the project. The manual routing functionality already works very well here; only the automatic Companion Device/background part appears to be failing.
Hi,
First of all, thank you for BTMicFix. The core audio-routing functionality works extremely well on my device and solves a problem that I could not solve with several Play Store audio-routing apps.
Environment:
Manual routing works correctly:
So the normal setCommunicationDevice() routing path appears to work perfectly on this device.
The problem is the automatic background mode.
Steps to reproduce:
Expected:
BTCompanionService should be started by Android when the associated earbuds reconnect, the foreground routing notification should appear, and Bluetooth mic routing should be enabled automatically.
Actual:
Nothing happens in the background. There is no BTMicFix notification and the Bluetooth microphone is not routed. Opening BTMicFix and enabling routing manually immediately makes it work again.
I looked through the v0.2.0 source and noticed something that might explain the problem.
In DeviceCompanionManager.kt, onAssociationCreated() eventually calls:
and startObservingPresence() does:
Unless I am misunderstanding the API, on Android 13 the String overload of startObservingDevicePresence() expects the address of a previously associated device, not the association ID.
AssociationInfo on API 33 also provides getDeviceMacAddress(), so perhaps this should use something along the lines of:
when registering device-presence observation.
There may also be a small UI/state issue: SetupScreen determines whether pairing is complete from preferences.pairedDeviceName, but I could not find where pairedDeviceName / pairedDeviceAddress are populated during the CompanionDeviceManager association flow. This may explain why selecting the earbuds produces no visible "paired" state even if Android actually creates the association.
It might also be useful to surface an error in the UI if startObservingDevicePresence() throws, since currently the exception appears to be caught and only logged.
I would be happy to test a patched APK on this Android 13 / Realme device if that would be useful.
Thanks again for the project. The manual routing functionality already works very well here; only the automatic Companion Device/background part appears to be failing.