Android Update Rejection (New Google Permissions & Location Permissions policies)

[firdaussoberi]

Your Environment

• Plugin version: ^3.9.0
• Platform: Android
• Gradle target API:29
• OS version: 10
• Device manufacturer / model: Redmi Note7
• React Native version (react-native -v): 0.60.4
• Plugin config

            var DEFAULTCONFIG = {
                url: BASE_URL + "postagentlocation",
                desiredAccuracy: BackgroundGeolocation.DESIRED_ACCURACY_HIGH,
                distanceFilter: 10,
                stopTimeout: 1,
                locationUpdateInterval:30000,//in milliseconds
                foregroundService: true,
                enableHeadless:true, //Enables "Headless" operation allowing you to respond to events after you app has been terminated with stopOnTerminate false.
                heartbeatInterval: 60, //default is 60s
                debug: false, // <-- enable this hear sounds for background-geolocation life-cycle.
                logLevel: BackgroundGeolocation.LOG_LEVEL_VERBOSE,
                stopOnTerminate: false,   // <-- Allow the background-service to continue tracking when user closes the app.
                startOnBoot: true,        // <-- Auto start tracking when device is powered-up.
                stopAfterElapsedMinutes:2880, //in minutes, 48 hours
                useSignificantChangesOnly:false,
                stopOnStationary:false, 
                schedule: [
                  "2-6 9:00-19:00"   // Mon-Fri: 9:00am to 7:00pm
                ],          
                extras: {
                  "deviceInfo":deviceinfo,
                },         
                headers: {              // <-- Optional HTTP headers
                  "Content-Type": "application/json",
                  "Access-Control-Allow-Methods": "POST",
                  "Authorization": "Basic " + token,
                },
            };


        BackgroundGeolocation.ready(DEFAULTCONFIG, (state) => {
        console.log("- BackgroundGeolocation is configured and ready: ", state.enabled);
                if (!state.enabled) {
                  ////
                  // 3. Start tracking!
                  //
                    BackgroundGeolocation.start(function() {
                      console.log("- Start success");
                    }); 
        
                }               
        });

Expected Behavior

It is not a bug or installation issue, rather rejection of app update on Google Play Store which I expected to be fine
since I just updated same version of the plugin a week ago.

Actual Behavior

App rejected on Play Store.

Steps to Reproduce

Context

Today my new app update submission just got rejected by the Play Store review team. It's weird because I have never once got rejected on Android before and I updated fine just a week ago. I suspect this is related to the recent crack down on more apps using background location access:

https://arstechnica.com/gadgets/2020/02/google-cracks-down-on-location-tracking-android-apps/
https://support.google.com/googleplay/android-developer/answer/9799150?hl=en

and related to this permission in manifest I suppose:
ACCESS_BACKGROUND_LOCATION
according to:
https://developer.android.com/training/location/background

The reasons given for rejection is as below:

Feature does not meet requirements for background location access

Based on our review, your declared feature does not meet the requirements for background location access.

Please remove the background location permission requested and submit an update to your app. When declaring a feature for background location access, please note the following:
Your selected feature should deliver clear value to the user and be important to the core functionality, or main purpose of the app. Without this core feature, the app is “broken” or rendered unusable.
You should also consider if users would expect the app to access their location in the background, and if you can deliver the same experience without accessing location in the background.  

You may only request permissions that are necessary to implement critical current features or services in your application. You may not use permissions that give access to user or device data for undisclosed, unimplemented, or disallowed features or purposes. In order for our team to check for compliance, we must be able to review and verify your in-app experience.

They gave two resolution options to allow submission:

Option 1: File an exception and roll out a submission (without making changes)
To file an exception in the form, go to the question “Does your app meet the Location permissions policy?” 
and select “No, this app does not meet the Location permissions policy.” (given until March 29, 2021)

Option 2: Submit a compliant update
Once you’re ready to submit a compliant version of your app:
--

