Bluetooth on Android needs ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION permission about flutter_blue

[franklinharper]

I remember encountering that issue when first started using flutter blue. I don't remember how I fixed it though :(. This time around we should make sure the solution is documented.

[johanhenselmans]

OK, found the culprit. As it turns out, since the 13 of december, gradle4 is used. I had to update the gradle build settings according to https://github.com/flutter/flutter/wiki/Updating-Flutter-projects-to-Gradle-4.1-and-Android-Studio-Gradle-plugin-3.0.1

Be sure to do a flutter package get in the example folder after you have done the changes so that the flutter_blue plugin is also compiled to this version. First I did not do that and got a crash of the example app.

I'll send a PR for the changes I did to get the example running.

[fmatosqg]

I solved that by adding the simple_permissions package (https://pub.dartlang.org/packages/simple_permissions#-example-tab-)

a) import simple_permissions on pubspec.yaml (simple_permissions: "^0.1.0" )
b) add permissions on manifest
c) add code to ask for permission

on _FlutterBlueAppState call

  updatePermission() async {
    Permission permission = Permission.AccessCoarseLocation;


    if (await SimplePermissions.checkPermission(permission)) {
      isPermissionGranted = true;
    } else {
      if (await SimplePermissions.requestPermission(permission)) {
        isPermissionGranted = true;
      } else {
        isPermissionGranted = false;
      }
    }

    print("Bluetooth coarse location granted???  $isPermissionGranted");
  }

[fmatosqg]

The reason the example works in the example app in this repo is that its gradle file is missing targetSdkVersion 26 thus using the old permissions model.

I'm working on a patch.

[fmatosqg]

#49 simply updates gradle file making the example app break, followed by updating example app to fix it.

A following possible patch would be include permission check/request in relevant api methods such as scan / advertise. I like that approach because it makes it simpler for people adopting the library.

Good practice for android says we should tell the user we're going to ask for a permission and why we want it; only then make request. We can make the automatically ask for permission the default, and if opting out dev should simply do the checking before calling scan.

[fmatosqg]

Hi @pauldemarco,

I understand if you're busy, but can you give us a hint if you would consider this issue? It's a simple PR without any updates in a while, and there may be other more complex PRs as well (such as #55 and #53) that are about as old.

Is there something missing from this issue that I can provide to move the PR forward?

[pauldemarco]

Hi @fmatosqg, sorry for the delay, I have some time set aside to look into this next week.
Handling Android permissions within FlutterBlue is something that will take some consideration. As flutter continues to grow and be available on more platforms, I'd like to avoid adding non-bluetooth functionality, like permission requesting . I think outsourcing this to a dedicated "permissions" plugin, like the one mentioned, would be a better solution.

[pauldemarco]

I'm thinking the developer can get the adapter state using FlutterBlue, and if it comes back as unauthorized, can then reach out to a third party plugin that handles permissions.

I'm open to hearing any thoughts on this

[fmatosqg]

I gave some thoughts about whether embedding permissions inside flutter blue and I couldn't find a good reason why it ended like it did. I'll happily adopt the model you mention. The sample code will need some updating, I would still recommend using that same library so people can copy paste it and run. But documentation needs some thoughts, I would love to have an error that explicitly says that the app didn't ask /wasn't granted which exact permissions at the moment it fails. I'll see if I can come up with something, I don't have a laptop around now.

…

On Thu., 29 Mar. 2018, 18:15 Paul DeMarco, ***@***.***> wrote: I'm thinking the developer can get the adapter state using FlutterBlue, and if it comes back as unauthorized, can then reach out to a third party plugin that handles permissions. I'm open to hearing any thoughts on this — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFHMcYtiAoJKmRf6KJvkpySJLNlYp3phks5tjIosgaJpZM4RXilC> .

[fmatosqg]

I think the change to the example build gradle is necessary to match what most people will have now and what google will enforce by november. And this change will make the example break.

I feel the example should keep being completely self enclosed, to the point of being useful for people who have never looked at mobile permissions before. The bluetooth api has already many steps, and I think there will be a handful of developers unaware or forgetting the very first step - granting permissions - increasing the apparent difficulty of dealing with bluetooth.

In this sense I only see 2 options, a) adding code on both native sides to check for permissions and return appropriate errors to user via dart, or b) depend on an existing dart library either at sample level or enclosed in flutter_blue library.

Between a and b I'd definitely go with b, or else we'd be reinventing the wheel. On option b I can see pros and cons, but I don't have a strong preference either way.

BTW the recommended approach for permissions is asking/checking them proactively before starting using methods. That will feel more intuitive to people coming from native.

I'm also open for thoughts.

[pauldemarco]

Runtime permissions have been added to Android side with minimal code.

If permissions are needed for a scan, they will be automatically requested from the user. If permissions are denied, it will error out and cancel scanning.

This now targets the latest android API, and maintains backwards compatibility all the way to android API 18.

Note: Since ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION can be used for Bluetooth scanning, I chose the lesser of the two, ACCESS_COARSE_LOCATION.