I am writting an UI test in Espresso for an Android app. I need to take an screenshot of the screen to verify the UI, I do it through the UiDevice.takeScreenshot() method.
This method is throwing an Exception because the app has no write permissions, in order to run this UI tests, I need to specifically add the android permission in the AndroidManifest:
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
Then execute the app, go to Android settings, enable this permission; and then I can run the UI test. After that I need to go back to AndroidManifest, remove this permission (because I only need it for the UI tests).
Is there any cleaner way to achieve this without having to touch AndroidManifest and automatically grant write external storage permission for the UI tests only?
You can put the <uses-permission> element in an AndroidManifest.xml file in your androidTest/ source set, so it does not affect your production code.
To automatically grant the runtime permission during tests, you can try the new GrantPermissionRule. Or, use other techniques to grant the permission as part of your test suite. In the end, they all use:
adb shell pm grant com.package.myapp android.permission.<PERMISSION>
adb shell pm revoke com.package.myapp android.permission.<PERMISSION>
...either from Gradle or from your test code.
Related
I have an app that requires root access. I'm using the following code to request the permission:
Process p = Runtime.getRuntime().exec("su");
What this does is: when the user has granted the root access to the app, it displays the root sign (#) in the statusbar ( which is normal ). The symbol remains in the statusbar even after the app goes to the background or even after that activity is finished. I want the symbol to appear when the permission is granted, and releasing the granted root access after performing the operation, so it removes the symbol from the statusbar.
HideItPro does it so I know it's possible, but I couldn't find a way pf doing it. Can anyone help me how to do this ?
PS: I'm using RootTools sdk for root operations.
Android's permission system is different than traditional Linux. On normal, commercial devices there is no access to "root" and there is no su command. You have to have a rooted ROM for that functionality.
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 :
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.
When revoking a permission (e.g: Locations) from an App in Android Marshmallow, the app process is terminated. Is there any way to handle this for UI tests that wants to test different cases (permissions enabled/disabled)? Attempting to use UIAutomator to set the permissions in App Setting results in a crash since the app terminates right after permission is revoked. Appreciate any insight/comments!
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.