1. Make the necessary updates to address the issue(s) identified above. If your app is not eligible to 
access location in the background or does not meet requirements for accessing location in the background, 
please remove the permission from your manifest and in-app functionality. 
2. Double check that your app is compliant with all other Developer Program Policies.

Debug logs

Logs

PASTE_YOUR_LOGS_HERE

Question

Have anyone encountered this before (or rather around this time)?
If so and you succeed resubmitting, what steps have you taken to resolve this?

I tend to prefer Option2 since doing Option1 won't do much good since March 2021 is a few months away and I still have to resubmit anyway. Also, is there any option in the plugin for Android that would allow only location tracking while in foreground and less 'intrusive' according to these Google's new policies?

I guess with my configs, I have to do enableHeadless:false, stopOnTerminate: true and startOnBoot: false right?

[christocracy]

You’re the first to report this rejection. I have nothing to suggest at this time.

[firdaussoberi]

You’re the first to report this rejection. I have nothing to suggest at this time.

Thanks @christocracy. I'll try to readjust and resubmit and let's see if it goes through. In the meantime, I would also like to know from people in this repo if they encountered this recently.

[christocracy]

Do you have access to the private repo? You might be interested in the new Config.locationPermissionRationale. It’s described at the top of the CHANGELOG for release 3.9.1.

Customers should post issues in and use the private repo for latest updates.

[firdaussoberi]

Do you have access to the private repo? You might be interested in the new Config.locationPermissionRationale. It’s described at the top of the CHANGELOG for release 3.9.1.

Customers should post issues in and use the private repo for latest updates.

I see. I have access to it. I'll check Config.locationPermissionRationale, thanks!

[christocracy]

API docs Config.backgroundPermissionRationale

[firdaussoberi]

Hi @christocracy . Sorry I didn't use private repo, I figure it's quicker to continue here. Just a quick question.

I've read the changelog regarding Config.backgroundPermissionRationale for v3.9.1 . If I read correctly, this is implemented only for Android right? Similar to that of iOS 'requestTemporaryFullAccuracy' in v3.9.0, which means I've to select platform for ready method. Also, this uses targetSdkVersion 30 so I assume targetSdkVersion 29 won't work then (in that case I've to upgrade my build.gradle)? How about the behaviour on Android9, will this forward user to Location Permissions screen also?

=================================
Edit:
Oh, for anyone looking about the rejection, if they see these three permissions:
ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
and especially ACCESS_BACKGROUND_LOCATION

all developers have to go through permission declaration starting Sept30 2020
and explicitly argue about its use case, as outlined here:
https://playacademy.exceedlms.com/student/path/64266/activity/88785
as they weed out non-compliant apps starting Nov2nd 2020.

[christocracy]

Ok, I submitted the demo-app today and got rejected.

Before submission, I configured all the new App access stuff, describing to App reviewers how to login to the demo and get the app to request permission:

App Access

You must explain to the reviewer how to login to your app from a fresh install and initiate requesting location Always permission dialog:

NOTE: I observed http://tracker.transistorsoft.com/google and the App-reviewer (on a real Pixel) actually did register and record a motionchange event!

Permissions declaration form

Re-release

I have updated the text in Config.backgroundPermissionRationale with suggestions from the rejection-notice and re-submitted a release.

Include at least the following sentence, adapted to include all the relevant features requesting access to location in the background in the app that are readily visible to the user: “This app collects location data to enable ["feature"], ["feature"], & ["feature"] even when the app is closed or not in use.”

BackgroundGeolocation.ready({
  .
  .
  backgroundPermissionRationale: {
    title: "Allow {applicationName} to access this device's location even when the app is closed or not in use.",
    message: "This app collects location data to enable recording your trips to work and calculate distance-travelled.",
    positiveAction: 'Change to "{backgroundPermissionOptionLabel}"',
    negativeAction: 'Cancel'
  }
})

[firdaussoberi]

Re-release

