added Support for ble API level 21

[bobroalexandr]

Hi, first of all want to say thank you for such a good library!

I saw here some issues that reffers to ble scan api v21 so I decided to make a little contibution to your great project and implement it.

I've decided to create 2 different pull requests:
1st(current one) that pull request almost doesn't change old code and just adds new code nearby. But also there is no ability to use ScanSettings and ScanFilter

2nd (in progress) Here will be much more code changes and ability to use ScanSettings and ScanFilter (it will work just for post-lollipop devices ofc)

[bobroalexandr]

@uKL @dariuszseweryn any comments? should I continue? is it helpful for your project?

[dariuszseweryn]

Hello @bobroalexandr
Thanks for your support. This is one of the features we are thinking about but in a bit different approach - it would be great to change the scanning interface to allow using the new API in it's full glory and backport to V18 as much of the functionality as possible.
I was thinking on this some time ago but other projects distracted me.

[bobroalexandr]

@dariuszseweryn thank you for response
I want to do it the way you described. Just wanted to understand if that will be helpful for that library.

[dariuszseweryn]

It will be useful without any doubt.
Sorry for the lack of contact - I can only excuse myself with having several projects recently plus some holidays. I will try to be more responsive now.

[nightscape]

There is another fork from @gryffindor14 which uses Android-Scanner-Compat-Library.
AFAIS this uses the new APIs if available and has backports for older Android versions.

@gryffindor14 is your fork ready for a PR?

[gryffindor14]

@nightscape It pretty much is. I am using it in a personal project and it seems to be working great. I have some Mock objects I wanted to create for MockRxAndroidBLE before the PR and I wasn't sure about the licensing with the Android-Scanner-Compat-Library. The library is BSD-3.

Kudos to @bobroalexandr. His start and this PR helped structure my fork quite a bit.

[aldoborrero]

As far as I know there's no problem at all mixing Apache 2 and BSD.

Here's the reason: http://programmers.stackexchange.com/questions/40561/is-bsd-license-compatible-with-apache.

As I remember, there was a bug with a particular version of the library with the scan filter (but maybe they have fixed it!).

[nightscape]

@aldoborrero I guess you are referring to this one? NordicSemiconductor/Android-Scanner-Compat-Library#1
That should be fixed since 0.1.2. The gryffindor14 fork uses 0.2.0, so that should be fine.
I'm also using the gryffindor14 fork (exactly because of its use of Android-Scanner-Compat-Library) and it seems to be working fine so far.

Probably @gryffindor14, @bobroalexandr and @dariuszseweryn should decide how to proceed and which fork/PR/commit to merge.

[aldoborrero]

Yeah that was indeed! I didn't check the version! Last time I used the lib was
pre 0.1.2!

On Oct 12 2016, at 10:37 am, Martin Mauch [email protected] wrote:

@aldoborrero I guess you are referring to
this one? [NordicSemiconductor/Android-Scanner-Compat-
Library#1](https://github.com/NordicSemiconductor/Android-Scanner-Compat-
Library/issues/1)
That should be fixed since 0.1.2. The fork uses 0.2.0, so that should be fine.
I'm also using the fork and it seems to be working fine so far.

—
You are receiving this because you were mentioned.
Reply to this email directly, [view it on GitHub](https://github.com/Polidea/R
xAndroidBle/pull/74#issuecomment-253153108), or [mute the
thread](https://github.com/notifications/unsubscribe-auth/AAFDe5HUgXXOcjNqvzgo
a_EWOeXTiFzXks5qzJxfgaJpZM4KE9lN).![](https://github.com/notifications/beacon/
AAFDe18HLFfVmK6CiaHCUlOESItQV5baks5qzJxfgaJpZM4KE9lN.gif)

[dariuszseweryn]

I am evaluating possibility of using the BSD-3 license in our library. Incorporating Nordic Semiconductors library would save us a lot of work.
I will check the fork from @gryffindor14
The only thing I dislike about the scan compatibility library is that it lacks tests.

[aldoborrero]

I've added an issue asking if they plan to add it.

NordicSemiconductor/Android-Scanner-Compat-Library#6

If that doesn't happen I would do it myself and I'll send a PR.

The good parts are that we can reuse tests from Android source code and adapt it.

[philips77]

Hi,

