More Bluetooth LE work

[Dirk Hohndel]

Yeah, yeah, yeah, I should have studied the commit messages
more closely and tried this under Linux (which doesn't work for
me right now because I don't run Linux on the hardware, but run
it in a VM under Mac OS and there is no BLE pass through into
the VM).

> On Jun 27, 2017, at 2:07 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> 
>> - in particular, I don't want to change the behavior of the old
>> rfcomm code - I don't have anything that uses it, and it supposedly
>> works fine for others, and it's a more standardized protocol than the
>> BLE GATT hackery of more modern dive computers, so it should remain
>> the default mode for those dive computers that support it.
> 
> Yes it should - but as I said earlier, it would be great to have a "prefer
> BLE flag" for testing.
> 
>> - HOWEVER, when we scan for the dive computers, we can see that some
>> dive computer _only_ supports BLE. When that happens, the first patch
>> in this series will now explicitly mark the bluetooth address with a
>> "LE:" prefix at scan time, which will allow the rfcomm code to realize
>> that it cannot use rfcomm for the device.
> 
> Good - we could then use that to hack that flag that I mentioned earlier.
> Easy enough.

Which we can already do just fine on Linux by editing the address field.
Only we don't have that field on Android - it's all implicit there. I think
I may need to rework the Subsurface-mobile UI a bit more with the two
target OS is mind. On iOS it will be all BLE only, nothing else will be
supported there. And on Android we need a better way to work on
serial vs. BT vs. BLE and knowing which dive computers can actually
be supported...

/D