I have updated the text Config.backgroundPermissionRationale to more closely resemble the rejection notice and re-submitted a release.

Good luck @christocracy for your submission! Let us know if it goes through.
About 'backgroundPermissionRationale', can you share your build.gradle? I look at your build.gradle and it has DEFAULT_TARGET_SDK_VERSION 29. I thought this targets api 30?

Mine is something like:

        buildToolsVersion = "29.0.3"
        minSdkVersion = 17
        compileSdkVersion = 29
        targetSdkVersion = 29
        supportLibVersion = "28.0.0"
        appCompatVersion = "1.1.0" 
        googlePlayServicesVersion = "17.0.0" 

Is it fine if I build like this or do I need targetSdkVersion=30?

[christocracy]

Release Accepted!

My latest change to Config.backgroundPermissionRationale Strings did the trick. My latest submission of demo app is now live (Flutter version). Reviewers are going to be very picky about what you say:

backgroundPermissionRationale: {
    title: "Allow {applicationName} to access this device's location even when the app is closed or not in use.",
    message: "This app collects location data to enable recording your trips to work and calculate distance-travelled.",
    positiveAction: 'Change to "{backgroundPermissionOptionLabel}"',
    negativeAction: 'Cancel'
  }

---

look at your build.gradle and it has DEFAULT_TARGET_SDK_VERSION 29

DEFAULT_XXX in the plugin's build.gradle apply only if you haven't provided ext overrides in your app's root build.gradle.

@firdaussoberi the only thing that matters for your root build.gradle is:

ext {
    compileSdkVersion = 30
    targetSdkVersion = 30
    .
    .
    .
}

[christocracy]

Release Accepted [React Native Demo].

Both the Flutter and React Native demo apps have been accepted.

I removed three words in the backgroundPermissionRationale.title for RN demo release, shortening to:

"Allow {applicationName} to access this device's location even when closed or not in use."

• Shortened phrase ”when [the app is] closed...” to simpler ”when closed...”

[christocracy]

It occurs to me with Google’s new app submission policy, where one must describe to Google how to login to the app and how to trigger the app’s UI to request background permission, that this system is susceptible to being gamed, like VW’s Emissions Scandal, where a developer could detect their app being reviewed and throw up a different backgroundPermissionRationale (or different UI altogether) than the one used in the usual production context.

Just a thought :)

[jpaas]

I have an app that only tracks location in the foreground. My AndroidManifest.xml contains ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION. I declared to Google Play that my app doesn't use background location but they've rejected the app because they say it does. Is there any way around this or do I have to go ahead and state that my app needs background location even when it doesn't? Seems like a good path to never getting approval.

[christocracy]

The plugin contains its own AndroidManifest.xml which is automatically merged into your app's AndroidManifest.xml.

<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
    <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
    <uses-permission android:name="android.permission.ACTIVITY_RECOGNITION" />
    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
    <uses-permission android:name="android.permission.ACCESS_LOCATION_EXTRA_COMMANDS" />
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
    <uses-permission android:name="com.google.android.gms.permission.ACTIVITY_RECOGNITION" />
    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
    <uses-permission android:name="android.permission.GET_TASKS" />

See my latest blog entry

[jpaas]

Ah yes the old tools:node="remove" I forgot about that. Thanks @christocracy !

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. You may also mark this issue as a "discussion" and I will leave this open.

[stale]

Closing this issue after a prolonged period of inactivity. Fell free to reopen this issue, if this still affecting you.

[AlberOliva]

¡Liberación aceptada!

Mi último cambio en Config.backgroundPermissionRationaleStrings funcionó. Mi último envío de la aplicación de demostración ya está disponible (versión Flutter). Los revisores serán muy exigentes con lo que dices:

backgroundPermissionRationale: { 
    title : "Permitir que {applicationName} acceda a la ubicación de este dispositivo incluso cuando la aplicación esté cerrada o no esté en uso". , 
    mensaje : "Esta aplicación recopila datos de ubicación para permitir grabar sus viajes al trabajo y calcular la distancia recorrida". , 
    PositiveAction : 'Cambiar a "{backgroundPermissionOptionLabel}"' , 
    negativeAction : 'Cancelar' 
  }

