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 :
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 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.
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.
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)