Multiple proximity observers


Is it possible to use multiple concurrent proximity observers on Android? I know it sounds like a weird request, but I’m trying to dynamically switch between low power and low latency scanning, and for a couple of different reasons it just made sense to have one continuous low power proximity observer in a foreground service that is always on, and then turn on a low latency observer whenever i need low latency.

I have tried to use a single observer and switch modes at run time, but then I run into this issue where Android’s bluetooth stack prevents me from starting observers too frequently.

I have also tried to use two separate observers in parallel, but then i get ServiceConnectionLeaked exceptions whenever I try to stop the low latency scanner.

If it is not possible to use two concurrent observers, do you have any thoughts on how to switch power modes? I my goal is a continuous low power observer running in a foreground service when the app is closed, but switch to low latency when the user opens the app.

I wish it was possible to reconfigure the observers on-the-fly, without having to stop, reconfigure, and restart every time.

I have tested with the Android Proximity SDK v1.0.3, with a Samsung A8 phone running Android 8.

1 Like

Theoretically, yes.

Practically, there’s this limit you mentioned, which means you’d need to add a bit more code to prevent switching between the two observers too frequently—specifically, less than 30 seconds apart.

I haven’t seen the ServiceConnectionLeaked problem before—do you have a stack trace for that?


Thank you for your answer.
I figured out that it was my own fault. I refactored my code and the problem went away. I think the problem resulting in ServiceConnectionLeaked exceptions was that I accidentally turned off the low power scanner running in a foreground service instead of my “normal” low latency scanner.
It works like a charm now though, and i think that this way it is easier to work around the 30 seconds limit.

While we are on the subject, can you please help me understand how many scans the Proximity SDK actually starts when I start a simple scanner? One might guess just one, but I suspect it might be several scans started under the hood? One scanner for proximity packets, one for Telemetry A and a third for Telemetry B packets? The logs from the Android stack sometimes indicates that there are even more scans started, but I’m not sure if that is just due to user error or if it is just the way the Android stack is built.

how many scans the Proximity SDK actually starts when I start a simple scanner?

Too many (: It’s something we need to optimize in the future. Ideally, it could be just one, since modern Android devices support one scanner for multiple packets (specifically, multiple Bluetooth-chip-level filters). The way it’s implemented right now however, we have one scanner per each packet, and we scan for a lot of them. It’s not an easy thing to change sadly, and probably involves refactoring a decent chunk of our scanning code, which is why this has been delayed for so long.

Ok, that confirms what I thought.
Thank you for your comments.