We were trying to interface with bluez (the Linux kernel Bluetooth stack, which exposes a D-Bus API) in order to communicate with our device, and no method we tried was able to get past opening the initial connection (no MTU negotiation, no connection interval selection, no service discovery, etc.). It was an old kernel, so it could have been bugs in the bluez implementation from that era, or bugs in the firmware blob of the BLE chipset (it worked on the same hardware running Android, but we didn't verify whether the BLE firmware blob was the same).
The argument in favor of this approach was that it was supposed to look and feel "just like normal Linux" which is where we do most of our development work. Unfortunately, this just isn't the case. I think the two biggest issues are:
1. ubports uses an Android kernel, and although it's 99% pure Linux, Android kernels usually disable a lot of things that your typical Linux machine expects and that some libraries rely on (e.g. most IPC mechanisms). This is really frustrating to work around.
2. This one could just be my lack of experience with these things, but the AppArmor security policies and the weird container setup slowed me down a lot and made the system unpleasant to work on. This didn't really cause an issue, but it made working with the system unpleasant.
