Upgrading to v1.3.0 may result in app being removed from Google Play Store beginning March 2021.

[tkem]

I just upgraded and noticed that besides ACCESS_FINE_LOCATION, which is required on Android 10, v1.3.0 now also requires requests ACCESS_BACKGROUND_LOCATION.

As stated here,

Your app should not request access to location in the background unless it’s required

Adding this permission will require app authors on the Play Store to fill out a Permissions declaration form, where to specify why a specific app requires requests ACCESS_BACKGROUND_LOCATION, and also provide a short video of the app in action. If this is not provided by March 2021, updates may be blocked and apps may be removed form the Play Store.

My app does not access location services in the background. It only requires location access for scanning for BLE devices, and - like most Cordova apps, I guess - only does this when in the foreground. So AFAICS ACCESS_FINE_LOCATION is sufficient for running on all versions of Android that support BLE, and both ACCESS_BACKGROUND_LOCATION and ACCESS_COARSE_LOCATION can be removed.

May I ask why ACCESS_BACKGROUND_LOCATION was added in the first pace?

[Mr-Mime]

Maybe this comment from @don explains it to you. https://github.com/don/cordova-plugin-ble-central/pull/771#issuecomment-723486451

[tkem]

@Mr-Mime Thanks for the link, found it myself in the mean time. Though @don's reasoning makes sense, I think the Play Store issues mentioned above, i.e. the possibility of your app being rejected, were not taken into account.

[tkem]

@Mr-Mime I changed this issue's title to better reflect my concerns with the ACCESS_BACKGROUND_LOCATION.

[CodeTroopers]

I have the same problem : ACCESS_BACKGROUND_LOCATION is required by the version 1.3.1 and my app is rejected by Google Play store approbation flow. ACCESS_BACKGROUND_LOCATION is not needed because scanning is always on foreground and then autoConnect can be used in background In waiting that this is fixed, i use this pull request #798 that requires only ACCESS_FINE_LOCATION

[ASHBAW]

Same here.

[angel-garcia-lopez]

I am in the same situation here and I need to release today. So I think for the moment I might downgrade to a previous plugin version or just remove the permission from the Manifest until this gets clarified.

[DCGoD]

This is a real issue. I'll put in a PR for it but I'm not sure why it's not being taken seriously. Google will not approve apps that cannot clearly show (with a video) how your app uses the background location service. Yes, this wasn't always the case and is part of their new agreement.

[QuentinFarizon]

Since apparently Google (or rather some of the manufacturers) require fine location for Bluetooth scanning, showing that our apps do Bluetooth scanning should be sufficient no?

Le ven. 4 déc. 2020 à 20:01, MM notifications@github.com a écrit :

This is a real issue. I'll put in a PR for it but I'm not sure why it's not being taken seriously. Google will not approve apps that cannot clearly show (with a video) how your app uses the background location service. Yes, this wasn't always the case and is part of their new agreement.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/don/cordova-plugin-ble-central/issues/821#issuecomment-738960004, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIATUICNIVC7NHC3JD6WFUDSTEWWZANCNFSM4TTAHNNA .

[angel-garcia-lopez]

Since apparently Google (or rather some of the manufacturers) require fine location for Bluetooth scanning, showing that our apps do Bluetooth scanning should be sufficient no? .

No, the problem is with background location. My app doesn't use it. And other apps are in the same situation. One may even not do bluetooth scanning but still use bluetooth (my case).

[DCGoD]

Correct. My suggestion is to make this a dynamic choice. If a user populates the background description string in config.xml, add the background location value to the manifest. Otherwise leave it out. Solves both cases at build time.

[ASHBAW]

I like Mark's suggestion.

[natestone]

