I have some Android permissions which I would like to know to which permision PROTECTION LEVEL they belong. Does anybody know how can this be checked? For example I need to know the PROTECTION LEVEL of android.permission.RECEIVE_BOOT_COMPLETED permission, but I would like to check many more.
EDIT:
I see that I didn't put it clearly: What I mean is not an API level with which permission was introduced, but permission protection level, one of four: Normal, Dangerous, Signeture, Signature Or System. It determines for example how this permission is presented to user during the application installation. How can I check to which protection level certain permission belongs?
A list of default permissions with the associated protection levels can be found in the latest source here:
https://github.com/android/platform_frameworks_base/blob/master/core/res/AndroidManifest.xml
Example:
<permission android:name="android.permission.INTERNET"
android:permissionGroup="android.permission-group.NETWORK"
android:protectionLevel="dangerous"
android:description="#string/permdesc_createNetworkSockets"
android:label="#string/permlab_createNetworkSockets" />
Keep in mind they could be changed by the OEM.
getPackageManager().getPermissionInfo(name, 0).protectionLevel
In this link you can see all the permissions of android.
The level you mark it here:
For Android-Permission..
To enforce permissions, various parts of the system invoke a
permission validation mechanism to check whether a given application
has a specied permission. The permission validation mechanism is
implemented as part of the trusted system process, and invocations of
the permission validation mechanism are spread throughout the API.
There is no centralized policy for checking permissions when an API
is called. Rather, mediation is contingent on the correct placement
of permission validation calls.
Permission checks are placed in the API implementation in the system
process. When necessary, the API implementation calls the
permission validation mechanism to check that the invoking
application has the necessary permissions. In some cases, the API
library may also redundantly check these permissions, but such checks
cannot be relied upon: applications can circumvent them by directly
communicating with the system process via the RPC stubs. Permission
checks therefore should not occur in the API library. In- stead, the
API implementation in the system process should invoke the permission
validation mechanism.
Also just go through with this documents for more info Android-Permission
You can find the protection level in the permission documentation
Related
I develop watchfaces for WearOS. I'm trying to modularize my code, by creating a base module that contains the common code for all my projects. Amoung other things, it should contain the code responsible for the in-app purchases. For this reason, I have to add <uses-permission android:name="com.android.vending.BILLING"/>. However, some projects don't have an in-app purchase. Therefore, these projects would inherit the BILLING permission, but actually woudn't need it.
So my questions are:
Is there a way around it? Like a way to conditionally specify aspects of the Manifest?
What are the consequences if I simply let this BILLING permission in, even if it's not required?
More generally, are there more "dangerous" permissions to let in when not required?
When uploading the app, you need to complete a Permissions declaration and the app goes through review. What you're seeking to do seems to explicitly run counter to the Play Store "Permissions policy" guidelines:
You may only request permissions that are necessary to implement current features or services in your app that are promoted in your Play Store listing.
I would expect your app to fail the review in light of this (or if it did pass the first time somehow, to possibly fail future reviews if it gets caught at a later stage).
Is there a way around it? Like a way to conditionally specify aspects of the Manifest?
I think there is no way of not declaring permissions in the manifest:
What are the consequences if I simply let this BILLING permission in, even if it's not required?
If it is a install-time permission the system will grant it automatically. But if it is a runtime-permission you must request the permission at runtime before usage.
So if you declare permissions that you do not need, in best case nothing happens. But I am not that much aware what kind of security issues can arrise from doing that.
Be aware that requesting permissions that you do not need in your App is against good practice:
Caution: Carefully consider which permissions you declare in your app's manifest. Add only the permissions that your app needs. For each permission that your app requests, make sure that it offers clear benefits to the user and that the request is done in a way that's obvious to them.
See also this post
Remove Permissions
You can also consider removing permissions in your (sub)modules that you declared in your base modules:
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" tools:node="remove"/>
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 an app using this method: getLine1Number from TelephonyManager
According to Android Documentation, this method needs READ_PHONE_STATE runtime permission. When I call this api without giving this permission, my app crashes. However, If I grant this app with the signature permission READ_PRIVILEGED_PHONE_STATE and without giving the READ_PHONE_STATE permission, the api works and the app does not crash.
Why is it the case?
the reason is simple, some APIs in order to work read permission from the android system as they are trying to access user-private data. Android, designed as a secure OS, would grant permissions to expose such data to these APIs. Some permissions needs to be explicitly agreed upon by the user, while some only need to be registered to keep track of.
Not including these permissions in the Manifesto will cause a permission not granted error and the app will crash as your source code probably does not have logic to deal with that.
I have read Dengerous permission and Normal permission as well. but I didn't find this permission anywhere. I just want to know what kind of permission is it?
WRITE_SETTINGS
added in API level 1
String WRITE_SETTINGS
Allows an application to read or write the system settings.
Note: If the app targets API level 23 or higher, the app user must explicitly grant this permission to the app through a permission management screen. The app requests the user's approval by sending an intent with action ACTION_MANAGE_WRITE_SETTINGS. The app can check whether it has this authorization by calling Settings.System.canWrite().
Protection level: signature
Constant Value: "android.permission.WRITE_SETTINGS"
Special Permissions
There are a couple of permissions that don't behave like normal and dangerous permissions. SYSTEM_ALERT_WINDOW and WRITE_SETTINGS are particularly sensitive, so most apps should not use them. If an app needs one of these permissions, it must declare the permission in the manifest, and send an intent requesting the user's authorization. The system responds to the intent by showing a detailed management screen to the user.
Source: https://developer.android.com/guide/topics/permissions/requesting.html#perm-groups
The protection level is signature. You must ask the user to be granted this permission if your API level is greater than or equal to 23.
You can find the documentation on all permissions here,
and you can find the documentation for the permission you specified here.
What is the best way to access the app usage database on Android, without using the API?
In particular, I would like to make a local copy of the database behind this API:
http://developer.android.com/reference/android/app/usage/UsageStats.html
There's no best way, other than the API. You may or may not receive the permission to access this data. On this page it says:
NOTE: This API requires the permission
android.permission.PACKAGE_USAGE_STATS, which is a system-level
permission and will not be granted to third-party apps. However,
declaring the permission implies intention to use the API and the user
of the device can grant permission through the Settings application.
It reads as though you might get the permission if you declare it and the user grants it... or you might not, as it will not be granted to third-party apps.