Is there a way to tell if a certain Android permission is required by which Android APIs? For example, which APIs will require the GET_TASKS or REBOOT permissions? My app, inherited from someone who's long gone, has these permissions listed in the manifest. I don't think we are using them, but I'm also afraid that if I remove them, there will be bad consequences. Any ideas on how to deal with this?
Both of these permissions are quite specialized, and only have a few uses.
android.permission.REBOOT
First of all, this permission has a protection level of signatureOrSystem, so unless your application is part of a custom ROM or you have access to the signing keys for the platform you are installing it on, the application won't even be granted the permission.]
It is required to call PowerManager.reboot()
android.permission.GET_TASKS
This permission is only marked dangerous, so your app can actually obtain this one.
There are two calls in ActivityManager that require this permission, getRecentTasks() and getRunningTasks() to get information about the current application tasks in the system. It's often used by custom Launcher applications to populate task lists.
HTH
PScout was a tool that analysed Android SDK and generated a map that maps Android permissions to methods that require those permissions.
Original PScout website doesn't work anymore but I extracted the mapping from original PScout and pushed it to Github. You can easily check it out and parse it if you need it.
Here you can find all methods that PScout found which require Android permissions.
PScout results- map of Android permissions and methods that require those permissions
Take out each piece then run in. If it continues to work keep what is deleted and move down the list of permissions.
Related
I am getting very conflicting information regarding the use of android.permission.READ_LOGS Android permission. Firstly, the Android Documentation website does not specify the protection level of this permission. It is neither classified as normal, nor dangerous. They do specify the following:
"Not for use by third-party applications, because Log entries can
contain the user's private information."
Some websites say not to use it for the same privacy concerns.
However I have some issue with that:
When I tested this permission in my app on Android 7.1.1 (Nexus 5X) and Android 4.4.2 (old Samsung 8" tablet), neither of them prompted me that the app required this permission. Both said that the app requested "no special permissions". This only happens if the permission is deemed "normal", in which case it is automatically granted.
Secondly, using this permission, I can only view logs from logcat pertaining to my app, which does not log any personal information. Hence, I don't violate any privacy either. I thought this permission may allow me to see other app's logs, causing privacy issues.
So, if this is the case, then is it deemed safe to use this permission in a production version of the app? It would help me a lot in debugging strange bugs users face if they can send me a logcat by the press of a button.
EDIT: Ok, now I am quite confused. It appears that I don't need to explicitly specify this permission in the manifest either.
Is READ_LOGS a normal or dangerous Android permission?
Neither. As of Android 7.1, it is signature|privileged|development. That basically means that apps signed as part of the firmware build or installed on the privileged partition can hold the permission, but nothing else can.
the Android Documentation website does not specify the protection level of this permission
Correct. READ_LOGS is still in the SDK, for backwards-compatibility reasons, but ordinary apps have not been able to hold it since Android 4.1, which came out five years ago.
This only happens if the permission is deemed "normal", in which case it is automatically granted.
No.
I thought this permission may allow me to see other app's logs, causing privacy issues.
It did, on Android 4.0 and earlier.
then is it deemed safe to use this permission in a production version of the app?
Well, bear in mind that there has never been a documented and supported way for apps to access LogCat contents. Most likely, you're using one of the script-kiddie solutions that have been posted, such as running the logcat command and capturing its output. So, it is entirely possible that there are devices, now or in the future, that will not support your particular approach towards accessing LogCat. So, the permission is not your problem; the lack of a supported API for LogCat access is your problem.
Personally, I'd use a logging library to log the content to both a file and to LogCat, using the file for whatever your app needs it for.
I'd like to grant Android permissions (e.g. android.permission.DELETE_PACKAGES, which has protectionLevel=system|signature) to apps signed by a given signature and/or with a given package name from SELinux policies, but so far I haven't found a way that works. The mac_permissions.xml file used to accept an allow-permission tag that accepted Android permission strings, but based on the Lollipop code that parses it, that tag doesn't seem to be supported anymore. I tried using it anyway, and it definitely seemed to be ignored by the system.
Ideally, I'd only have to add/modify SELinux policy files as opposed to core AndroidManifest files that declare the restricted permissions and specify their protection levels. Assume that apps with the given signature/package wouldn't otherwise be granted said permissions by PackageManager because they lack any of the special privileges that Android permission protection levels recognize (signed by platform cert, installed in /system, etc.), and that the permission is a system permission (i.e. declared by the frameworks/base/core/res AndroidManifest) that is declared at OS build time.
Is there a way to allow a given app signature/package to use a given Android permission from SELinux?
All the MMAC work was abandoned by the SE for Android project as none of it was accepted upstream. Currently, there is no supported mechanism for associating package permissions to SE Linux policy. If your building Android, one could restore that work in their tree, the branches to start with are the seandroid branches here: https://bitbucket.org/seandroid/frameworks-base/branches/
However, the most up-to-date branches with the code are over a year old. So you may have porting issues.
Also, that code uses the mac_permissions.xml file for controlling access, but the EOPS, extended operations changes would also be of use, you can read up about it in its config file:
https://bitbucket.org/seandroid/external-sepolicy/src/ccb97c52cda2bac69c0499b3c76bc8e0d28d636c/eops.xml?at=seandroid-5.1.1&fileviewer=file-view-default
Bear in mind, the install time permission checks and the eops changes, while providing a form of mandatory access controls, don't really use core SE Linux technologies. By that, it can be used with or without an selnux enabled kernel.
If one really wanted to couple SE Linux to permission strings, it would require significant effort to label the permissions, and have Package Manager Service (PMS) and Activity Manager Service (AMS) compute whether or not access is allowed.
However, now that per-application android permission controls are available, most of the work is no longer needed.
I'm wanting to clarify on the key changes of marsh mallow 6.0.
Are there any changes that we need to be aware of as developers, as opposed to user only or OS features that do not affect development.
If so how do we manage these changes? example do we need to disable a feature, will it cause application crashes or it will open the setting page and asking for enabling the feature for that application.
I was so confused about how the recent changes affect developers, I was looking for some clarity.
As far as I can see there's no need to enable or disable features, the developer needs to be mindful of what target sdk they are developing in when creating or updating apps.
The biggest change to developers in the latest upgrade is Runtime Permissions.
Taken from:
Everything every Android Developer must know about new Android's Runtime Permission
Although Android is being keep developed but the latest update to Android M is totally different since there is some major change that would change everything like new Runtime Permission. Surprisingly it is not much talked about in Android Developer community even though it is extremely important and may cause some big trouble in the near future.
.../...
You might already feel like there is some cold wind blowing through your arms ... If you are an Android Developer, you will suddenly know that programming logic is totally changed. You cannot just call a function to do the job like previous but you have to check for the permission for every single feature or your application will just simply crash !
Correct. I would not spoil you that it is easy. Although it is a great thing for user but it is truly nightmare for us developer. We have to take coding to the next level or it will surely have a problem in both short-term and long-term.
Anyway this new Runtime Permission will work like described only when we set the application's targetSdkVersion to 23 which mean it is declared that application has already been tested on API Level 23. And this feature will work only on Android 6.0 Marshmallow. The same app will run with same old behavior on pre-Marshmallow device.
This means user permissions are not being requested at install time, but at runtime. This is done using a permission request, and can be saved by the user for one run of the app, or as a default 'always'. This permission can always be revoked in the device settings.
As the api is backward compatible, any devices running with apps of targer sdk < 23 will still be ok.
However these same apps will not run on android devices >= 6.0 with a target sdk of 23 if the runtime permissions are not implemented and the user failing to give permission needs to be managed to stop apps from crashing.
The only manisfest permissions that will require runtime permission requests are those that are deemed as a dangerous permission level, so accessing personal information, camera, etc.
Permissions are grouped and once a permission is given for one item of a group, permission is then granted for the remaining permissions of the group.
For more detail Sytem - Permissions.
Why exactly uses-permission
Ex :
<uses-permission>android:name="android.permission.ACCESS_NETWORK_STATE"/>
is needed to access various modules of Android. How is it that just adding one single line that too by the same programmer who is coding it, is actually providing security? I am new to Android programming and this is looking funny. Kindly explain what is the exact use of quoting the <uses-permission>
Google made a whole page to describe the concept. Go through it and you will know the reason.
http://developer.android.com/guide/topics/security/permissions.html
EDIT: In addition to above information. These required permissions are shown to the user at the time of installing the application. They are even visible at the google play store for each app. While most users don't see reqd permissions before installing, some might check them out and if its interfering with their privacy more than required they may not install it or even give bad reviews on play store. These are mentioned in AndroidManifest so Google doesn't have to go through all the scenarios to check what all services the application might request in future.
Whatever permissions you have added in <uses-permission> are actually used later at installation time of your application. User will be asked that this applications require following permissions: Access network states. And if user accepts, the application can be installed. Else application won't be installed.
Refer to this for ore clarification.
I'm wondering if it's possible to get Android permission dynamically without using AndroidManifest just with some codes, because I've some OSGi bundles running on Android and without Android permission they are restricted in functionality.
Thanks for your answers, yes it complicates the user experience and it's also dangerous for the user if that mechanism is provided
No this is not possible.
You can't alter the contents of an already installed APK. It would be very dangerous to allow such a behavior anyway as the whole permissions system is meant to allow the user to first read what permissions an Application requires so he can judge if it is ok or not.
No, sorry, you must request all permissions via the AndroidManifest.xml file.
Yes, i found this line in http://developer.android.com/guide/topics/security/security.html:
Android has no mechanism for granting permissions dynamically (at run-time) because it complicates the user experience to the detriment of security.
Guys now from Android 6.0 Marshmellow onward, you can ask users at runtime to allow permissions dynamically, I found of it, have a look at this link. I hope it will help you getting idea.