Fixed
Status Update
Comments
as...@gmail.com <as...@gmail.com> #2
./gradlew installDebug also fails with the same error.
vi...@google.com <vi...@google.com>
je...@google.com <je...@google.com>
as...@gmail.com <as...@gmail.com> #3
Furthermore, the -g option should not be added by default (with no way to disable) on all installs as it doesn't allow for easy testing of runtime permissions.
cm...@google.com <cm...@google.com> #4
Yuki, change ag/I3db0d26664d163f9164ee3f8c0f5c3916611445b seems to be the root cause.
4.1.0-beta02 is also impacted.
as...@gmail.com <as...@gmail.com> #5
Runtime permissions were introduced in API 23, so this is most likely the root cause.
cm...@google.com <cm...@google.com> #6
I'll fix this issue by simply adding a API level check. "-g" option was added at the level 23.
We had a discussion in the team and decided to set "-g" by default. Here's reasons: 1) testing libraries (e.g. Espresso, orchestrator, etc) require it. 2) Starting in Android 10, a dialog is displayed asking for permission when you run a legacy apps (https://developer.android.com/about/versions/10/privacy/changes?hl=en#user-permission-legacy-apps ). This behavior change makes existing tests to be failed without "-g" option. 3) Dealing with the runtime permission check dialog in instrumentation tests is not easy and not reliable.
We had a discussion in the team and decided to set "-g" by default. Here's reasons: 1) testing libraries (e.g. Espresso, orchestrator, etc) require it. 2) Starting in Android 10, a dialog is displayed asking for permission when you run a legacy apps (
cm...@google.com <cm...@google.com> #7
Defaulting it to enabled with a wrapped api level check is fine but it should also be possible to disable it in the AGP dsl. it should be left up to the developer to decide when the permissions are granted and when they aren't. Especially given where it is implemented it applies to all installs done by Gradle, not just during instrumentation tests.
cm...@google.com <cm...@google.com> #9
I am experiencing the same issue. My instrumentation tests are installed with permissions granted. This causes our builds to fail, as we have espresso tests to verify the user paths when permissions are not granted.
What is the ETA for this DSL for disabling the automatic permission granting for instrumentation tests?
If have changed the behaviour completely with the release 4.1.0 you should at least provide at the same time the DSL which disables new behaviour.
At the moment this issue blocks further updates of AGP and in the end is a blocker to migrate to Jetpack Compose for many developers.
What is the ETA for this DSL for disabling the automatic permission granting for instrumentation tests?
If have changed the behaviour completely with the release 4.1.0 you should at least provide at the same time the DSL which disables new behaviour.
At the moment this issue blocks further updates of AGP and in the end is a blocker to migrate to Jetpack Compose for many developers.
Description
I upgraded to Android Gradle plugin 4.0.0 which required me to upgrade the Gradle wrapper as well. I upgraded the Gradle wrapper to 6.4.1 from 5.6.4. After the upgrade, I got following exception when trying to run instrumented tests with testCoverageReport enabled.
Build logs with Gradle 6.4.1 -https://github.com/ashutoshgngwr/noice/runs/722643012#step:4:2
Build logs with Gradle 6.1.1 - https://github.com/ashutoshgngwr/noice/runs/722702335#step:4:2
build.gradle - https://github.com/ashutoshgngwr/noice/blob/master/build.gradle
app/build.gradle - https://github.com/ashutoshgngwr/noice/blob/master/app/build.gradle
Studio Build: N/A Version of Gradle Plugin: 4.0.0 Version of Gradle: 6.4.1 Version of Java: openjdk version "1.8.0_252" and openjdk version "10.0.2" 2018-07-17 OS: Linux
Steps to Reproduce:
./gradlew wrapper --gradle-version 6.4.1
./gradlew clean connectedCheck
./gradlew wrapper --gradle-version 6.1.1
(downgrade)./gradlew clean connectedCheck
Please do let me know if I can provide any further information.