Fixed
Status Update
No update yet.
Comments
rm...@google.com
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.
br...@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.
tn...@google.com
This bug has not been updated in over a year. Please reopen if this is still an issue or requires addition inspection.
Description
all required information.
Studio Build: 3.4
Version of Gradle Plugin: 3.4.0 (also reproduced on 3.2.1)
Version of Gradle: 5.1.1 (also reproduced on 4.10.3)
Version of Java: 7
OS: OSX 10.14.4
Steps to Reproduce:
1. Open sample project attached
2. Run ./gradlew lint (fails due to adding baseline)
3. Run ./gradlew lint again (fails due to one `UselessLeaf` issue not having both locations added to baseline)
This issue has been seen on numerous out-of-the-box rules like `IconDuplicate` and `UselessParent`, and also custom lint rules. It would seem that the lint tool is filtering out files with duplicate names, or not passing all the files/nodes to the `Detector`s that need to visit them during the analysis phase, and therefore these `Issue`s are not added to the baseline. Then, when running again, these non-baselined `Issues`s are thrown.
In order to work around this, we are forced to copy the violations from the lint-results.xml into the baseline.