beepiz / blescancoroutines Goto Github PK

Since API 24 (Android 7.0), only 5 scan starts are allowed for the app in windows of 30 seconds.

This gotcha is among the not well documented parts of Android BLE.

This should be easy to achieve with Flow (relates to #5).

Different scan throttling strategies might be allowed.

• A "cautious" one could ensure all scan starts are spaced by 6 seconds delaying any start happening sooner.
• An eager one could delay the 6th scan of the 30 seconds window.
• A middle ground (possibly configurable) one could allow to be eager, but not too much to avoid delay if the scan starts count exceeds the 30s window limit. Could delay with a growing backoff (linear, exponential, or custom).
• Finally, there could be a strategy to keep the started scans alive after flow cancellation for up to the duration of the 30s window, so if a new scan with the same filter is requested, it can be reused without counting in the scan starts quota.

This will need an instrumented test and/or a test app so we can rest assured all the strategies work as expected with the full range of their allowed parameters.

The reference test advertising device, its software and its config are yet to be determined.
A Raspeberry Pi 3 B running Android Things might be a good choice because of the low price point, and the Android APIs usable from Kotlin.

Last note: It might be interesting to see if we can handle a continuous scan by restarting frequently the scan as it should be easier with Flow (maybe using old BLE API if it works better), for devices that have malfunctioning bluetooth low energy (can often be determined with ease with Wi-Fi enabled).

Hi,
could you please update your project dependencies. Meanwhile coroutines are stable and not experimental anymore.

The scanner.scan() method returns kotlinx.coroutines.experimental.channels.ReceiveChannel but I can only import kotlinx.coroutines.channels.ReceiveChannel

Thanks in advance!

In the mobile sample when a user taps on the start scan button the app crashes with the following stack track because the action is not called on the Main Thread.

19232-19252/com.beepiz.blescancoroutines.sample E/MainActivity: android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views. at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:7760) at android.view.ViewRootImpl.focusableViewAvailable(ViewRootImpl.java:3780) at android.view.ViewGroup.focusableViewAvailable(ViewGroup.java:917) at android.view.ViewGroup.focusableViewAvailable(ViewGroup.java:917) at android.view.ViewGroup.focusableViewAvailable(ViewGroup.java:917) at android.view.ViewGroup.focusableViewAvailable(ViewGroup.java:917) at android.view.ViewGroup.focusableViewAvailable(ViewGroup.java:917) at android.view.ViewGroup.focusableViewAvailable(ViewGroup.java:917) at android.view.View.setFlags(View.java:14096) at android.view.View.setEnabled(View.java:10016) at android.widget.TextView.setEnabled(TextView.java:2096) at com.beepiz.blescancoroutines.sample.common.extensions.SuspendViewsKt.awaitOneClick(SuspendViews.kt:15) at com.beepiz.blescancoroutines.sample.common.extensions.SuspendViewsKt.awaitOneClick$default(SuspendViews.kt:13) at com.beepiz.blescancoroutines.sample.MainActivity.consumeScanStartStops(MainActivity.kt:74) at com.beepiz.blescancoroutines.sample.MainActivity$consumeScanStartStops$1.invokeSuspend(Unknown Source:12) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:32) at kotlinx.coroutines.DispatchedTask.run(Dispatched.kt:233) at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:594) at kotlinx.coroutines.scheduling.CoroutineScheduler.access$runSafely(CoroutineScheduler.kt:60) at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:742)

Hi Louis,

The scanChannel extension function currently returns a Channel. Do you think a Flow might be more suitable here?

I'm new to channels/flows/coroutines, so my understanding may not be correct. A Flow would allow more flexibility in when scanning should actually start - e.g. only after the user calls collect.

Current API works fine for my needs, but I was curious about your thoughts.

Thanks.

The new invokeOnClose method added in the version 0.24.0 of kotlinx.coroutines is all we need to stop scan.

Caused by: groovy.lang.MissingPropertyException: Could not get unknown property 'beepiz_bintray_user' for object of type com.jfrog.bintray.gradle.BintrayExtension.