In the final AndroidManifest (in Temp/StagingArea/) they are still there:
And calling ./aapt.exe d permissions my.apk still outputs ACCESS_FINE_LOCATION among others.
Is there any way to suppress silent adding of such permissions? Exporting to Android Studio project is not an option — I have absolutely no time or desire to overcomplicate build scripts on continuous integration machine.
Thanks!
P.S. Also signing in to forum is almost completely broken, please fix it. It takes several times to manage to sign in since forum immediately forgets it after you logged on. At least on Google Chrome.
Any ideas? How to get rid of ACCESS_FINE_LOCATION? On Android 6.0 we don’t request this permission in run time — everything still works (like interstitials and rewarded video). All we want is to remove it from AndroidManifest altogether.
(Logging in to forum is broken, have I mentioned it?)
Thank you very much for answering, I really appreciate this! It would be great if you could help me to solve this nasty issue.
I’ve checked all AndroidManifests.xmls, and unpacked all *.aars to check their manifests — no one lists ACCESS_FINE_LOCATION.
Probably calls are hidden somewhere inside compiled plugins. But everything works fine on Android 6.0 where we do not request this permission in runtime. So probably call to Input.location is in some non-executing or non-critical branch. It’s VERY important not to add unnecessary dangerous permissions to Manifest, this concerns featuring in Google Play Store.
I just want to force suppressing ACCESS_FINE_LOCATION and READ_PHONE_STATE by all means, regardless if it is formally used by some ad plugin or something like that.
Please, realize that implicit adding dangerous permission is actually a critical bug to be fixed, not some convenient feature. It makes us (the game from top-200 selling) lose money in three ways:
Users churn on installing as they afraid of «permissions for spying».
Google refuses featuring; they require either to remove unnecessary permissions, or ask for them in runtime in right place (on Android 6+). We do not ask them since everything is working just fine without these permissions, falling back to some default behaviour if permission is not granted.
To avoid adding READ_PHONE_STATE permission I’ve removed Chartboost Fyber plugin — this stopped adding READ_PHONE_STATE to AndroidManifest. But that means that we do not receive revenue from this network anymore.
If some plugin uses permission in some way, it DOES NOT MEAN that this permission is vitally important for plugin. Plugin can handle the absence of permission just fine.
The chances that a plugin is going to crash the whole application when the permission is missing - are very high.
You could export the project and modify the manifest in Android Studio manually, however we cannot guarantee anything then.
The correct approach will be to:
do a binary search within your plugins by disabling half of them at a time. Find the offending plugin;
check the managed libraries of the plugin in question for location calls;
fix it or make sure you never get into this code path.
Not in our case. On Android 6 plugins are not granted these dangerous permissions anyway (even if they are listed in AndroidManifest) — since we never ask them in run-time. But plugins still work, probably, because they just check if permission is not granted and correctly handle this case, executing fallback branch.
No, we cannot, because “If you just switched to export your Android project using Gradle instead of the old system, you may encounter build errors, especially if you are using additional Android libraries, or if you have added a custom AndroidManifest.xml.” https://docs.unity3d.com/Manual/android-gradle-troubleshooting.html
Even if some plugin adds one of these permissions I do not want to exclude this plugin. I just want to let it work without permission, being tested. If some ad plugin uses permission and finds out that permission of fine location is not granted, it just continues working with fallback settings.
Unity does not statically analyze code paths, so even if calls are in branches that are never really executed, Unity detects that API calls (if (checker.HasReferenceToMethod(...)) and adds permission: manifestXML.AddUsesPermission().
Is there any way to fix this Unity script to prevent adding dangerous permission in case if I am sure suppressing is safe?
I’ve managed to narrow down the list of assemblies. Loaded all 59 of them to dotPeek (all hail JetBrains), and searched all references to UnityEngine.Input.location. Looks like in this particular case I can get rid of found plugin.
But I hope you understand, that this critical issue still has to be fixed in Unity.
By using “binary search”, I meant to find the offending plugin (what you have successfully done), not disabling it forever.
Your assumptions are mostly correct. However, this is not a bug - it’s preventing the application from crashing because of poorly written plugins. The fact that your particular plugin handles it correctly does not guarantee anything - we want Unity to run smoothly with any plugin.
Thank you for your feedback! Permissions are a huge pain for everybody - we’ll think of how we can handle them in a nicer way.
But what else was I supposed to do? «Fix it» — patch third-party dll via Reflector to cut out Input.location calls? «…Or make sure you never get into this code path» — the problem obviously remains even if branch of call to Input.location is never executed — Unity detects references to it, does not analyse code flow. I’ve described this scenario in filed bug-report.
It’s a hack to rely on postprocess patching instead of good API design. And it would not be so harmful if I could suppress applying this patch.
I hope that you can provide the API for checking and requesting permissions in run time for Android 6+.
We are encountering the exact same issue as you did. I can’t just let dangerous permissions to be in my app.
Did you manage to solve this problem somehow? I would be very grateful if you could help me.