Too many receivers

[mmeisel]

I'm having the same issue as #438 where I am getting:

java.lang.IllegalStateException: Too many receivers, total of 1000

presumably after my app has made 1000 connections. Once it gets into this state, I have to kill the app before I can make any more connections. I am using one BleManager instance per connection, but I am using setAutoConnect(false).

From a cursory look at the code, it seems like it may be the case that the BleManager.disconnect() request does eventually result in BleManagerHandler.close() being called, but not BleManager.close(), which is where the receiver in question is unregistered (BleManager.mPairingRequestBroadcastReceiver). Am I reading that correctly?

Thank you for making such an incredibly helpful library!

[mmeisel]

@philips77 have you been able to reproduce this? Do you need more information from me? I tried a workaround (calling BleManager.close() myself) but I am still getting lots of these errors from user devices so I could use some help.

[philips77]

Hi,
Let me inverstigate it now.

[mmeisel]

Thanks! FWIW, I ran LeakCanary and had it track my BleManager subclass after calling disconnect().suspend(), it gave me this (I censored my application name with *****s). These seem to go away if I call close() explicitly, but the version that is giving me errors in the wild does call close() explicitly, so something else must be going on here.

    ┬───
    │ GC Root: System class
    │
    ├─ android.provider.FontsContract class
    │    Leaking: NO (*****Application↓ is not leaking and a class is never leaking)
    │    ↓ static FontsContract.sContext
    ├─ com.*****Application instance
    │    Leaking: NO (Application is a singleton)
    │    mBase instance of android.app.ContextImpl
    │    ↓ Application.mLoadedApk
    │                  ~~~~~~~~~~
    ├─ android.app.LoadedApk instance
    │    Leaking: UNKNOWN
    │    Retaining 17.3 kB in 336 objects
    │    mApplication instance of com.*****Application
    │    Receivers
    │    ..*****Application@335639464
    │    ....BleManagerHandler$1@343600128
    │    ....BleManager$1@341303128
    │    ....BleManager$1@343741576
    │    ....BleManager$1@343440032
    │    ....VisibilityTracker@336445680
    │    ....BleManagerHandler$1@343741968
    │    ....BleManager$1@343603416
    │    ....BleManager$1@343012456
    │    ....BleManagerHandler$2@343600152
    │    ....SystemEventsBreadcrumbsIntegration$SystemEventsBroadcastReceiver@341201984
    │    ....BleManager$1@343554392
    │    ....BleManager$1@342619576
    │    ....BleManager$1@342228608
    │    ....BleManagerHandler$2@343741992
    │    ....BleManager$1@341696168
    │    ....BleManager$1@343429328
    │    ....BleManager$1@343599736
    │    ↓ LoadedApk.mReceivers
    │                ~~~~~~~~~~
    ├─ android.util.ArrayMap instance
    │    Leaking: UNKNOWN
    │    Retaining 16.8 kB in 322 objects
    │    ↓ ArrayMap.mArray
    │               ~~~~~~
    ├─ java.lang.Object[] array
    │    Leaking: UNKNOWN
    │    Retaining 16.8 kB in 320 objects
    │    ↓ Object[1]
    │            ~~~
    ├─ android.util.ArrayMap instance
    │    Leaking: UNKNOWN
    │    Retaining 16.7 kB in 319 objects
    │    ↓ ArrayMap.mArray
    │               ~~~~~~
    ├─ java.lang.Object[] array
    │    Leaking: UNKNOWN
    │    Retaining 16.6 kB in 317 objects
    │    ↓ Object[14]
    │            ~~~~
    ├─ no.nordicsemi.android.ble.BleManager$1 instance
    │    Leaking: UNKNOWN
    │    Retaining 856 B in 26 objects
    │    Anonymous subclass of android.content.BroadcastReceiver
    │    ↓ BleManager$1.this$0
    │                   ~~~~~~
    ╰→ com.*****Device instance
    ​     Leaking: YES (ObjectWatcher was watching this because *****)
    ​     Retaining 836 B in 25 objects
    ​     key = 49f6f69d-bb45-4178-8ce4-4701909eb7c7
    ​     watchDurationMillis = 5595
    ​     retainedDurationMillis = 593
    ​     context instance of com.*****Application

[mmeisel]

Hi @philips77 I'm wondering if you've had a chance to look into this further? I'm happy to help debug, but I could use some tips about where to start since I'm not familiar with the codebase.

[mmeisel]

I did a little more digging, and it's definitely BleManager.mPairingRequestBroadcastReceiver that is leaking. If I use adb shell dumpsys activity broadcasts to find the registered BroadcastReceivers, I see one receiver for action android.bluetooth.device.action.PAIRING_REQUEST for every connection the app has ever made since being started, and that number never decreases. Calling close() explicitly seems to fix the problem, but I wasn't sure about something -- is it safe to call disconnect().enqueue() and then immediately call close()?

[philips77]

Hello,
Sorry, I was on well deserved vacation and enjoyed my time without the computer.

is it safe to call disconnect().enqueue() and then immediately call close()?

