I'm having trouble putting a new version of an app in the play store and was hoping someone could help me out. The previous versions of this app were basically a different app, the new version is built from the ground up. When I upload the app bundle for review I eventually get a status update that there is an issue with the background location permission, and that it is missing from the permission declaration form (because i removed it, it should not be needed anymore). It states there is at least one feature that uses this access. In the affected APK(s) it shows a bundle that was published over a year ago which is confusing me.
The "new" app is using the ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION permissions with the compileSdkVersion 30, minSdk 21 and targetSdk 30. This version should not be using background location access so additionally I've added the following line to the AndroidManifest.xml:
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" tools:node="remove"/>
I also have the the tools declared inside the manifest tag at the top of the file.
when I run the app and look at it's permissions under apps/myapp/permissions i see the coarse and fine location access, but no background access . The background access is also not in the list of permissions when exploring the bundle in the play store and not to be found when analysing the bundle and manifest in AndroidStudio.
When going through the packages I can't find an indication of a package that might be inserting this permission.
I'm wondering if there is a better way for me to debug this instead of uploading to the play store for review and what I might be missing here for the approval.
Android 10 (API level 29) introduced some changes to location permissions. The effect of that change for apps targeting older versions of Android is as follows:
If your app runs on Android 10 or higher but targets Android 9 (API level 29) or lower, the platform applies the following behavior:
If your app declares a element for either ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION, the system automatically adds a element for ACCESS_BACKGROUND_LOCATION during installation.
If your app requests either ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION, the system automatically adds ACCESS_BACKGROUND_LOCATION to the request.
So any version of your app still available in Google Play which uses ACCESS_FINE_LOCATION and/or ACCESS_COARSE_LOCATION, and has a targetSdkVersion <= 28 will now automatically have the ACCESS_BACKGROUND_LOCATION on devices running Android 10 or above. Whether it actually reads location data in the backgrund is a different matter; the important thing here is that it declares the permission.
These rules apply to all your release tracks - whether it's the production track, the alpha/beta track, an internal test track, etc. If any of them fits the criteria listed above, you'll have to publish an updated version of your app on that release track.
If you are absolutely sure that you are not using the permission anywhere inside your code. It's time to check you dependencies, if any one of them is using this permission.
Related
Our app for navigation: minSdkVersion 21, targetSdkVersion 30. We have no services in the background, we remove our updatelistener in onPause() and we request only location permission ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION, so we should never be even able to use a location in the background. So far the theory. In the App COntent section we indicated we indeed don't use locations in the background and there the questionnaire does not continue, as the interaction flow ended there successfully.
But Google just removed our app from the Play store as it believes it is violating the policy about using the device location in the background. The Developer Permission Declaration in de Play store has a Sensitive App Rights section mentioning "Location rights: not used in the background".
In interaction with Google - very cumbersome - we got this after weeks:
We found that your app is not compliant with the Location Permissions policy, or we were unable to review and verify your in-app experience for compliance with this policy.
If you have determined that your app does not require location in the background, complete the following steps to remove background usage and reach compliance:
For any APK targeting Android 10 or newer (SDK level 29 or higher):
Remove the ACCESS_BACKGROUND_LOCATION permission from your app APK or app bundle
[If minimum SDK level is 28 or lower] If you’re using ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION, examine your code paths and restrict usage to foreground purposes only (learn more)
You should no longer see the Location declaration listed under App Content
For any APK targeting Android 9 or older (SDK level 28 or lower):
If you’re already using ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION, examine your code paths and restrict usage to foreground purposes only (learn more)
In your console declaration, select “No” to the question “Does your app access location in the background in APKs or app bundles targeting Android 9 or older?”
We believe we did exactly that. ANy interaction over email takes days and always goes into a loop, back to square one.
Our questions:
Could it be that the MapBox library 6.6.0 uses locations in the background? We don't call their code to initialize any fetching of locations, as we update the map position ourselves.
Is there any way of determining where the violation - if at all - takes place?
Any other improvements that may help?
One month ago Google Play Console rejected my latest update and said that it is not compliant with the location in the background policies.
More precisely, the google email reports " 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."
I used the background location permission for scanning BLE in ionic app (https://github.com/don/cordova-plugin-ble-central ).
I removed the background location permission (ACCESS_BACKGROUND_LOCATION) from cordova plugin because, after some test, is effectively not really necessary. However, are necessary other location permission (ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION) so I would like to know if is equally necessary to display a prominent disclosure through a pop-up alert before my app’s location runtime permission.
I tried to send an issue ticket to google developer support on April 14th, but I have not received a reply.
If you target Android API version 28 or lower, ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION implicitly implies background location permission and you must hence follow all the rules for that.
If you target Android API version 29 or higher and do not have ACCESS_BACKGROUND_LOCATION in your manifest, you will automatically comply to Google Play's background policies (since you are then not affected by them).
I have an app on Google play store that uses the Flutter image_picker. I have received an alert from Google which says that I cannot use requestLegacyExternalStorage =true in my manifest file. I am confused and don't know what to do because in the documentation of image_picker it clearly says that we should use requestLegacyExternalStorage in the manifest file. Please help me solve this problem and is there a workaround for this?
If your targetSdk is not 30 you can keep using the flag android:requestLegacyExternalStorage="true" and you don't have to do anything.
From this post:
Google Play restricts the use of high risk or sensitive
permissions,
including a special app access called All files
access.
This is only applicable to apps that target Android 11 (API level 30)
and declare the MANAGE_EXTERNAL_STORAGE permission, which is added
in Android 11. Also, this policy does not impact the usage of the
READ_EXTERNAL_STORAGE permission.
If your app does not require access to the MANAGE_EXTERNAL_STORAGE
permission, you must remove it from your app's manifest in order to
successfully publish your app. Details on policy-compliant alternative
implementations are also detailed below.
If your app meets the policy requirements for acceptable use or is
eligible for an exception, you will be required to declare this and
any other high risk
permissions
using the Declaration Form in Play Console.
Apps that fail to meet policy requirements or do not submit a
Declaration Form may be removed from Google Play.
Also, this GitHub post have a good discussion about this:
SDK 41 contains all the necessary changes to make your app compatible
with Android 11, and should not result in removal from the Play Store.
There is no action for you to take. Just because you received this
warning, does not mean your app is infringing on the new scoped
storage policy. According to this
response
from someone at Google, they sent this warning to anyone using the
requestLegacyExternalStorage flag since it is their best indicator
of apps that may need to declare the MANAGE_EXTERNAL_STORAGE
permission.
If you're on SDK 41- you have nothing to do, you can ignore this warning.
If you're on SDK 40 or below- you can ignore this warning since it's specific to targeting Android 11.
Check out also this useful links:
https://developer.android.com/about/versions/11/privacy/storage
https://www.androidcentral.com/what-scoped-storage
I have an app which contains <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
Is there a way to delay asking the user for the location permission until they take an account which requires it? I've tried removing uses-permission from the XML, this breaks location even after programmatically asking for location permissions.
I do programmatically ask for location info, but that only seems to work if the permission is also specified in the XML.
I am assuming that you are experiencing this as you're targeting below Android 6.0?
As per the docs
Android 6.0 Marshmallow introduced a new permissions model that lets
apps request permissions from the user at runtime, rather than prior
to installation. Apps that support the new model request permissions
when the app actually requires the services or data protected by the
services.
Therefore, you will be unable to avoid requesting permissions before the user actually needs to use that particular service, unless you target a higher API level.
If you need permission, you can not remove it from manifest. If your target API is above 23 (Android 6) Just ask for permission programmatically when you need it. You as developer determine when to ask for permissions.
Otherwise if user's device is below android 6 or if your target API is below 23 then permissions will be requested at install time and you can not change it.
I have created an app which amongs others show the SSID name.
Now with the latest android version, the user needs to set extra permissions (<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />) for my app to be able to get the SSID name.
Now that's all fine, but 1. these permissions are harder to get (I understand that I can't just ask for them but the user has to explicit go to the app-settings and accept the location permission) and, more importantly 2. I don't want to ask for those rights if the user is still on an old(er) version of Android and these extra permissions are not needed.
I have these settings
minSdkVersion 11
targetSdkVersion 26
so also very old Android versions can install my app, and now they also have to give the permission for the Android version they don't yet have?
I would like that only users on the latest version of Android have to give these permission, and users on older Android versions don't have to.
Is it possible to make this distinction in the manifest?
I've seen a reference to Is it available to set checkSelfPermission on minimum SDK < 23? but that question doesn't talk about the manifest xml and that's what my question is about
User won't have to go explicit to the app-settings, just check the Android version with
android.os.Build.VERSION.SDK_INT >= N
And if it is true, you should ask the permission with
Activity.requestPermissions(String[] permissions, int requestCode)
Then listen the result with Activity.onPermissionsResult.