I have a Cleaner app in java that has features like - System cleaner, Whatsapp manager, and Basic file Explorer to list & delete files i.e. downloads, images, videos, documents and audio.
Now it has to comply with Google's scoped storage enforcement or it will be removed from the store.
My question here is:
How to I make sure I am using correct permissions to comply with this policy? While making sure the older versions of Android would
still work as normally (or scoped storage api works with them too?).
What I have already done:
<uses-permission
android:name="android.permission.WRITE_EXTERNAL_STORAGE"
android:maxSdkVersion="28" />
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.WRITE_INTERNAL_STORAGE" />
I have updated the permissions as shown above^ and set target sdk to 30, as well as removed requestLegacyExternalStorage flag from
manifest file.
Notice that WRITE_EXTERNAL_STORAGE is using max sdk = 28 tag, do I need to do this with other two (READ&WRITE) permissions also? (official doc only showed example of write-external-storage permission)
I'm still asking for these permissions in java code - do I need to wrap that code using if (Build.VERSION.SDK_INT < 30) to make sure
it's only asked in lower android versions or using the above tag in
manifest already takes care of that for me?
I have already implemented the requestDeletePermission() dialog for deleting files in Android 11 - it works! But for listing files in Basic explorer I'm
still using the old code that worked in old Android versions - do I
need to update that too? (Although it's still working with above 3 permissions)
Please help me I really have to finish it before the end of this month or my app will get removed. The whole point is to avoid violating the new policy in Android 11. I'm willing to give higher bounty to elaborative answers.
Thank you.
Related
In the android manifest, there are sometimes permissions named as:
com.google.android.gms.permission...
or android.permission....
Is this naming arbitrary or is there a reason for having different prefixes?
The reason I would like to know this is to be able to locate the right permissions I usually go to the https://developer.android.com/reference/android/Manifest.permission
This link contains only ones with "android.permission.*" I would like to know if there is a single reference somewhere for all the other permissions?
P.S. Below is an example of ACTIVITY_RECOGNITION being added to the manifest, trying to make sense of it.
<!-- Required for 28 and below. -->
<uses-permission android:name="com.google.android.gms.permission.ACTIVITY_RECOGNITION" />
<!-- Required for 29+. -->
<uses-permission android:name="android.permission.ACTIVITY_RECOGNITION" />
Is this naming arbitrary or is there a reason for having different prefixes?
android.permission is used for permissions in the Android Open Source Project.
com.google.android.gms.permission is used for permissions from what we think of as Play Services.
Other apps can define their own permissions, ideally in their own namespaces. But, they are just strings, so you or I could try defining a custom permission that starts with android.permission.
I would like to know if there is a single reference somewhere for all the other permissions?
Permissions are arbitrary strings from arbitrary developers. There is no way to know what all of them are. I am not aware of Google having documentation listing all of Play Services' permissions, but I cannot rule it out.
Below is an example of ACTIVITY_RECOGNITION being added to the manifest, trying to make sense of it.
This was tied to functionality that originally was supplied by Play Services and then moved into Android itself. So, the permission started with the Play Services namespace and then was cloned into the AOSP namespace.
My users are complaining that my app now requires "run at startup" permission according the listing on Google Play. I have no need for this permission so would like to remove it from my app. I assume it must be from a library that I use but which one? In the "Merged Manifest" there is nothing about "boot" or "startup". I just have these:
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.WAKE_LOCK" />
How can I track this down? My users are acting like I'm the anti-Christ for having this extra permission and I look stupid(maybe accurately) for not knowing why. Also, is there a list somewhere that shows what permissions correspond to what text on the Play store description page?
I want to address the comment about removing the permission. I understand how that is done and that's not what I'm asking. I need to know how to find the permission. Else, how can you remove something if you don't know what is is? Also, I may want to keep the permission but need to explain what it is for to my end-users.
#Mike is probably correct about WorkManager API. Still the question is how did he find that out? Why doesn't Android Studio show the permission in the Merged Manifest?
Also, even stranger is that I have removed the WorkManager API so the permission should be gone. I did check out the code for the released version and there are no left over references to WorkManager.
The easy way is from Android Studio. First build your app. Then from the build menu select Analyze APK. From there you can see the full AndroidManifest.
https://developer.android.com/studio/build/apk-analyzer
In my case the permissions did not show up in the Merged Manifest tab. Could be a bug. I think what happened is that I used a library during beta testing. Removed the code that uses library but still had a reference in build.gradle. That added the permission to the released apk's Manifest.
Im using WebRTC with cordova and I made the huge mistake of upgrading the version of android in the play store from 22 to 23. (apparently no way to revert this situation)
Now I must ask for the permissions at runtime. Everything is ok for now, but for WebRTC communication my app needs this particular permission "MODIFY_AUDIO_SETTINGS". For camera, microphone and location permissions I use cordova-diagnostic-plugin using those methods : requestCameraAuthorization, requestMicrophoneAuthorization and requestLocationAuthorization.
I tried requestRuntimePermission method with this as argument cordova.plugins.diagnostic.permission.MODIFY_AUDIO_SETTINGS but its not working since cordova.plugins.diagnostic.permission doesnt contain 'MODIFY_AUDIO_SETTINGS' permission. Here is the list of available permissions :
Im pretty much sur that the problem is the lack of 'MODIFY_AUDIO_SETTINGS' permission, since I had the same problem with android 22 (no audio) because I was not including it in the config. see this old SO post of mine
Thanks.
MODIFY_AUDIO_SETTINGS is not a "dangerous" permission that can be requested at run-time on Android: see here the full list of "dangerous" permissions which need to be requested at run-time.
I've mentioned the following permission:
<uses-permission android:name="android.permission.NFC" />
in my manifest.xml. But NFC code is no more in use and I commented the source code. Means NFC is no more in use for my app, but while installing the app, it's still shows in installing window.
So, is it possible in android that don't ask for permissions mentioned in Manifest.xml file, if code is not in use? Thanks
No, it is not possible, because the Android system has no idea which permissions your application requires before run-time. Picture the following scenario:
You are writing an application, not specifying NFC permission as you're not using it in your code, but you ARE using a framework that in 50% of the implementations do use NFC (device manufacturer specific framework).
The Android system has no way of telling if the NFC permission is required and thus it relies on your explicit instruction for permissions
As I'm sure you've noticed, an exception will be raised if the permission does not exist for the specified action
The only way to make sure the requirement is gone is to remove the permission from the manifest (and frankly, is it that much of a deal?)
Besides commenting out the unnecessary codes, you have to remove the permission from your manifest as well.
I wrote a program that worked perfectly until the market required me to add 'minSdkVersion'. Since I was using 2.3.3 capabilities I set it at 10,but then my program stopped being able to access files from the disk (all file access is false though it works without 'minSdkVersion'). Changing it to require API 1 fixed the functionality but now inadequate OS versions can download it. Should the 'minSdkVersion' be able to change actual functionality? Any ideas what could cause this?
You should set minSdkVersion to the lowest adequate OS version for your app. Don't forget to also set targetSdkVersion to the highest level for which your app has been tested.
I'm going to assume when you say "access files" you mean on the SD card.
In this case, you need to add 2 new permissions:
<uses-permission
android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<uses-permission
android:name="android.permission.READ_EXTERNAL_STORAGE"/>
These permissions weren't added until API level 4, so anything below that gets them for free.