I'd gladly accept any PRs with tests or other features if required to Android Scanner Compat lib. We in Nordic are very happy that you find our libs useful.
I have a lot of thing on my plate now and wouldn't be able to do it myself, at least not quickly.

[aldoborrero]

Just to keep informed this thread also, I did the very first attempt to add, at least, the same tests that Android AOSP has.

[aldoborrero]

First batch of AOSP tests has been merged. I plan to add custom ones to the library in upcoming days.

[dariuszseweryn]

Thank you, great work!
I think it would be good to have some non-happy tests. We have a different library (which internally uses RxAndroidBle) for React Native - you could find some inspiration there: https://github.com/Polidea/react-native-ble-plx/blob/master/android/src/test/groovy/com/polidea/reactnativeble/advertisement/AdvertisementDataSpec.groovy
Cheers!

[aldoborrero]

For sure, I would like to add more test coverage beside those that AOSP has (which IMHO are a bit low and doesn't test too much).

I'm in talks with @philips77 to increase the coverage of the code. I'll keep updating this thread with more news regarding this topic (bear in mind that I will try to add it ASAP, but with not commiting myself too much as these weeks I have a pretty busy agenda).

Thanks for sharing @dariuszseweryn :)

[dariuszseweryn]

Hello @aldoborrero !
Happy New Year!
Did you have some time to work on the topic? Any updates?
Best Regards

[aldoborrero]

Hey @dariuszseweryn Happy New Year too!

I've been busy this past two months. But I plan to start next week as soon as I come back to Barcelona :)

I'll ping you again 👍 !!

[passsy]

the ScanSettings should be a parameter so we can use SCAN_MODE_LOW_LATENCY

[jeremy303]

@dariuszseweryn @aldoborrero and others. Thanks for the hard work. I'm keenly interested in API 21 scanning. Any updates?

[uKL]

@HolySamosa Hey! Actually, there are! @dariuszseweryn took over the change and we have some initial commits in the pipeline.

[jeremy303]

@uKL That's good news! I'm going to need to do extensive background scanning on Android 6 devices, so I really need to use API 21. Looking forward to kicking the tires on the new commits. @dariuszseweryn, so you happen to have a timeline for when we may see something? Thanks!

[aldoborrero]

Hi guys! I have back my Bluetooth device to test so I can try to move this forward also.

Previously, we were discussing of using the library from Nordic Semi to provide compatibility but I'll discard that and go forward with this PR (as is already being happening). I can help also to test.

[jeremy303]

@dariuszseweryn Awesome, that's very exciting news!

Just curious: which approach do you think you'll go with for 1.3.0? Nordic Semiconductor or from scratch?

[dariuszseweryn]

From scratch is my personal favour - less dependencies is always better and it is easier to change / tune later.

[chuks]

Hi, was wondering if you got a chance to implement the API 21 scanning? Great library, otherwise.

[sebirdman]

Are there any plans to continue forward with this PR or is there a plan to update outside of it? I've noticed when finding a single device (with a unique uuid) in an area with a ton of other devices (with their different uuid) i see a much longer search times when using this library vs searching myself with the updated >=21 search api.

[dariuszseweryn]

There is an initial implementation of this feature on our internal PR. It is different from this implementation. I hope to have it merged to the master branch this week.

[dariuszseweryn]

Just added the new scanning API to 1.3.0-SNAPSHOT. Feel free to check it out.

[passsy]

❤️ I'll check the code and add additional fixes/improvements I'm maintaining on my fork

[dariuszseweryn]

Great! Give it a try. It is on develop branch.

[chuks]

Excellent...this is good news! I'm also trying this out today, and will let you know if I see any issues.

[jeremy303]

I've also replaced my own API 21 scanning w/ the new implementation. It looks like the RxAndroidBle implementation might also help with another issue I've been meaning to address (properly handling disabling the Bluetooth adapter during a scan, which throws no error during BluetoothLeScanner.scan()). If all goes well with my initial testing in the next week, I may roll it out to a group of 50 testers. This app does continuous background scanning, so it should be a great way to kick the tires on the new version...

[chuks]

Did you figure out how to add multiple service UUIDs to the scan filter in this new API? On the platform's API, you can use a List to create the scan, but i can't figure out how to add multiple service UUIDs to this new API.

[dariuszseweryn]

