Android ble device bluetooth communication framework Bluetoothkit

The Bluetoothkit is a powerful Android Bluetooth communication framework that supports connection communication, Bluetooth broadcast scanning, and beacon resolution for low power Bluetooth devices.

For detailed documentation on this project, please follow: https://github.com/dingjikerbo/BluetoothKit

For beginners just contact with Android Bluetooth development, will often encounter some strange pits, I also walked all the way, I met some of the pits summed up a bit, these pits in this project are fixed, so you don't have to spend time and effort to repeat the step again. The project is currently being updated, and there are any better suggestions you can make at any time.

bluetooth scan related pits

First, startdiscovery on most mobile phones can be found in the classic Bluetooth and ble, but the startdiscovery callback cannot return to the BLE broadcast, so can not broadcast recognition device, And StartDiscovery scan ble is much less efficient than startlescan. So in practical applications, or startdiscovery and startlescan separate sweep, the former sweep classic Bluetooth, the latter sweep low-power Bluetooth.

Second, Startlescan (), in the Onlescan () can not do time-consuming operation, especially around the BLE device more time, easy to cause the underlying blockage. If there is a time-consuming operation, throw it into the child thread to handle it.

Third, some mobile phone will filter equipment broadcast, a scan process only send a request, if not received response will no longer receive the device broadcast callback, the solution is to sweep several times.

bluetooth connection-related pits

One, the operation of the Bluetooth device can not be parallel, only serial, that is, each time you receive the callback of the last operation before continuing the next operation. But disconnect exception, disconnect to Closegatt immediately, do not wait for other operations in the task queue. and cancel all tasks that are being executed or ready to be executed.

Second, sometimes the Bluetooth protocol stack exception may not receive callbacks, so we have to do a time-out check for each operation, or all subsequent operations are blocked.

Third, for the task of overtime, it is best to Closegatt, the next time re-connect the time to reopen a GATT.

Four, Bluetooth connection may be unstable, it is best to support the failure of the automatic retry mechanism, especially the connection and discovery services, because 80% of the problems occurred in the establishment of connectivity and discovery services, and this piece is the most time-consuming.

When the connection is established, it can be initiated by the device side to change the connection interval, which can speed up the subsequent discovery service and data reading and writing. Some mobile phone Discover service is very slow, because the connect interval is too big, some mobile phones will be active to the device to initiate changes to connect interval, and some mobile phones will not. In this case connect interval difference will be very large, in practice found some cell phone is 7ms, some mobile phone is the default 50ms, so found service to 8s, even 20s is very common, this is unbearable for users. So the better way is the device proactively initiates changes to connect interval

Vi. all operations on the same device should preferably be executed serially on the same thread, preferably not on the UI thread, although these operations are asynchronous and theoretically not time consuming, but it is possible to have ANR because of the cross-process involved. In addition, each device is not recommended to open a thread, the device is more than the contribution of memory will also degrade performance. It is a good practice to open a thread, and all of the device's operations are initiated in that thread, although it occupies the same thread, but each device maintains its own task queue.

Seven, Bluetooth operations are asynchronous, callbacks are usually executed in the binder thread, because this is a cross-process callback back. Be sure to take note of this, or there will be some strange problems. For example writecharacter in the worker thread, but Oncharacterwrite is in the binder thread, callback if the task queue is involved in scheduling must post back to the worker thread processing, otherwise there will be multithreading caused by data inconsistency problem.

Eight, then seventh, in the callback post back to the worker thread processing should be careful not to take a handle, but to bring data. For example, for Oncharacteristicwrite, do not take bluetoothgattcharacteristic, but to take the value of it. Otherwise, some data is omitted and a duplicate set of data may eventually be received. The same problem is also found on the notify.

Nine, when the device firmware upgrade, profile may have changed, but the next time Discover service is the return of the old cache, so read and write character may fail. The workaround is to refresh the cache of the device the next time you connect, after the firmware upgrade. Of course, restarting Bluetooth also refreshes the cache, but affects all devices. In addition, sometimes discoverservice service discovery is incomplete, or can not find the service at all, also consider clearing the cache.

Ten, some mobile phone discoverservice may callback more than once onservicediscover, this should pay attention to defense.

Xi. service do not cache, although the UUID may not change anything, but these service will be associated with GATT, if the GATT changed, the service is scrapped, any read and write operations on these service and character will be wrong. So it is recommended to go to discover service every time you connect, do not cache.

12, firmware upgrade is usually a writing device, in order to speed up the write speed, can be specified in the write character no response flag, the practice found that the speed can be increased by one or more times. However, it is important to note that even with the no response flag, it does not mean that the write operation does not have a callback, we still have to follow the last write callback before the next write operation. The way to improve write speed is to change the MTU and change the connection interval, but changing the MTU hardware does not necessarily support it, and it has to be tried several times.

13, write the time do not specify Writetype, do not specify Writetype does not mean Writetype is write_type_default, in fact the system will automatically according to the property to decide Writetype, if with Property_ Write_no_response property, the Write_type_no_response will be selected automatically, otherwise Write_type_default will be selected.

14, open/close character notify, you must wait until the Ondescriptorwrite callback to calculate the end, to start the next task.

XV, the equipment of the GATT should be closed in time when not used, the system supports the number of connection handles is limited, when the upper limit can no longer establish a new connection.

16, when the connection to adjust Closegatt release resources, do not adjust the disconnect, do not use the GATT before the next time reconnect, because some mobile phones on the re-connected may have problems, such as the re-connected after dead and alive to find service. In this case, it is best to simply disconnect the GATT and open the new GATT the next time you connect, so you can discover the service.

Use

It is very simple to use, add a line of dependencies, and then create a global singleton bluetoothclient, which is called by the detailed interface to refer to the link above.

1. Adding dependencies in Build.gradle

‘com.inuker.bluetooth:library:1.3.8‘

2, create a bluetoothclient, preferably a single case of global use

new BluetoothClient(context);

some of the techniques used

* * First, the realization of a
Complete cross-process asynchronous task queue with support for task timeouts, error retries, and defensive queue overflow * *

Second, intercept and hook the system layer of Bluetooth binder, to achieve the monitoring of all Bluetooth device communication, when the number of simultaneous connected devices will automatically cut off the least active device

The entire framework is encapsulated in one service, with the flexibility to specify the process in which the service resides.

Iv. Shielded interface asynchronous callbacks may hold memory leaks caused by activity references on the calling side

V. Use dynamic agents to automatically close all operations on the worker thread, so the entire frame is unlocked

Android ble device bluetooth communication framework Bluetoothkit