In my app, which uses a proprietary bluetooth device, I'm working on self-correcting some problems that may come up with the device. One of those problems is when the phone thinks it's paired, and the device does not, so it refuses connections until the phone unpairs and re-pairs. Using the answer found here, I got this working in code quite nicely, but I'm a bit concerned over how "safe" this is, since I now have an aidl under android.bluetooth in my own source tree. This seems to work fine in my testing with several 2.2 and 2.3 phones, but am I open to having to rewrite in future versions, or does creating this local aidl actually insulate me from future changes? Pointers to further reading are welcome.
1 Answers
It looks like the answer you linked to is calling private APIs. Be careful doing this as they could change at any time in future versions of Android.
To answer you questions:
but am I open to having to rewrite in future versions?
Yes, because those private APIs could change at anytime without any notice because they are private.
does creating this local aidl actually insulate me from future changes?
No, it won't insulate you. They could change anything in android.os.ServiceManager
or android.bluetooth.IBluetooth
without notice and it would break your code in newer versions of Android.
I sound a bit repetitive, but becareful with private APIs, they might bite you in the future. However, it also sounds like this might be the only way you can do this.

- 27,363
- 32
- 109
- 125
-
That's what I was afraid of :). BT support has been getting better (support for multiple connections with 2.2, the createInsecureRfcommSocketToServiceRecord with 2.3), maybe we'll get a more complete interface in some future rev. Thanks, Greg – gbryant Oct 10 '11 at 15:30
-
@gbryant indeed, I've had to use some private apis for bluetooth for 1.5/1.6 version of android, but as you've said, they have thankfully being make public apis slowly over time for bluetooth. I think you'd be fine with private apis with the hopeful expectation that they will eventually incorporate more of those apis in the future. – Bryan Denny Oct 10 '11 at 15:57