Android runtime permission for system apps - android

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.

Related

How to request permission on Android Things?

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 :

Unable to grant SET_ANIMATION_SCALE permission programmatically

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.

Android 6.0 - What is the difference between dangerous and special permissions?

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 Marshmallow, "dangerous" protection level and system components/apps

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.

Define a permission for third-party apps to use in Android

I want to define a permission in my Android app, and let other third-party apps to use. This permission is used to restrict calling of my modules. That is, third-party apps must request the right permission to call my module, just like using system permissions defined by Android system, android.permission.INTERNET or so.
In my test, I defined the permission in my app, say "my.apps.permission.my_permission", and then install it on emulator. In some of my Activities, android:permission="my.apps.permission.my_permission" property is added. This property forces the apps calling my activities must have the right permission "my.apps.permission.my_permission". Then in a test app, request the permission in AndroidManifest.xml, <uses-permission android:name="my.apps.permission.my_permission" />
The problem is, in the test app, which will call my permission-required activities, when I call startActivity(), I got a SecurityException : Permission Denied. But, if I defined a permission with the same name in the test app, everything works fine.
And, the followings are my conclusions:
1) It seems that, the permission defined in my app, "my.apps.permission.my_permission", is not visible to other third-party apps. How to make it visible, so that other apps can use my permission just like the ones defined in Android system?
2) Even is visible, Android won't check user-defined permissions with name conflicting.(I test this by define a permission with name "android.permission.INTERNET" in test app and overrides the system-defined one, and require "android.permission.INTERNET" in my app, and still, everything works fine.) If so, every other apps can define a permission with the same name that my module requires, and cheat my app. Is that right?
Anyone can help?
Thanks a lot!
I got the answer.
My own app, which defined the permission for other apps to use, must be installed before other apps who want to use my permissions. Otherwise, those apps must be re-installed, to use my permissions. No other operations or codes are needed, just <uses-permission android:name="my.apps.permission.my_permission" />, the same as other system defined permissions.
And, several apps may define permissions with the same name, conflicting with each other. The first installed app occupies the conflicting permission name, others won't overwrite or change the original permission.

Categories

Resources