@HolySamosa Great! All feedback is welcome. Just have in mind this bug: #194 It will be released in 1.2.3 as soon as possible and then merged into 1.3.0-SNAPSHOT.

@chuks Do you want to achieve filtering with AND or OR with those service UUIDs?

[chuks]

AND. I'm working on a custom product with two very specific services. I only want to find this product in a scan. In the previous implementation (using AOSP), I just create a List containing with both UUIDs and use in the scan filter.

[chuks]

Also, just read up bug #194. What's the work around for that? I will also doing long/continuous background scanning.

[dariuszseweryn]

As for #194 you would need to periodically stop the scan and start a new one.
To have a filtering of a device that is advertising you could add one ScanFilter with one UUID and then filter by using RxJava .filter() function for the second UUID. The library has embraced the default Android API. Maybe it is a good idea to be able to add multiple UUIDs to a single ScanFilter.

[chuks]

Ok, for #194, that's what I currently do with the platform's default scan -- I do intermittent 10 seconds scans, with 5 seconds pauses. I'll transfer that implementation to this new API.

As for the scan filter, yes, it would be great to have filter created directly with multiple UUID in a List, just like how it's done in the default platform. If I add one Scan filter with a UUID, how does the next filter get to the second one? Can you share a code snippet on how I can achieve that? I'm basically trying to find all devices that's advertising either UUID 1 (the custom UUID) OR UUID 2 (the DFU UUID -- when the device is in DFU state). Sorry, I incorrectly stated AND, instead of OR, in my previous post.

[chuks]

Sorry, I mis-stated. The custom devices I'm working with advertise either UUID 1 or UUID 2, so I'm trying to scan for any devices advertising either of both UUIDs. How do I achieve that in a single ScanSettings with this new API?

[dariuszseweryn]

The method accepts client.startBleScan(ScanSettings, ScanFilter...). So if you add two ScanFilters the results will be emitted even if only one of them will match.

[chuks]

Thanks. So something like this:

rxBleClient.scanBleDevices( ScanSettings, new ScanFilter.Builder() .setServiceUuid(ParcelUuid.fromString(UUID1)) .setServiceUuid(ParcelUuid.fromString(UUID2)) .build() )

[dariuszseweryn]

no, something like:

ScanFilter.Builder builder = new ScanFilter.Builder()
rxBleClient.scanBleDevices(
  scanSettings,
  builder.setServiceUuid(uuid1).build(),
  builder.setServiceUuid(uuid2).build()
)

[chuks]

Ok --awesome, thanks!

[RobLewis]

I've re-read this whole discussion and don't understand what the issues are. What, exactly, is "API 21 scanning"? What's the practical impact for users of RxAndroidBle? Will there be code changes involved? Would appreciate a bit of explanation.

[chuks]

@RobLewis here's a good explanation of the changes API 21 brought to BLE on Android - http://www.argenox.com/blog/android-5-0-lollipop-brings-ble-improvements/. This RxAndroidBle was using the older Android BLE implementation, pre-API 21. "API 21 scanning" basically means supporting the newer Android BLE API in this library. Hope that helps!

[uKL]

What's super cool is that the library emulates most features on pre-21 platforms. @dariuszseweryn did a great job to support this, you can use the API in API 18+.

[RobLewis]

Thanks, @chuks. Still would like to know if there is any impact on the code I write. Does the library now automatically and transparently use the new scanning system when running on API 21 or later? Are there new features available to RxAndroidBle users? Or is this an "under-the-hood" improvement?

[dariuszseweryn]

@RobLewis answering your questions:

Does the library now automatically and transparently use the new scanning system when running on API 21 or later?

No. The old library API .scanBleDevices(UUID...) does not benefit from this feature.

Are there new features available to RxAndroidBle users?

The new library API .scanBleDevices(ScanSettings, ScanFilter...) has a slightly different behaviour (it is not cached between calls that are using the same filters) so it is not possible to migrate the current userbase that is using the old library API. But that is an interesting idea.

Or is this an "under-the-hood" improvement?

Yes - if you use the new library API you do not have to care on what Android API you are calling it. The library exposes a subset of the new Android scanning API in a backwards-compatible manner so it is possible to call it from API <21 and get almost the same behaviour.

[RobLewis]

Thank you, but I still have not seen a statement of exactly what I need to do to my existing code to reap these benefits, and what, in fact, these benefits are.