For the record, this article is only for those who have some background in Bluetooth development.

Android BLE development is a big pit, with very unstable connections. When a peripheral is connected multiple times, a connection failure occurs. Observation of the log shows that the onClientConnectionState() method frequently has an error code of 133.

1. Why does the error code 133 appear

  • Gatt.close () was not called and the resource was not freed, causing the connection to fail
  • Frequent attempts to establish connections
  • The system has a limit on the maximum number of Ble connections. Generally, the maximum number of Ble connections is 6. If this limit is exceeded, an error code 133 will appear
  • The BLE hardware module is faulty

How to solve it?

2. GATT Closes resources before each connection

// Gatt private BluetoothGatt mGatt; Private void connect(BluetoothDevice device, BluetoothGattCallback callback) {BluetoothGattCallback (); if (SdkUtil.isAtLeastM_23()) { mGatt = device.connectGatt(ViotSDK.getInstance().getBaseContext(), false, callback, BluetoothDevice.TRANSPORT_LE); } else { mGatt = device.connectGatt(ViotSDK.getInstance().getBaseContext(), false, callback); }} public void close() {if (mGatt! = null) { mGatt.disconnect(); mGatt.close(); mGatt = null; }}Copy the code

3. If error code 133 is displayed, configure a retry policy

In the Gatt connection callback, if the connection fails and the error code is 133, retry the connection

Private static int GATT_CONNECT_RETRY_MAX_COUNT = 3; private static int GATT_CONNECT_RETRY_MAX_COUNT = 3; private int retryCount = 0; private class BleCallback extends BluetoothGattCallback { @Override public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) { super.onConnectionStateChange(gatt, status, newState); If (bluetoothgatt.gatt_success == status) {// Gatt connection successful} else {// Gatt connection failed // Connection failed Need to release resources close(); If (status == 133 && retryCount < GATT_CONNECT_RETRY_MAX_COUNT) {// 133 Error code Retry connect(deviice, callback); }}}}Copy the code

Since the device Rom is customized by the company system group, the operation of bluetooth switch is authorized. We can restart the device bluetooth during the retry process to release the Bluetooth connection more thoroughly.

Private static int GATT_CONNECT_RETRY_MAX_COUNT = 3; private static int GATT_CONNECT_RETRY_MAX_COUNT = 3; prvate int retryCount = 0; private Handler handler = new Handler(Looper.myLooper()); private class BleCallback extends BluetoothGattCallback { @Override public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) { super.onConnectionStateChange(gatt, status, newState); If (bluetoothgatt.gatt_success == status) {// gatt connection successful} else {// Gatt connection failed // release resources close(); If (status = = 133 && retryCount < GATT_CONNECT_RETRY_MAX_COUNT) {if (BluetoothUtil. SwitchBlueState (false)) {/ / off bluetooth Handler. PostDelayed (() - > {the if (BluetoothUtil. SwitchBlueState (true)) {/ / 5 s, @override public void run() {connect(deviice, callback) {connect(deviice, callback); }}, 5000); } else {// Reopening Bluetooth failed connectDeviceError(); }}, 5000); } else {// Disable Bluetooth failed connectDeviceError(); } } } } private void connectDeviceError() { } }Copy the code

Bluetooth operation class, BluetoothUtil

public class BluetoothUtil { private static final String TAG = BluetoothUtil.class.getSimpleName(); Public static Boolean switchBlueState(Boolean isOpen) {BluetoothAdapter adapter = BluetoothAdapter.getDefaultAdapter(); boolean suc; if (isOpen) { suc = adapter.enable(); Log.d(TAG, "open blue suc :" + suc); } else { suc = adapter.disable(); Log.d(TAG, "close blue suc :" + suc); } return suc; }}Copy the code

4、 FastBLe

Address: github.com/Jasonchenli…

FastBLe is an excellent BLE open source library with 4.4K Star on GitHub. It supports reconnection mechanism and connects devices stably.

5, summary

After repeated optimization, it was found that the occurrence of 133 error codes could not be completely eliminated, but could only be reduced. This problem also depends on the model. The Mi connection I tried is relatively stable, and OPPO often appears. In Ble development, it is easy to encounter. You still need Google at the protocol level and device vendors at the hardware level to optimize. What development can do is to improve the stability of Ble connections as much as possible. If you have a better idea, feel free to discuss it in the comments section

reference

Stackoverflow.com/questions/2…

medium.com/@martijn.va…

www.zhihu.com/question/24…

Github.com/Jasonchenli…