How about in .done { ... } or .then { ... } callbacks for the DisconnectRequest? Seems like the internal close() method is called when the device actually gets disconnected, not immediately.
Calling close() immediately after disconnect().enqueue() won't even start disconnecting, will just shut it down.

[mmeisel]

Sounds great! No worries at all. I was previously using disconnect().suspend() followed by close(), but that still leaks under some conditions I can't quite understand -- maybe the coroutine was getting cancelled before the disconnection is complete? I'll try what you suggested.

Regardless, I still think only BleManagerHandler.close() is getting called by the disconnect process, never BleManager.close(), so you do have to explicitly call BleManager.close() even when autoConnect is false, otherwise that pairing request receiver leaks.

[philips77]

Yes, that is correct. This is because the BleManager instance can in theory be used to make another connection to some other device.

[mmeisel]

Thanks @philips77, I think the documentation is not clear that this is the intended behavior, I submitted a PR to clarify it, hopefully it makes sense.

[mmeisel]

Unfortunately, I'm still encountering this issue, even when calling close() explicitly, but it's very hard to debug since it doesn't happen every time. But sure enough, I see these pairing request BroadcastReceivers start piling up over time, and I have some production users reaching the 1,000 receiver limit still as a result.

Here is an excerpt from adb shell dumpsys activity broadcasts with an app that has been running for a while but has no active connections:

❯ adb shell dumpsys activity broadcasts com.xxxxxxx
ACTIVITY MANAGER BROADCAST STATE (dumpsys activity broadcasts)
  Registered Receivers:
  * ReceiverList{dfa19ed 24501 com.xxxxxxx/10324/u0 remote:8357004}
    app=24501:com.xxxxxxx/u0a324 pid=24501 uid=10324 user=0 #receivers=10
    Filter #0: BroadcastFilter{1b17022}
      Action: "android.bluetooth.device.action.PAIRING_REQUEST"
  * ReceiverList{17eb06c 24501 com.xxxxxxx/10324/u0 remote:572651f}
    app=24501:com.xxxxxxx/u0a324 pid=24501 uid=10324 user=0 #receivers=10
    Filter #0: BroadcastFilter{c3a3635}
      Action: "android.bluetooth.device.action.PAIRING_REQUEST"
  * ReceiverList{3084ea8 24501 com.xxxxxxx/10324/u0 remote:65ae6cb}
    app=24501:com.xxxxxxx/u0a324 pid=24501 uid=10324 user=0 #receivers=10
    Filter #0: BroadcastFilter{70ddc1}
      Action: "android.bluetooth.device.action.PAIRING_REQUEST"
  * ReceiverList{4434f88 24501 com.xxxxxxx/10324/u0 remote:e4fdf2b}
    app=24501:com.xxxxxxx/u0a324 pid=24501 uid=10324 user=0 #receivers=10
    Filter #0: BroadcastFilter{e147d21}
      Action: "android.bluetooth.device.action.PAIRING_REQUEST"
  * ReceiverList{9c28960 24501 com.xxxxxxx/10324/u0 remote:b2f963}
    app=24501:com.xxxxxxx/u0a324 pid=24501 uid=10324 user=0 #receivers=10
    Filter #0: BroadcastFilter{defee19}
      Action: "android.bluetooth.device.action.PAIRING_REQUEST"
  * ReceiverList{984c970 24501 com.xxxxxxx/10324/u0 remote:4b4efb3}
    app=24501:com.xxxxxxx/u0a324 pid=24501 uid=10324 user=0 #receivers=10
    Filter #0: BroadcastFilter{f8a14e9}
      Action: "android.bluetooth.device.action.PAIRING_REQUEST"
  * ReceiverList{532b61e 24501 com.xxxxxxx/10324/u0 remote:6550a59}
    app=24501:com.xxxxxxx/u0a324 pid=24501 uid=10324 user=0 #receivers=10
    Filter #0: BroadcastFilter{348deff}
      Action: "android.bluetooth.device.action.PAIRING_REQUEST"
  * ReceiverList{fc1a7a 24501 com.xxxxxxx/10324/u0 remote:a6616a5}
    app=24501:com.xxxxxxx/u0a324 pid=24501 uid=10324 user=0 #receivers=10
    Filter #0: BroadcastFilter{fc4a22b}
      Action: "android.bluetooth.device.action.PAIRING_REQUEST"
  * ReceiverList{3d59843 24501 com.xxxxxxx/10324/u0 remote:4ed39f2}
    app=24501:com.xxxxxxx/u0a324 pid=24501 uid=10324 user=0 #receivers=10
    Filter #0: BroadcastFilter{d286ec0}
      Action: "android.bluetooth.device.action.PAIRING_REQUEST"
  * ReceiverList{d7f5115 24501 com.xxxxxxx/10324/u0 remote:d4deacc}
    app=24501:com.xxxxxxx/u0a324 pid=24501 uid=10324 user=0 #receivers=10
    Filter #0: BroadcastFilter{5281c2a}
      Action: "android.bluetooth.device.action.PAIRING_REQUEST"