search

AltBeacon / android-beacon-library

Allows Android apps to interact with BLE beacons
Apache License 2.0
2.84k stars 836 forks source link

Ranging stopped working after a while #541

Open paulbao opened 7 years ago

paulbao commented 7 years ago

Expected behavior

Should keep notifying ranging beacon nearby

Actual behavior

Just stopped working after a while

Steps to reproduce this behavior

  1. Turn on bluetooth and start 'android-beacon-library-reference' app
  2. Click 'start ranging' and see firstBeacon displayed
  3. Keep it running for a while

Mobile device model and OS version

Moto G(2nd Generation)/Android 6.0 Disabled doze for the app

Android Beacon Library version

Version 2.11

log.txt

davidgyoung commented 7 years ago

The log indicates that detections stopped abruptly after about 15 minutes of constant scanning. Is see no system level error messages about why this happens. A similar issue in Android 7 stops long scans after 30 minutes (see #526). But this should not apply to Android 6.

It may be that the bluetooth stack gets into a bad state at some point due to external factors.

When this happens, what do you need to do to make it detect gain? Will it detect again if:

  1. You restart the app?

  2. You turn bluetooth off and on?

  3. You reboot the phone?

AndroFlo commented 6 years ago

I have the same problem. And to "resolve" it a turn of/on the bluetooth

willmcclellan commented 6 years ago

@davidgyoung I work on the same team as @paulbao and just picking this up again after seeing more instances of it happening. To answer your question, scanning only picks up again after restarting bluetooth. It looks like it's crashing at the device level and a hard restart is required.

We've seen this on Samsung J3 devices, running Android 5 and 6, but it's probably not limited to them (see the Moto G log about). At this stage, we're just looking at the best way to detect that this is happening as we have permissions to restart bluetooth programmatically. We can cycle bluetooth when our users log out and in, but the crash can occur mid-session, so ideally we need something more robust.

If you have any experience/advice for handling device level crashes I'd be grateful to hear about them. I did notice you have another project https://github.com/RadiusNetworks/bluetooth-crash-resolver that does just that, but it looks pretty out of date and maybe not relevant anymore?

I'd be happy to provide more logs so I'll try and reproduce it on one of our test devices if that helps?

davidgyoung commented 6 years ago

@willmcclellan, the key to an automated solution is figuring out a way to detect a the Bluetooth stack getting into a bad state.

Two first thoughts:

  1. Look for patterns in log messages in LogCat. While I think this would work, it requires root access for an app to read system level log messages.

  2. If BLE scan results stop, assume there has been a crash. The problem with this one is that you don't know if the detections stopped because of going of of range or because of a crash.

There may be some other API call that behaves differently once a crash happens. The trick is to find it.

In the case of the BluetoothCrashResolver I did a large amount of testing before finding a way to let me know it happened. In that case, a full crash and restart of the Bluetooth stack was indicated by a sub second transition from the off state to the on state (each of which provided API callbacks.) . That diagnosis won't help here because I do not believe that I this case the BluetoothService actually crashes and restarts. It just gets into a bad state.

This stuff can be pretty time consuming. But if your team has time or budget, I am pretty sure there is a solution. If it enough of a priority for you, perhaps we could set up an offline discussion. You can contact me privately at tech at davidgoung.com

In the case o

davidgyoung commented 6 years ago

Closed via #644