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.
Related
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.
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.
Is there a way to automatically accept permissions on a user's mobile and without the interaction of the user with the app? When the app launches, the permissions should be accepted automatically. Please suggest me any idea/hack to do it.
Thanks
Yea its possible , For that you need change targetSdkVersion (SDK v26 or any version above to SDK v22) to targetSdkVersion SDK v22 in build.gradle , in this case it will not ask to user to grant perssion , it will take permission automatically and why its working because granting permission introduce in sdk 23 and above
Note :- it may be ask permission in OPPO phones , Vivo etc while runtime.
Sample Peoject Link :- https://github.com/kdblue/PermissionGranted
No problem if the solution is illegal but I want a way to do it
Whats this mean?
First of all this is impossible. If you are working on a technology then you have to follow its guidelines.
The second thing is if your app targets Android M or greater then you have to follow the Permission model .
If your app target is below Android M then you do not have to ask for Runtime permission, the permissions will automatically granted on installation all at once.
Note:- Starting from Android M User can manually allow/disallow the permission to any third party app . So in that case you won't get SecurityException but your feature would not work .
Conclusion:- As you see your app is going to effect anyhow whether its targets low or high, So its better to follow the Permission model and make use of Android's new version's. As Android's new versions rolls out to more and more users, apps that request permissions at the time of installation will be viewed as un-maintained or poorly written, as users will expect not to have to agree to permissions up front, which leads to bad user experience .
I want to ask for any permission to the user after installing the app.
Is it possible to request runtime permissions from current API(7.0) to API level 19 (4.4)?
I've read the documentation and I've tried a lot of examples.
Everything seems too complex and I've even seen plugins to request permissions.
The documentation provides an example usign several NuGet Packages:
https://developer.xamarin.com/samples/monodroid/android-m/RuntimePermissions/
But it only works with Android M (6.0 API level 23) and above...
This article talks about it:
https://blog.xamarin.com/requesting-runtime-permissions-in-android-marshmallow/
For example, in my case I want to check if the app have the "permission CAMERA" and if not ask for the user, something like this:
if (Android.Support.V4.Content.ContextCompat.CheckSelfPermission(this, Manifest.Permission.Camera) != (int)Permission.Granted) {
// Permission has never been accepted
// So, I ask the user for permission
ActivityCompat.RequestPermissions(this, new String[] { Manifest.Permission.Camera }, REQUEST_CAMERA);
} else {
// Permission has already been accepted previously
}
The application opens without displaying anything.
The check works but "RequestPermissions" don't ask anything to the user.
Why not show anything?
Why I need to use "ActivityCompat" if also doesn't work in versions prior to M?
Can anyone give me an example to request runtime permission from a simple code (compatible with versions prior to M)?
I got the same result as you, so did a little investigation. The trick is that you have to set permissions in 2 places.
1. In manifest
2. Request permissions in run time
As shown here https://developer.android.com/training/permissions/requesting.html
the result is different.
On all versions of Android, your app needs to declare both the normal and the dangerous permissions it needs in its app manifest, as described in Declaring Permissions. However, the effect of that declaration is different depending on the system version and your app's target SDK level:
If the device is running Android 5.1 or lower, or your app's target SDK is 22 or lower: If you list a dangerous permission in your manifest, the user has to grant the permission when they install the app; if they do not grant the permission, the system does not install the app at all.
If the device is running Android 6.0 or higher, and your app's target SDK is 23 or higher: The app has to list the permissions in the manifest, and it must request each dangerous permission it needs while the app is running. The user can grant or deny each permission, and the app can continue to run with limited capabilities even if the user denies a permission request.
Runtime Permissions were introduced in Android 6.0 (API 23 - Marshmallow). As such you will not be able to programmatically set up Runtime Permissions on any Android API lower than 23. The Requesting Runtime Permissions in Android Marshmallow guide you linked in your question is likely the best resource here, and the Check the SDK Version section shows the logic for checking the API level and preventing the Runtime Permissions workflows from being called on API levels prior to 23.
For previous API levels from 22 and prior you will need to add your install-time permissions in your AndroidManifest.xml as described in the Add Permissions to Android Manifest guide.
Besides setting your Permissions in Manifest.xml you can check the permission using Xamarin.Essentials: Permissions
It automatically prompt the user to Allow or Disallow the requested permissions.
Background
I remember that it was told (on one of Google's videos) that if the previous version of the app was updated to have targetSdk 23 on the new version, ALL permissions that were granted before - will stay granted now.
So, for example, if you installed an app with targetSdk 22, that required a permission to read from the contacts, then even after an upgrade of the app, to one with targetSdk 23, it will stay this way.
The reason is simple: the user already granted the permissions upon install.
The problem
According to what I've found, there is an exception to this rule:
If your app had the permission SYSTEM_ALERT_WINDOW , and now you upgrade to targetSdk 23, it gets revoked (reset), and you need to request it from the the user.
This behavior isn't mentioned anywhere in the docs:
http://developer.android.com/reference/android/Manifest.permission.html#SYSTEM_ALERT_WINDOW
http://developer.android.com/guide/topics/security/permissions.html
http://developer.android.com/about/versions/marshmallow/android-6.0-changes.html
http://developer.android.com/about/versions/marshmallow/android-6.0.html
And also not in any video I've watched.
The only thing that's mentioned about SYSTEM_ALERT_WINDOW permission, is that you need to handle them differently, using ACTION_MANAGE_OVERLAY_PERMISSION to request the permission, and Settings.canDrawOverlays(...) to check if the permission is granted
What I've tried
I tried to contact Google about this issue, and they said it's intentional:
I spoke with the development team and the behavior you're seeing is
working as intended. This is documented here:
http://developer.android.com/reference/android/Manifest.permission.html#SYSTEM_ALERT_WINDOW
The protection level of SYSTEM_ALERT_WINDOW was raised in Android M.
The questions
Are there other permissions that have this behavior?
What would happen, if the app had targetSdk 22/23, and there was an upgrade of the OS to Android 6 ? Will the SYSTEM_ALERT_WINDOW (or any other permission) get revoked?
Pretty sure other stuff will stay granted, but I'd like to ask anyway: What about other special permissions-like features, such as : SAF, admin, usage-access, accessibility access, notification access, ... ?
EDIT: about #2, here's the answer from Google (link here):
On OS upgrade the app should keep SYSTEM_ALERT_WINDOW. Pre-API 23 apps
have the permission by default, as opposed to API 23 Apps that are off
by default. However, there is a known bug that for API 23 Apps they
were losing SYSTEM_ALERT_WINDOW on upgrade. The recommendation for a
developer is to always check the status of SYSTEM_ALERT_WINDOW at
start and if not granted, direct the user to Settings. We will be
fixing the issue in a future release.