I also like Mark's suggestion but would like to ask if it's possible to have the plugin turn off any background location events if the config.xml does not have the background description string. For instance, disabling background bluetooth scanning if the user has not opted for background location services. That way, I can't accidentally use something I haven't requested access to. Essentially, it would just check if the app is in the background and deny use of location-based services if the config value is not set (maybe not viable since config.xml is external to the complied code, so maybe a flag on the command line during install or something would be a way to facilitate it "--disable-background-location-services". Thanks for considering.

[HankLloydRight]

I would also like to echo Mark's suggestion. I'm now caught between two versions. I was using an older version 1.1.4 which worked fine for years with ACCESS_COARSE_LOCATION.... until the app wouldn't connect to BLE on a user's new Samsung device.

So I updated the BLE plugin to V1.3.1 for the ACCESS_FINE_LOCATION patch and it works fine now (delivered via side-loading, not Google Play store).

But now when I try to upload my app to Play store, I have this ACCESS_BACKGROUND_LOCATION problem. My app does not need ACCESS_BACKGROUND_LOCATION at all, but now I can't release the app to production without jumping through the new hoops like preparing a video showing how the app needs to access ACCESS_BACKGROUND_LOCATION, which I can't do since it doesn't. So I'm now stuck without a working app in the Play store (the current version in Production only has ACCESS_COARSE_LOCATION).

Please allow us some method to toggle ACCESS_BACKGROUND_LOCATION on or off as needed. Thank you.

[HankLloydRight]

I was able to find a workaround for other people with this ACCESS_BACKGROUND_LOCATION permission.

See this question on StackOverflow: https://stackoverflow.com/questions/63501872/issue-with-the-cordova-plugin-ble-central Which leads to this fork: https://github.com/dslima90/cordova-plugin-ble-central

While his example is for Ionic, I'm using it for Cordova.

The Stackoverflow user DSLima90 forked version 1.2.5 and changed ACCESS_COARSE_LOCATION to ACCESS_FINE_LOCATION but without ACCESS_BACKGROUND_LOCATION. I was able to remove plugin version 1.3.1 and add this fork and now my app works as planned and will be approved in the Google Play Store. THANK YOU DSLima90!

[LocutusOfPenguin]

I have the same problem (google reject) and can't understand the current status of this. Do I need to go back to this dslima state (19 commits behind) or can I do something like what @markamccorkle saying? We all need to support Android 10 (soon).

Fresh install of this lib brings back this "background" on config.xml (and these google problems) so, I don't see any progress.

[QuentinFarizon]

Do someone know how to make a <uses-permission>tag in plugin.xml configurable at build time ? I'll push a PR

[tellybrown]

I don't see any code in this project that actually uses the background permission. It should be required by the calling app to determine if it should be used in the background, not the plugin. I don't think the config.xml solution is a good one since there is no code actually using it. I have other purposes for using background for receiving and processing notifications. I have no need for location in the background.

[marioshtika]

Any updated on this? Google is still rejecting apps that uses the background permission. It's a permission that the app is asking but it's not using.

[strafton]

Has anyone come up with a solution to this yet? My app is currently being rejected from google due to this issue and it is a HUGE problem for me. The existing app is breaking and I can't get a fix in due to this issue!! Please help!

[HankLloydRight]

Please see my post above for a workaround until this plugin is updated:

https://github.com/don/cordova-plugin-ble-central/issues/821#issuecomment-761820509

These two CLI commands should fix it for you:

cordova plugin rm cordova-plugin-ble-central cordova plugin add git+https://github.com/dslima90/cordova-plugin-ble-central.git

That's it. But all credit goes to dslima90, not me.

[Gargamil]

You can also use my 1.3.1 fork. I only removed ACCESS_BACKGROUND_LOCATION.

https://github.com/Gargamil/cordova-plugin-ble-central

[dariosalvi78]

This is a serious issue and I hope @don will fix it. @Gargamil maybe you want to send a PR for this?

[DCGoD]

This is a serious issue and I hope @don will fix it. @Gargamil maybe you want to send a PR for this?

Like many open source repos. The solution isn't to rely on the original author since nearly every project goes stale eventually and someone comes in, forks it, then continues on till the next picks it up. It's time to pick up the torch here in my opinion. Give thanks and praise to the original author and thank them for the hard work and effort and continue to make their baby live on. Just my $.02

[QuentinFarizon]

@don Would you agree to handover control of this repo ? It's better to keep the same repo / npm package / cordova plugin name than having a multitude of forks and competing repos not officially listed in npm/cordova/ionic/...

I agree with @markamccorkle, thanks for your amazing work !

[Gargamil]

Created a pull request based on my fork: https://github.com/don/cordova-plugin-ble-central/pull/839

[dariosalvi78]

I think the background permission could bee made optional with a flag, like done for IOS_INIT_ON_LOAD, for those who need it.

[marioshtika]

@Gargamil I don't think we should remove the ACCESS_BACKGROUND_LOCATION.

I agree with @dariosalvi78, we should make it optional. We should set it when installing the plugin, by passing it as a variable.

For example:

$ cordova plugin add cordova-plugin-ble-central --variable ACCESS_BACKGROUND_LOCATION=true

[dariosalvi78]

Variables specified on the command line (also called preferences) can be used to a) make the permission optional in plugin.xml and b) to not ask for permissions at runtime. As for the latter, it's possible to get the preferences inside the plugin Java class that extends CordovaPlugin by just doing this.preferences.get.... This is because the preferences are a protected member of that class.

