Android-BLE-Library: Timeout on first connection and error 133

I can no longer reliably connect to a new peripheral. The connection times out after 30s and then I get error 133. Here’s the logging on the Android side.

2018-11-30 16:04:14.048 11300-11300/? I/ProvisioningActivity: Device C7:56:60:F0:56:58 clicked.
2018-11-30 16:04:14.196 11300-11300/? D/ProvisioningActivity: Device 228892 exists and is unowned. Good.
2018-11-30 16:04:14.205 11300-11300/? I/ProvisioningActivity: Connecting to C7:56:60:F0:56:58
2018-11-30 16:04:14.214 11300-11300/? D/BikeTrackerManager: onDeviceConnecting()
2018-11-30 16:04:14.215 11300-11300/? D/BluetoothGatt: connect() - device: C7:56:60:F0:56:58, auto: false
2018-11-30 16:04:14.215 11300-11300/? D/BluetoothGatt: registerApp()
2018-11-30 16:04:14.215 11300-11300/? D/BluetoothGatt: registerApp() - UUID=f0f74613-fc8c-4347-bdd0-9baa346f1b46
2018-11-30 16:04:14.219 11300-11357/? D/BluetoothGatt: onClientRegistered() - status=0 clientIf=9
2018-11-30 16:04:17.485 11300-11300/? I/chatty: uid=10209(cc.biketracker.android) identical 2 lines
2018-11-30 16:04:44.231 11300-11357/? D/BluetoothGatt: onClientConnectionState() - status=133 clientIf=9 device=C7:56:60:F0:56:58
2018-11-30 16:04:44.237 11300-11300/? D/BluetoothGatt: close()
2018-11-30 16:04:44.237 11300-11300/? D/BluetoothGatt: unregisterApp() - mClientIf=9
2018-11-30 16:04:44.239 11300-11300/? D/BikeTrackerManager: onDeviceDisconnected()
2018-11-30 16:04:44.239 11300-11300/? D/ProvisioningActivity: Disconnected. Presenting alert dialog.
2018-11-30 16:04:44.332 11300-11307/? I/tracker.androi: Compiler allocated 4MB to compile void android.widget.TextView.<init>(android.content.Context, android.util.AttributeSet, int, int)
2018-11-30 16:04:44.341 11300-11300/? D/BikeTrackerManager: onDeviceDisconnected()
2018-11-30 16:04:44.359 11300-11300/? W/AudioTrack: Use of stream types is deprecated for operations other than volume control
2018-11-30 16:04:44.359 11300-11300/? W/AudioTrack: See the documentation of AudioTrack() for what to use instead with android.media.AudioAttributes to qualify your playback use case
2018-11-30 16:04:44.433 11300-11300/? W/AudioTrack: Use of stream types is deprecated for operations other than volume control
2018-11-30 16:04:44.433 11300-11300/? W/AudioTrack: See the documentation of AudioTrack() for what to use instead with android.media.AudioAttributes to qualify your playback use case
2018-11-30 16:04:44.622 11300-11300/? D/LocalBroadcastUtil: Local broadcast message: model changed.
2018-11-30 16:04:44.627 11300-11300/? D/BleBackgroundScanner: Bonded peripherals:
2018-11-30 16:04:44.629 11300-11300/? D/BleBackgroundScanner: No Bike Tracker devices bonded to this phone. Not scanning.
2018-11-30 16:04:44.630 11300-11300/? D/BikeTrackerManager: onError()
2018-11-30 16:04:44.630 11300-11300/? E/ProvisioningActivity: BLE error: 133: Error on connection state change

I’m connecting like this:

bleDeviceManager.connect(selectedBluetoothDevice.getDevice())
                    .retry(3, 200)
                    .useAutoConnect(false)
                    .enqueue();

On the device (peripheral) side, I don’t get any logging for the connection at all. It’s like nothing’s happened on the radio. I don’t have a sniffer dongle to hand to check for sure.

I first saw this on v2.0.0 and have just verified it on v2.0.2. I’ve been able to connect once, without having changed any code on either side, but then after clearing the bond on both sides and testing again, I can’t connect. Turning off the Bluetooth adapter on the phone, rebooting the phone, reflashing the device - nothing seems to put it right. I can repro this with the DK as the peripheral, so it’s not a hardware thing with my device.

I can also connect, and bond, from the nRF Connect app.

Happy to share both the device firmware and the Android app source code privately. Anything else I can check, until I get back to my sniffer and Wireshark?

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 60 (31 by maintainers)

Most upvoted comments

Hi, I did some tests and can confirm the issue. After disconnecting from a bonded device using Pixel 4 with Android 10, and trying to reconnect I was getting error 8 (timeout) (not 133) very often. By using autoConnect=true it finally manage to connect after few tries after which the connection seemed stabled. On next disconnection situation repeated.

There is #232 open, which should improve the behavior on bonded devices, as the first connection attempt would switch to one using autoConnect automatically.

philips77 on Aug 26, 2020

No idea, sorry, but it does sound like we should reopen the issue.

eliotstock on Aug 26, 2020

In my case the problem was in the connection not scanning. Manage to fix it by forcing such config:

bluetoothDevice.connectGatt(
                context,
                false,
                connectCallback,
                BluetoothDevice.TRANSPORT_AUTO,
                BluetoothDevice.PHY_LE_CODED
            )

Problem exist only on Android 10 when bonded to more than one device and only this particular config solves it. But this still is a bit flaky solution. After connecting to device with different settings, it breaks all future connections even for this config.

Not going to reopen this as let’s say it’s fixed. But maybe someone have any idea or wild guesses why this particular config works and others don’t?

mtomczynski on Nov 12, 2019

Thanks Maciek, this is super helpful. No, I haven’t had time to try the background service yet. Regarding “list of bonded devices seems to be a trigger”: I also list all the bonded devices in my app, with bluetoothAdapter.getBondedDevices(). One of us might get some mileage out of stepping through the Android BLE stack sources.

The Java layer of it is here (but you probably already have the sources in the Android SDK inside Android Studio): https://android.googlesource.com/platform/packages/apps/Bluetooth/. It’s 80K lines of Java but you should be able to just step into methods from a breakpoint in your own code. Eventually you’ll hit some JNI calls and won’t be able to step down any further. So far I haven’t seen any code that would behave differently based on whether the caller is a service or an activity.

Below that it’s this code: https://android.googlesource.com/platform/system/bt/, which is 200K lines of C++. You might be able to use gdb to set a breakpoint in there if you can find the function that the JNI methods in the Java layer map to and have a userdebug Android phone. I haven’t tried yet.

eliotstock on Oct 25, 2019

Hi, error 133 that happens 30 sec after connectGatt is a timeout. The phone didn’t receive any advertising packet from this device during that time and thrown an error. Make sure that the device is advertising, that the address you try to connect is correct, that you scanned the device you want to connect to or it has a public device type, and you didn’t reach any limits of connected devices, etc. I don’t know what else may cause a timeout. Does it happens 100% of times?

philips77 on Feb 17, 2019