New issue
Advanced search Search tips

Issue 674155 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug

Blocking:
issue 604105



Sign in to add a comment

bluetooth: Scan is not started after 5 consecutive tries

Project Member Reported by fbeaufort@chromium.org, Dec 14 2016

Issue description

Chrome Version: 57.0.2950.3	
OS: Android 7.1.1; Nexus 5X Build/NMF26F

What steps will reproduce the problem?
(1) Go to https://googlechrome.github.io/samples/web-bluetooth/gap-characteristics.html
(2) Press "Get Bluetooth Device's GAP Characteristics" button and close Chooser
(3) Repeat this 5 times in less than 10s.

What is the expected result?
Web Bluetooth chooser starts a BLE scan each time.

What happens instead?
At some point, Web Bluetooth chooser stops starting BLE scan.


I believe this a "feature" added in Android 7.1.1 that prevents applications to scan too many times (and for too long). It would be nice if there were a message in the chooser to warn user about this such as "Please wait xx seconds before attempting a new scan".
 
Blocking: 604105
According to https://github.com/AltBeacon/android-beacon-library/issues/418, As of Android N, DP4:

    We’ve changed the BLE Scanning behavior starting in DP4. We’ll prevent
    applications from starting and stopping scans more than 5 times in 30 
    seconds. For long running scans, we’ll convert them into opportunistic scans.

And if you look into https://android.googlesource.com/platform/packages/apps/Bluetooth/+/master/src/com/android/bluetooth/gatt/AppScanStats.java#59, you'll see two constants:

    static final int NUM_SCAN_DURATIONS_KEPT = 5;

    // This constant defines the time window an app can scan multiple times.
    // Any single app can scan up to |NUM_SCAN_DURATIONS_KEPT| times during
    // this window. Once they reach this limit, they must wait until their
    // earliest recorded scan exits this window.
    static final long EXCESSIVE_SCANNING_PERIOD_MS = 30 * 1000;

    ...


    synchronized boolean isScanningTooFrequently() {
        if (lastScans.size() < NUM_SCAN_DURATIONS_KEPT) {
            return false;
        }
        return (System.currentTimeMillis() - lastScans.get(0).timestamp) <
            EXCESSIVE_SCANNING_PERIOD_MS;
    }

And look at https://android.googlesource.com/platform/packages/apps/Bluetooth/+/master/src/com/android/bluetooth/gatt/GattService.java#1332,


        if (app != null) {
            if (app.isScanningTooFrequently() &&
                checkCallingOrSelfPermission(BLUETOOTH_PRIVILEGED) != PERMISSION_GRANTED) {
                Log.e(TAG, "App '" + app.appName + "' is scanning too frequently");
                return;
            }
            scanClient.stats = app;
            app.recordScanStart(settings);
        }
        mScanManager.startScan(scanClient);

Comment 4 by pe...@opera.com, Dec 19 2016

Confirming the findings above. I could not find any way to make Chromium detect the condition where scanning is skipped. 
This is what I see in the log:

BtGatt.GattService: onScanFilterParamsConfigured() - clientIf=5, status=0, action=1, availableSpace=16
BtGatt.GattService: registerClient() - UUID=6c63c486-b863-46f6-9b0e-a1818bb0d4dc
BtGatt.GattService: onClientRegistered() - UUID=6c63c486-b863-46f6-9b0e-a1818bb0d4dc, clientIf=5
BtGatt.GattService: start scan with filters
BtGatt.GattService: App 'org.chromium.chrome' is scanning too frequently
BtGatt.GattService: stopScan() - queue size =0
BtGatt.GattService: unregisterClient() - clientIf=5
BtGatt.GattService: registerClient() - UUID=c0c033bf-b66b-4184-abe0-ae1138a2cbba
BtGatt.GattService: onClientRegistered() - UUID=c0c033bf-b66b-4184-abe0-ae1138a2cbba, clientIf=5
BtGatt.GattService: start scan with filters
BtGatt.GattService: App 'org.chromium.chrome' is scanning too frequently
Shall we ask Android folks to at least raise an error when starting scan instead of failing silently?
Or should we monitor ourselves time between scan and scan lengths?

Comment 6 by pe...@opera.com, Dec 20 2016

I would have preferred Android to raise an error.

Comment 7 by ortuno@chromium.org, Feb 13 2017

Status: Available (was: Untriaged)
Project Member

Comment 8 by sheriffbot@chromium.org, Feb 16 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Hotlist-Recharge-Cold
Status: Available (was: Untriaged)

Sign in to add a comment