I need to grant my device permission to change automation settings of the device it is running on (for testing purpose).
I have added to manifest:
<uses-permission android:name="android.permission.SET_ANIMATION_SCALE"/>
And in my Activity on resume:
String[] permissions = new String[1];
permissions[0] = Manifest.permission.SET_ANIMATION_SCALE;
ActivityCompat.requestPermissions(getCurrentActivity(), permissions, 0);
Log.d("ISGRANTED", " " + (ContextCompat.checkSelfPermission(getCurrentActivity(), permissions[0]) == PackageManager.PERMISSION_GRANTED));
And nothing happens. I test on Android Api 23+ and I don't get any dialog to get the permission. Log returns:
06-30 15:03:32.757 17771-17799/my.app.package D/ISGRANTED: false
But if I replace permisions[0] with Manifest.permission.GET_ACCOUNTS (which is also in my manifest above SET_ANIMATION_SCALE permission) then it works. Dialog appears and log returns true.
What's the problem?
Please take a look at my Gradle plugin, Cappuccino. It automates the process of disabling system animations for Espresso testing. There are detailed instructions on Github.
From here or here, because it's not for use by third-party applications:
"android.permission.SET_ANIMATION_SCALE" : ["signature|system|development", "Modify the global animation scaling factor. Not for use by third-party applications."],
ProtectionLevel (from here):
signature 2 A permission that the system is to grant only if the requesting application is signed with the same certificate as the application that declared the permission. If the certificates match, the system automatically grants the permission without notifying the user or asking for the user's explicit approval.
system 0x10 Old synonym for "privileged".
privileged 0x10 Additional flag from base permission type: this permission can also be granted to any applications installed as privileged apps on the system image. Please avoid using this option, as the signature protection level should be sufficient for most needs and works regardless of exactly where applications are installed. This permission flag is used for certain special situations where multiple vendors have applications built in to a system image which need to share specific features explicitly because they are being built together.
development 0x20 Additional flag from base permission type: this permission can also (optionally) be granted to development applications.
Related
One of our developers made android application with all permission in manifest.xml (ACCESS_FINE_LOCATION, USE_FINGERPRINT ect.).
I guided him to remove unnecessary permission then he told me, "It is safe, because he used android 6.0 run-time permission (pop up the permission)".
But I think it is not safe because it can be abused.
Do I think wrong?
There are two kind of permissions, normal and dangerous. All declared normal permissions are in effect if declared in the manifest.If the app min sdk is Android 6.0 and above, until the user grants the permissions at runtime, the dangerous permissions are not in effect. It doesn't matter if they are declared in the manifest.It may be dangerous if the user grants the app dangerous permissions and you allow other apps to access some resources using your apps permissions like PendingIntent.
As suggested by Cao Minh Vu
It is better to request permissions which your app really requires.If you request a permission that is not required by your app users may think your app is malware.
For Example:
If you are requesting permissions for camera which is not required for your App even though giving permission or denying it is up to the user but it may cause user to be skeptical.And Probably user may uninstall your Application.
Question about Android runtime permissions. AFAIK, android grant dangerous permission at runtime. I reset my phone, then adb pull /data/system/users/0/runtime-permissions.xml, I found android.ui.system has already granted many dangerous permissions. can anybody tell me how it does?
The mechanism to insert dangerous runtime permissions into the /data/system/users/0/runtime-permissions.xml file via a user-confirmed dialog applies only to third party applications, and is not relevant for built-in applications.
For built-in/system applications and framework components, all
permissions are granted by default when a new user is created or
when the device boots and a systemReady event is fired.
You can see the AndroidManifest.xml from AOSP, where all types of required permissions are written for system components.
For third party apps, when the user grants any runtime permission, it gets added into the file /data/system/users/0/runtime-permissions.xml. The permission gets removed from the file when the user revokes it from any third party app. In the case of a full factory reset, runtime permissions of all third party apps are removed, as /data/system/users/0/runtime-permissions.xml gets deleted (data partition wipe).
But even after a factory reset, /data/system/users/0/runtime-permissions.xml contains runtime permissions (even dangerous ones) for system apps, see the default permissions: runtime-permissions.xml.
And it happens because:
All the default permissions are granted from
PackageManagerService, via these two methods:
newUserCreated() //this get called when new user is created
systemReady() //this get called when device is booted
and the above methods internally invoke:
DefaultPermissionPolicy.grantDefaultPermissions();
Have a look at How DefaultPermissionPolicy triggers
And if you see DefaultPermissionPolicy's implementation, it
contains all the relevant method to load all type of permissions for
System components.
Specifically DefaultPermissionPolicy.grantDefaultPermissions()
internally calls
grantPermissionsToSysComponentsAndPrivApps(userId);
grantDefaultSystemHandlerPermissions(userId);
and it internally invokes grantRuntimePermissionsLPw(), which
performs all the remaining work.
Privileged Permission Allowlisting
Device manufacturers had little control over which signature|privileged permissions could be granted to privileged apps. Starting in Android 8.0, manufacturers must explicitly grant privileged permissions in the system configuration XML files in the /etc/permissions directory.
Android allow system apps present in these directories(system/product/vendor/oem/ | _ext) to whitelist their permissions via writing a XML file.
XML file content:
<permissions> <privapp-permissions package="x.y.z"> <permission name="android.permission.PACKAGE_USAGE_STATS" /> </privapp-permissions> </permissions>
Android.bp file:
prebuilt_etc { name: "x.y.z.xml", system_ext_specific: true, src: "x.y.z.xml", sub_dir: "permissions", }
Add 'x.y.z.xml' to PRODUCT_PACKAGES to make this part of final image (same as for an app)
On target: XML file can be found under 'partition/etc/permissions/priv-app'
PackageManager parse all the XML files and whitelist the permissions mentioned for the package name while install the app on boot.
As the guide from google states out, there are normal, dangerous and special permissions.
Dangerous are, as far as I understand, disabled as default (is this true?).
If an app declares that it needs a dangerous permission, the user has to explicitly grant the permission to the app.
Does this infect also updates or only new installs?
And what exactly is the difference between the dangerous permission and
the special permissions?
Android says for special permissions:
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.
Is that not the same like the quote above? I do not get the difference.
Thanks!
System permissions are divided into two categories, normal and dangerous:
Normal permissions do not directly risk the user's privacy. If your
app lists a normal permission in its manifest, the system grants the
permission automatically.
Dangerous permissions can give the app access to the user's
confidential data. If your app lists a normal permission in its
manifest, the system grants the permission automatically. If you
list a dangerous permission, the user has to explicitly give
approval to your app.
Ques : Dangerous are, as far as I understand, disabled as default (is this true?).
Ans : Yes Dangerous permissions will be disabled by default.
Ques : Does this infect also updates or only new installs?
Ans : There are Two cases
Case 1 : App Targeting & running on API Level 23
If your app is targeting API Level 23, then all the permission which are defined in the Android Manifest will now ask for a permission when they need it.
For example, instead of giving an app access to your camera when you install it, you’ll be prompted the first time the app wants to access your camera.
Case 2 : App Designed for Older Version
Older Android apps automatically get these permissions when you install them, but you can revoke any permission you want from Settings >> Apps >> App >>App Info >> Permissions.
http://developer.android.com/training/permissions/requesting.html
Dangerous
Basically Google decided to mark some permissions dangerous (see full list here). Those permissions need to be requested actively if you want to use them, so you can't just put them in the manifest and expect everything to work, it wont. But if the user gives access once, you can use that permission for the remainder of the applications life (unless the user goes in and clicks it off inside settings).
The request will open a dialog on top of your app where the user can decide if you are allowed the permission.
Special
Special are like dangerous, except even harder to use. In order to use special you have to start an intent requesting the permission so the user goes to a Google defined activity that manages everything.
This is how it works for apps targeting Android 6.0 and onward.
Android M not showing normal permission like Internet, WIFI in the permission list. Its just saying No special permission to display. Is that how Android M will display permission, it will never show permission prior to install. Can any one experienced this before.
attached screenshot,please check it.
Please help me to finding this answer.
Thanks.
Quoting the documentation:
When the user installs or updates the app, the system grants the app all permissions listed in the manifest that fall under PROTECTION_NORMAL. For example, alarm clock and internet permissions fall under PROTECTION_NORMAL, so they are automatically granted at install time. For more information about how normal permissions are handled, see Normal Permissions.
The system may also grant the app signature permissions, as described in System components and signature permissions. The user is not prompted to grant any permissions at install time.
(emphasis added)
I'm developing an application that going to be pr-installed (as a system app) on the firmware.
from the documentation so far about the relation between system apps, new permissions model, and the protection levels - I don't understand exactly when system app needs (if at all) to request user permission.
My problems starts when I try to use the WRITE_EXTERNAL_STORAGE permission. from the documentation I can see that it marked as "dangerous" permission.
- does "dangerous" permissions grant automatically to system apps?
when I use WRITE_EXTERNAL_STORAGE permission (as a system app) I'm getting security exception, and I don't know if it's mean that even tough my app installed as a system app - "dangerous" permissions must be requested by the user..
another point to mention:
to check the app behavior as a system app, I'm installing my application APK on the sys-priv directory (the device is rooted) of a nexus 5 running SDK preview 3. this is when I'm getting the security exception when attep to use methods requires the external storage permission..
After a lot of digging and debugging, I finally found some clue of granting runtime permission on marshmallow for system app, with a lot of inspirations in this stackoverflow ticket.
The key logic is in DefaultPermissionGrantPolicy. After systemReady, PackageManagerService checks if this user's default runtime permissions are not set yet(i.e. this is a new user), if so, PackageManagerService calls DefaultPermissionGrantPolicy.grantDefaultPermissions() to check/grant permissions:
public void grantDefaultPermissions(int userId) {
grantPermissionsToSysComponentsAndPrivApps(userId);
grantDefaultSystemHandlerPermissions(userId);
}
There are two cases that your built-in app may be automatically granted with runtime permission.
A> grantPermissionsToSysComponentsAndPrivApps -> will grant runtime permission with FLAG_PERMISSION_SYSTEM_FIXED and FLAG_PERMISSION_GRANTED_BY_DEFAULT.
if your system app has uid<10000, you will be granted with permissions for your user group.
if your system app fits all below conditions, it will be granted the permissions.
is a privilegedApp (under /system/priv-app/)
is persistent (android:persistent="true")
signed with platform signature.
B> grantDefaultSystemHandlerPermissions -> will grant runtime permission with FLAG_PERMISSION_GRANTED_BY_DEFAULT .
If your app is considered as a "default platform handler app", (i.e. your app is "expected to work out-of-the-box", like camera, dialer, SMS, calendar .etc, you can read more in method grantDefaultSystemHandlerPermissions()).
Other than that, your system application needs to ask user for granting dangerous permission, as long as it has targetSdk set to 23.
Quoting the release notes for the 2nd M preview:
Apps included in the system image are no longer granted dangerous permissions automatically. All apps should check for and request permissions at runtime.
That fits with what I recall seeing when I first used the stock Camera app on a Nexus 5 with the final(?) 6.0 preview firmware — it too asked for the runtime permission.
So, AFAIK, system apps have to ask for runtime permissions, as do non-system apps.