Feature Request P3
Status Update
No update yet.
Comments
pa...@gmail.com
Do you have a repro project that you could share with us?
There should be no need to excluding any dependencies: we automatically remove them from the test APK if they are in the main APK.
There should be no need to excluding any dependencies: we automatically remove them from the test APK if they are in the main APK.
a....@gmail.com
I've implemented a solution which leverages wrapper classes, overriding and build variant configuration. The solution is quite long to explain and is found over here: https://github.com/ahasbini/AndroidTestMockPermissionUtils .
It is not yet packed in an sdk but the main idea is to override the functionalities of ContextWrapper.checkSelfPermission and ActivityCompat.requestPermissions to be manipulated and return mocked results tricking the app into the different scenarios to be tested like: permission was denied hence the app requested it and ended with granted permission. This scenario will occur even if the app had the permission all along but the idea is that it was tricked by the mocked results from the overriding implementation.
It is not yet packed in an sdk but the main idea is to override the functionalities of ContextWrapper.checkSelfPermission and ActivityCompat.requestPermissions to be manipulated and return mocked results tricking the app into the different scenarios to be tested like: permission was denied hence the app requested it and ended with granted permission. This scenario will occur even if the app had the permission all along but the idea is that it was tricked by the mocked results from the overriding implementation.
ae...@google.com
This bug has not been updated in over a year. Please reopen if this is still an issue or requires addition inspection.
gr...@gmail.com
This is most definitely still an issue.
With permission checks (rightly!) being encouraged contextually, the need to be able to test the various different pathways and permutations of requesting permissions, having them granted or denied, requesting again and ensuring that rationale messages are displayed etc. is more important than ever.
The lack of espresso to be able to provide the ability to reset the permissions mid-suite is a pretty major deficiency.
Description
Using UiAutomator to manually revoke a permission will cause the process to restart, resulting in an error in the test case "Instrumentation run failed due to 'process crash'". Same with using ActivityManager to clear the application data and reset the permissions state.
Right now the only option is to use a separate framework to test the APK by itself and do the OS interactions to reset permissions and then relaunch the application and navigate through the application to an area that would interact with the permission.
It would be very useful if there was a way for us to either:
1) Revoke a permission from a test runner without killing the process (unlikely, since that's enforced at the OS level)
2) Call an API that would revoke the permission, and signal the test runner to restart the process and continue at the test case where it left off.
Not sure if this is possible or not, but it would be very helpful.