Maybe Don or Tobias can work on that? (I'm super busy now!)

[marioshtika]

I will try to implement what we mentioned above and send a pull request in the next few days.

[Path-A]

@Gargamil Thanks! I'm using your repo for app submission. You're a lifesaver. Hopefully @don can accept the pull request soon.

[marioshtika]

Hello @don,

I have created a pull request (#844) where the ACCESS_BACKGROUND_LOCATION permission is optional.

You can enable it as shown below:

$ cordova plugin add cordova-plugin-ble-central --variable ACCESS_BACKGROUND_LOCATION=true

• I used a hook of type after_prepare to add or remove the ACCESS_BACKGROUND_LOCATION on the AndroidManifest.xml file.
• I also used the variable as a preference to use it in the Java file to request the ACCESS_BACKGROUND_LOCATION permission dynamically.
• I updated the README.md file with the information about this variable

I tested it and it is working as it should.

---

This alert message is showing when ACCESS_BACKGROUND_LOCATION=false

---

This alert message is showing when ACCESS_BACKGROUND_LOCATION=true

[giowild]

Hi all, since you are experts about BLE, ionic and Background, I have the following issue:

https://github.com/don/cordova-plugin-ble-central/issues/850

Any advise or pointer would be greatly appreciated, thanks a lot!

[tkem]

FYI: Google finally acknowledged that requiring location services for scanning BLE devices wasn't such a good idea in the first place, so with Android 12 there will be a new permission BLUETOOTH_SCAN, and apparently enabling location for this will no longer be necessary.

Source: https://www.youtube.com/watch?v=D2cU_itNDAI (relevant part starts around 21:30)

[marioshtika]

This is big update for the users :), but for the developers it is just another permission we have to handle :P So I am guessing that, as we are supporting the ACCESS_COARSE_LOCATION permission for SDK < 29. We are going to support ACCESS_FINE_LOCATION, ACCESS_BACKGROUND_LOCATION permissions for sdk >= 29 and <=30. And we are going to support BLUETOOTH_SCAN permission for sdk > 30

Saying that I think we still need to make the ACCESS_BACKGROUND_LOCATION optional.

@don do you agree with the above? I have already sent a pull request (#844) do you think that would be merge any time soon? Is there anything else you want me to add or change or remove? I would like to help with this issue, so let me know if you need anything else from me.

[takumiecofit]

@marioshtika Hi, I would like to use your #844 as an npm package. Does anyone know how to npm install that pull request/commit?

[marioshtika]

Hello @takumiecofit I have never tried installing from a pull request, but maybe this might help.

@don do you think #844 is a pull request that can be merged with the main branch?

[kstearns]

Even after removing the ACCESS_BACKGROUND_LOCATION, my app is still being rejected by Google. Asking them to clarify exactly why it is being rejected has resulted in the same generic (no information) response 3 times.

Has anyone else actually gotten an app accepted with suggested workaround ?

My suspicion is that they're inspecting the source and seeing that the Location usage is being performed in a Service, which is technically a background process, and therefore rejecting it ... but I cannot even get an answer to that specific, pointed question.

Really getting frustrating ... customers are pissed that BLE functionality has been broken for weeks now as I haggle with Google and get zero support.

[tellybrown]

I wrote a script in bash to remove those elements from code before i built.

On Mon, Jul 19, 2021, 5:16 PM kstearns @.***> wrote:

Even after removing the ACCESS_BACKGROUND_LOCATION, my app is still being rejected by Google. Asking them clarify exactly why it is being rejected has resulted in the same generic (no information) response 3 times.

Has anyone else actually gotten an app accepted with suggested workaround ?

My suspicion is that they're inspected the source and seeing that the Location usage is being performed in a Service, which is technically a background process, and therefore rejecting it ... but I cannot even get an answer to that specific, pointed question.

Really getting frustrating ... customers are pissed that BLE functionality has been broken for weeks now as I haggle with Google and get zero support.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/don/cordova-plugin-ble-central/issues/821#issuecomment-882897383, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAUCS6FKVE2LJRNW7VOF7H3TYSP23ANCNFSM4TTAHNNA .

[kstearns]

Does your script make any other changes besides removing the ACCESS_BACKGROUND_LOCATION permission usage ?

[tellybrown]

This is what I did. Cat command was useful for debugging if you needed to alter more or if code changed.

sed -i '' '723d' ./android/capacitor-cordova-android-plugins/src/main/java/com/megster/cordova/ble/central/BLECentralPlugin.java cat ./android/capacitor-cordova-android-plugins/src/main/java/com/megster/cordova/ble/central/BLECentralPlugin.java sed -i '' '11d' ./android/capacitor-cordova-android-plugins/src/main/AndroidManifest.xml cat ./android/capacitor-cordova-android-plugins/src/main/AndroidManifest.xml

[kstearns]

Thanks, appreciate your willingness to help. Unfortunately, those are the exact same 2 changes that I have made to my app, but they continue to reject it ... sigh. Back to developer support i suppose ...

[HankLloydRight]

Have you tried any of the other workarounds or forks of the ble-central library? (see above posts). They worked just fine for me.

[tellybrown]

if you have a build process it will replace those lines even if you checked in the code. Mine passed once I removed them in my build process. The best way I found was to look at the google play portal to look at the permissions after I uploaded. Because I found I still had them in there even after I thought I had removed.

[kstearns]

Yeah, i did a manual build and inspected APK/bundle to confirm they were removed. Also confirmed permissions in play portal after uploading. If its working for others, then I'm beginning to think that the dev support guys have no flipping idea why its being rejected either :)

[QuentinFarizon]

After switching to one of the forks, did you clean your platforms and plugins directories ?

Also, depending on the fork you use, on some of them there is a variable to pass to enable background or not.

Le mar. 20 juil. 2021, 02:23, kstearns @.***> a écrit :

Yeah, i did a manual build and inspected APK/bundle to confirm they were removed. Also confirmed permissions in play portal after uploading. If its working for others, then I'm beginning to think that the dev support guys have no flipping idea why its being rejected either :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/don/cordova-plugin-ble-central/issues/821#issuecomment-882950181, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIATUIGOGDEFJVCOTNJGVETTYS6XBANCNFSM4TTAHNNA .

[marioshtika]

Hello, @kstearns. QuentinFarizon is right. Did you clean your platform and plugins directories, after switching between forks? Which fork are you using?

If you are using my fork you should do the below steps:

ionic cordova plugin rm cordova-plugin-ble-central
ionic cordova platform rm android
rm -rf plugins 
rm -rf node_modules
rm package-lock.json
npm i 
ionic cordova platform add android
ionic cordova plugin add https://github.com/marioshtika/cordova-plugin-ble-central --variable BLUETOOTH_USAGE_DESCRIPTION="Your description here" --variable IOS_INIT_ON_LOAD=false --variable ACCESS_BACKGROUND_LOCATION=false

Let me know if these steps helped you pass the review 🤞

[HankLloydRight]

I just uploaded a new Cordova app to Play Store (for testing) using the dslima90 fork above (see post from Jan 17), and here are the results from the Play store:

Features (3) android.hardware.bluetooth, android.hardware.faketouch, android.hardware.location

Required permissions (4) android.permission.ACCESS_COARSE_LOCATION, android.permission.BLUETOOTH, android.permission.BLUETOOTH_ADMIN, android.permission.INTERNET

[kstearns]

Yes, I tried the forks, and on most recent attempt, I just manually edited the plugin Java source files directly and built from Android Studio to be 100% certain I knew what was getting bundled in the app, but was still rejected. I really think something is screwed up with the Play app account ... like it is holding onto old/bad images/data/something and incorrectly rejecting the app. Thanks for all the support - much appreciated. I'll post back once I get to a resolution with Google.

[HankLloydRight]

Have you looked at all your other plugins for a suspect? Or are you sure it's ble-central?

[kstearns]

Yes, nothing else in the app uses BLE or Location in any way.