There's no permission in Manifest class for the android.permission.PROCESS_INCOMING_CALLS permission. I need it for runtime asking for permissions.
There's no permission in Manifest class for the android.permission.PROCESS_INCOMING_CALLS permission.
That is because Android does not have such a permission, as you can tell by looking at Android's own manifest and looking at the various <permission> elements.
Related
What is the difference between privapp-permissions.xml in system/etc/permissions and default-permissions.xml in system/etc/default-permissions?
For refernce: https://github.com/opengapps/opengapps/issues/518#issuecomment-355230967
The link didn't understand properly.
Every private permissions used by apps in /system/priv-app/ should be put in privapp-permissions.xml.
The dangerous permissions used by apps in /system/ can be granted by default by system/etc/default-permissions.
private permissions are permissions declared in platfrom with system|signatured flags.
dangerous permissions are runtime permissions should be granted by users.
In later versions of Android (like 8.0.0), can we still declare normal level permissions in the manifest, like INTERNET permission and expect it to be granted at installation time?
<uses-permission android:name="android.permission.INTERNET" />
or do we need to explicitly request them through the code?
If the second, do we need to ask for it on every single activity?
can we still declare normal level permissions in the manifest, like INTERNET permission and expect it to be granted at installation time?
Yes. Only dangerous ones need to be requested at runtime.
Yes, you can declare normal level permissions in the manifest. But in 6.0 and above you have to check that permission is granted or not by user at runtime.
I have switched my app to target API 27 and now it can't be granted WRITE_EXTERNAL_STORAGE permission -- grantResult is always -1.
My app needs this permission since it doesn't use apps private external storage space (which doesn't require WRITE_EXTERNAL_STORAGE starting from API 19).
I know that in API 26 there have been behavior changes for permissions. However this doesn't explain my problem.
I'm requesting both READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions in a standard way:
ActivityCompat.requestPermissions(activity, new String[] {
Manifest.permission.READ_EXTERNAL_STORAGE,
Manifest.permission.WRITE_EXTERNAL_STORAGE
}, requestCode);
(both permissions are declared via <uses-permission in manifest).
The dialog appears and I click "Allow":
However inside onRequestPermissionsResult callback I'm getting a -1(denied) for WRITE_EXTERNAL_STORAGE (and 0 (granted) for READ_EXTERNAL_STORAGE).
Shouldn't the result be 0 for both since I have requested and, presumably, granted both?
I have tried to request WRITE_EXTERNAL_STORAGE alone, but in this case the dialog doesn't appear at all.
One more detail: I have just checked the merged manifest in build/intermediates/manifests/full/debug and noticed that WRITE_EXTERNAL_STORAGE permission has attribute android:maxSdkVersion="18" (there is no such attribute in my manifest). This could be happening because my app has minApiVersion=21, but I'm not sure.
Somewhere along the line, you are picking up that android:maxSdkVersion="18" attribute. My guess is that it is coming from a library. Check the "Merged Manifest" tab in Android Studio, when you are editing your own manifest. It will have details of what is contributing the various elements and attributes.
android:maxSdkVersion has the effect of removing your <uses-permission> element on higher Android SDK versions, at least in terms of how runtime permissions work.
Since you need this permission for all versions, adding tools:remove="android:maxSdkVersion" on the <uses-permission> element should revert the android:maxSdkVersion="18" and give you what you expect.
I noticed a space in my permission in manifest, it was <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE "/> and I changed it to <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/> and problem solved.
I'm trying to write to a value on AT. I've already declared required permission as follow in manifest,
<uses-permission android:name="android.permission.WRITE_SETTINGS"/>
And try to request permission at run-time, AT shows windows regarding permission setup. However the switch is not clickable. Regarding AT document
Requesting Permissions at Runtime is not supported because embedded
devices aren't guaranteed to have a UI to accept the runtime dialog.
Declare permissions that you need in your app's manifest file. All
normal and dangerous permissions declared in your app's manifest are
granted at install time.
However Settings.System.canWrite() always returns false.
Are there any special methods to enable permission WRITE_SETTINGS?
Like you said, the documents say:
Declare permissions that you need in your app's manifest file. All normal and dangerous permissions declared in your app's manifest are granted at install time.
Therefore you don't see the normal Android permissions UI.
From the release notes:
Dangerous permissions requested by apps are not granted until the next device reboot. This includes new app installs and new elements in existing apps.
So try powering off and on your Android Things device
After install application with the statement on AndroidManifest.xml as follow
<uses-permission android:name="android.permission.WRITE_SETTINGS"/>
It needs to be also run Settings as follow via adb
adb shell am start -S com.android.settings/.Settings
Then click APPS>YOUR_APP, then click permission.
Now the switch is clickable. So AT not granted to permission. It needs to be granted manually.
This permission is having Protection level: signature.Which means this permission is only granted to system apps.
Please find the below screenshot for your reference :
Android defines a set of permissions that third-party apps can request. Permissions are categorized by sensitivity; most permissions are either "normal" or "dangerous". Normal permissions are granted automatically, without prompting the user; dangerous permissions are presented to the user when the app is installed and the user is asked to consent to granting them.
Question: For any particular Android permission I have in mind, how can I tell whether it is a normal permission or a dangerous permission? Is there a list of dangerous permissions and a list of normal permissions?
(I know that third-party apps can declare their own permissions. I'm only asking about standard permissions. I know it may not be possible to get a 100%-complete list. I'm only looking for best-effort; something is better than nothing.)
For a related but different question, see also Where can I get a list of Android permissions (however, that's a different question; it doesn't at the normal vs dangerous distinction, and I don't necessarily need a complete list).
For more simplicity, below are list of Normal permissions taken from official docs:
As of API level 23, the following permissions are classified as PROTECTION_NORMAL:
ACCESS_LOCATION_EXTRA_COMMANDS
ACCESS_NETWORK_STATE
ACCESS_NOTIFICATION_POLICY
ACCESS_WIFI_STATE
BLUETOOTH
BLUETOOTH_ADMIN
BROADCAST_STICKY
CHANGE_NETWORK_STATE
CHANGE_WIFI_MULTICAST_STATE
CHANGE_WIFI_STATE
DISABLE_KEYGUARD
EXPAND_STATUS_BAR
FLASHLIGHT
GET_PACKAGE_SIZE
INTERNET
KILL_BACKGROUND_PROCESSES
MODIFY_AUDIO_SETTINGS
NFC
READ_SYNC_SETTINGS
READ_SYNC_STATS
RECEIVE_BOOT_COMPLETED
REORDER_TASKS
REQUEST_INSTALL_PACKAGES
SET_TIME_ZONE
SET_WALLPAPER
SET_WALLPAPER_HINTS
TRANSMIT_IR
USE_FINGERPRINT
VIBRATE
WAKE_LOCK
WRITE_SYNC_SETTINGS
SET_ALARM
INSTALL_SHORTCUT
UNINSTALL_SHORTCUT
And here is list of Dangerous permissions and permission groups:
CALENDAR : READ_CALENDAR, WRITE_CALENDAR
CAMERA : CAMERA
CONTACTS : READ_CONTACTS, WRITE_CONTACTS, GET_ACCOUNTS
LOCATION : ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION
MICROPHONE : RECORD_AUDIO
PHONE : READ_PHONE_STATE, CALL_PHONE, READ_CALL_LOG, WRITE_CALL_LOG, ADD_VOICEMAIL, USE_SIP, PROCESS_OUTGOING_CALLS
SENSORS : BODY_SENSORS
SMS : SEND_SMS, RECEIVE_SMS, READ_SMS, RECEIVE_WAP_PUSH, RECEIVE_MMS
STORAGE : READ_EXTERNAL_STORAGE, WRITE_EXTERNAL_STORAGE
Normal permissions are granted automatically, without prompting the user
AFAIK, the documentation is wrong here.
dangerous permissions are presented to the user when the app is installed and the user is asked to consent to granting them
AFAIK, all permissions have this behavior.
What this may have morphed into is that dangerous permissions are always displayed and normal permissions are ones that might be "below the fold" if there are enough dangerous ones.
For any particular Android permission I have in mind, how can I tell whether it is a normal permission or a dangerous permission? Is there a list of dangerous permissions and a list of normal permissions?
You can look at the source code.
I found this blogpost listing the "default" permissions by protection level. I think, this is the kind of list you were looking for.
The list might have changed in the meantime though, as the post is 10 months old. It provides sample code to recompile the list by yourself.
From android M permissions will be granted at runtime. User consent is not required for Normal permissions but for Dangerous permissions user is required to grant the permission to application.
Normal permissions: https://developer.android.com/guide/topics/security/normal-permissions.html
Dangerous permissions: Dangerous permissions cover areas where the app wants data or resources that involve the user's private information https://developer.android.com/guide/topics/security/permissions.html#normal-dangerous
Here is a good article which describes every thing about run time permissions ,
Normal permissions
android.permission.ACCESS_LOCATION_EXTRA_COMMANDS
android.permission.ACCESS_NETWORK_STATE
android.permission.ACCESS_NOTIFICATION_POLICY
android.permission.ACCESS_WIFI_STATE
android.permission.ACCESS_WIMAX_STATE
android.permission.BLUETOOTH
android.permission.BLUETOOTH_ADMIN
android.permission.BROADCAST_STICKY
android.permission.CHANGE_NETWORK_STATE
android.permission.CHANGE_WIFI_MULTICAST_STATE
android.permission.CHANGE_WIFI_STATE
android.permission.CHANGE_WIMAX_STATE
android.permission.DISABLE_KEYGUARD
android.permission.EXPAND_STATUS_BAR
android.permission.FLASHLIGHT
android.permission.GET_ACCOUNTS
android.permission.GET_PACKAGE_SIZE
android.permission.INTERNET
android.permission.KILL_BACKGROUND_PROCESSES
android.permission.MODIFY_AUDIO_SETTINGS
android.permission.NFC
android.permission.READ_SYNC_SETTINGS
android.permission.READ_SYNC_STATS
android.permission.RECEIVE_BOOT_COMPLETED
android.permission.REORDER_TASKS
android.permission.REQUEST_INSTALL_PACKAGES
android.permission.SET_TIME_ZONE
android.permission.SET_WALLPAPER
android.permission.SET_WALLPAPER_HINTS
android.permission.SUBSCRIBED_FEEDS_READ
android.permission.TRANSMIT_IR
android.permission.USE_FINGERPRINT
android.permission.VIBRATE
android.permission.WAKE_LOCK
android.permission.WRITE_SYNC_SETTINGS
com.android.alarm.permission.SET_ALARM
com.android.launcher.permission.INSTALL_SHORTCUT
com.android.launcher.permission.UNINSTALL_SHORTCUT
Dangerous permissions
in Android Studio,you can open your AndroidManifest.xml and press F1 on every permission you used then you can see if it is dangerous which the doc may shows.
New permissions are added as new Android versions are released, so any list included in your code will go out of date.
If you need a future-proof approach, it's possible to determine at runtime whether a permission is dangerous.
fun Context.isDangerousPermission(permissionName: String): Boolean {
val permissionInfo: PermissionInfo = try {
packageManager.getPermissionInfo(permissionName, 0);
} catch (ex: PackageManager.NameNotFoundException) {
return false
}
return if (Build.VERSION.SDK_INT >= 28) {
permissionInfo.protection == PermissionInfo.PROTECTION_DANGEROUS
} else {
permissionInfo.protectionLevel and PermissionInfo.PROTECTION_DANGEROUS != 0
}
}
This extension function returns true if a permission is dangerous.
For example:
activity.isDangerousPermission("android.permission.CAMERA") // true
activity.isDangerousPermission("android.permission.INTERNET") // false