mira tu build.gradle y tiene DEFAULT_TARGET_SDK_VERSION 29

DEFAULT_XXXen el complemento se build.gradleaplican solo si no ha proporcionado extanulaciones en la raíz de su aplicación build.gradle.

@firdaussoberi, lo único que importa para tu root build.gradlees:

ext {
    compileSdkVersion = 30
    targetSdkVersion = 30
    .
    .
    .
}

Hola!, donde debo dejar este codigo?

[maxymczech]

Maybe you just got lucky with the reviewer. We are trying to submit an app with the following purpose:

The main purpose of the app is to provide information about real estate offers to app users, with intelligent suggestions based on recent user locations.

And the google reviewer just rejects it claiming "Based on our review, your declared feature does not meet the requirements for background location access."

[Daavidaviid]

Me too, I got the same message recently for an app update that keeps getting rejected

[gauravroyzz]

wait, my app doesnt use background location, still its getting rejected on playstore.

[christocracy]

doesnt use background location

So why are you using this plugin here which is named “background-geolocation”.?

did you read the last paragraph of that blog post?

[ghost]

We made a new RN app with the plugin and we get constantly rejected by Google Play because they say we ask : ACCESS_BACKGROUND_LOCATION while we do not request that permission at all in any place!

Our AndroidManifest :

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW"/>
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
<uses-permission android:name="android.permission.VIBRATE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.ACTIVITY_RECOGNITION"/>
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" /

Google reporting we ask:

android.permission.ACCESS_BACKGROUND_LOCATION
android.permission.ACCESS_FINE_LOCATION
android.permission.ACCESS_COARSE_LOCATION

So my question is: does the plugin auto set permission somewhere behind ?

In the plugin setting we have: locationAuthorizationRequest: 'WhenInUse’,

With : compileSdkVersion = 30 and the text above set for backgroundPermissionRationale

Still no way to pass Google Play validations!

Note: exact same iOS app is approved without any issues so I think this thread can be re-opened

[christocracy]

The plugin's Android library contains its own AndroidManifest which is merged into your app's.

<uses-permission android:name="android.permission.WAKE_LOCK" />
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
    <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
    <uses-permission android:name="android.permission.ACTIVITY_RECOGNITION" />
    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
    <uses-permission android:name="com.google.android.gms.permission.ACTIVITY_RECOGNITION" />
    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
    <uses-permission android:name="android.permission.GET_TASKS" />
    <uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" />

See my blog about *New Google Play Console Guidelines for "Sensitive App Permissions"

[mikehardy]

I was not able to pass google's review standard for requiring background access in my app (which I concede is fair, I'm pro-privacy and their rationale for rejecting my use of location in the background was appropriate) so the part about tools:remove from that blog is what I used. Works great, Play Store approved

However, if you do want to remove the android.permission.ACCESS_BACKGROUND_LOCATION from your app, simply add the following element to you AndroidManifest.xml

<manifest>
  <uses-permission
    android:name="android.permission.ACCESS_BACKGROUND_LOCATION"
    tools:node="remove" />
  .
  .
  . 
</manifest>

[shuzootani]

adding the remove statement in manifest causes build error The prefix "tools" for attribute "tools:node" associated with an element type "uses-permission" is not bound

Any idea to resolve this issue?

  <uses-permission
    android:name="android.permission.ACCESS_BACKGROUND_LOCATION"
    tools:node="remove" />

sorry. I just had to add xmlns:tools="http://schemas.android.com/tools" in manifest like

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">

[felipebutcher]

So why are you using this plugin here which is named “background-geolocation”.?

did you read the last paragraph of that blog post?

i used this with only foreground location too lol i don't know why, it's probably the first one i've found on the internet.