Bulk move omnipod.dash.driver package to omnipod.common.bledriver

[jwoglom]

To prepare for future Omnipod 5 support in AndroidAPS, we will want to share code between DASH pods and Omnipod 5 due to the common similarities across the bluetooth stack. On the iOS LoopKit side, we are doing similar code reuse with DASH to avoid building a brand new driver from scratch.

This PR moves the package name app.aaps.pump.omnipod.dash.driver to app.aaps.pump.omnipod.common.bledriver to prepare for future Omnipod 5 driver development. It should not have any functional changes.

[sonarqubecloud]

Quality Gate failed

Failed conditions
D Security Rating on New Code (required ≥ A)
B Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[xitation]

Any chance we could look at using this BLE library, which is used by xDrip - https://github.com/dariuszseweryn/RxAndroidBle ?

I know in the early days of DexDrip and then after it became xDrip, it had many of the same ongoing issues with BLE that the DASH has been having. However after moving to this library I understand it helped reduce ongoing issue with BLE connections and timeouts.

In case there is any interest, I've used Claude code to evaluate both code bases and come up with a migration plan to use this library. Happy to share if it can provide any ideas or inspiration on the approach on how we could migrate to it.

My concern with just using the existing driver architecture is we will just perpetuate in the community the ongoing issues with BLE, moving into OmniPod 5. Ideally if this is fixed now, it could benefit both OmniPod pumps and reduce the ongoing BLE issue in the community. As well as improve flexibility with other BLE device interoperability, like allowing "nearby device" permissions again for apps that require them, without the impacts we see at the moment.

[jwoglom]

Any chance we could look at using this BLE library, which is used by xDrip - https://github.com/dariuszseweryn/RxAndroidBle ?

I know in the early days of DexDrip and then after it became xDrip, it had many of the same ongoing issues with BLE that the DASH has been having. However after moving to this library I understand it helped reduce ongoing issue with BLE connections and timeouts.

In case there is any interest, I've used Claude to evaluate both code bases and come up with a migration plan to use this library. Happy to share if it can provide any ideas or inspiration on the approach on how we could migrate to it.

My concern with just using the existing driver architecture is we will just perpetuate in the community the ongoing issues with BLE, moving into OmniPod 5. Ideally if this is fixed now, it could benefit both OmniPod pumps.

I haven't personally used DASH with AndroidAPS so i can't speak to the severity of issues which others are having, and my initial impulse is definitely to reduce scope. however if we think that migration would help and isn't a nontrivial amount of work I'm not against it. Personally the only android BLE library i have direct experience with is BLESSED (pumpx2 and by extension the Tandem Mobi AAPS driver use it).

[xitation]

Any chance we could look at using this BLE library, which is used by xDrip - https://github.com/dariuszseweryn/RxAndroidBle ?
I know in the early days of DexDrip and then after it became xDrip, it had many of the same ongoing issues with BLE that the DASH has been having. However after moving to this library I understand it helped reduce ongoing issue with BLE connections and timeouts.
In case there is any interest, I've used Claude to evaluate both code bases and come up with a migration plan to use this library. Happy to share if it can provide any ideas or inspiration on the approach on how we could migrate to it.
My concern with just using the existing driver architecture is we will just perpetuate in the community the ongoing issues with BLE, moving into OmniPod 5. Ideally if this is fixed now, it could benefit both OmniPod pumps.

I haven't personally used DASH with AndroidAPS so i can't speak to the severity of issues which others are having, and my initial impulse is definitely to reduce scope. however if we think that migration would help and isn't a nontrivial amount of work I'm not against it. Personally the only android BLE library i have direct experience with is BLESSED (pumpx2 and by extension the Tandem Mobi AAPS driver use it).

I ended up writing a specific guide on how to remove / change / fix / config android to work around the issue :) Not a fix, it's a work around and it breaks stuff in other apps as a result. - https://androidaps.readthedocs.io/en/latest/GettingHelp/BluetoothTroubleshooting.html

This has helped reduce the impact on the community due to BLE issues, but has not completely resolved the problem.

I'm happy to upload my Claude generated fork with it's suggested migration approach if that can help inspire you :)

[xitation]

Here is the output from Claude Code, not suggesting in any way it's accurate or correct, but it might help as a starting point. - https://github.com/xitation/AndroidAPS/tree/Dash-RxAndroidBle/dash-rxandroidble-migration-docs

I was doing this mostly as an experiment, I didn't intend to build or try and run this code base. But use it as a discussion starter with the devs :)

[xitation]

I'm also more than willing to assist with testing any of this development if it will apply to the DASH which is the system I use. I'm technically savvy, but a terrible developer, more a infra/systems engineer :)

My brother runs OmniPod 5's so technically as that develops I can likely get a few pods to test with too.