Fixed
Status Update
Comments
re...@gmail.com <re...@gmail.com> #2
Also this should be handled like Activities with results. Some stubbing of intent should be possible and then checking permission result. just like the espresso intents are done.
si...@google.com <si...@google.com> #3
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.
dr...@gmail.com <dr...@gmail.com> #4
This bug has not been updated in over a year. Please reopen if this is still an issue or requires addition inspection.
si...@google.com <si...@google.com> #5
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
Java Version: 7
SDK Tools, Revision 24.4.1 (October 2015)
Taking a screenshot with the tool screenshot2 raise a NullPointerException on Ubuntu Server 14.04 and Kali Linux 2.0. It works on Mac OS X 10.11.
Command:
$ screenshot2 -e image.png
Error:
Exception in thread "main" java.lang.NullPointerException
at com.android.ddmlib.MonitorThread.wakeup(MonitorThread.java:580)
at com.android.ddmlib.MonitorThread.quit(MonitorThread.java:588)
at com.android.ddmlib.AndroidDebugBridge.terminate(AndroidDebugBridge.java:235)
at com.android.screenshot.Screenshot.main(Screenshot.java:198)