Fixed
Status Update
No update yet.
Comments
au...@google.com
It seems that maybe D8 when it is desugaring returns all of the classpath instead just the subset that is testImplementation.
au...@google.com
jedo@ can you triage this? It is blocking is from moving to 3.5.0
je...@google.com
cm...@google.com
Huh, this is fixed for me by upgrading *gradle* from 5.3.1 to 5.4.1...
cm...@google.com
Which as AGP 3.5 now requires Gradle 5.4.1 this is potentially safe to close as obsolete.
au...@google.com
Do we know what fixed it? I would suggest adding a test to make sure we dont regress in this way in the future.
cm...@google.com
I'm not sure, Ivan might be familiar with what changed.
ga...@google.com
The last Gradle snapshot version with this bug is gradle-5.4-20190308000236+0000-bin.zip. Snapshot published after that one behaves correctly (gradle-5.4-20190308071035+0000-bin.zip).
[Deleted User] <[Deleted User]>
I recently found "testImplementation" dependencies declared in shared Android libraries are now propagating to other modules that consume the libraries via "implementation <library_name>". I thought only api and implementation dependencies were supposed to be packaged into consuming modules? My project uses AGP 3.4 / Gradle 5.4 although I'm not 100% sure when this behavior started happening. Just curious if this is intended behavior or whether I should file a separate issue for this.
For example:
Module A: testImplementation robolectric
Module B: implementation A
B cannot reference robolectric classes at compile time (as expected), however, Module B's test/ pass with AndroidJUnit4 test cases (not expected). This shouldn't be possible because the robolectric dependency is only declared for Module A's test/ suite, not Module B's test/ suite. I don't recall testImplementation behaving this way before. Is that supposed to propagate test dependencies like this?
For example:
Module A: testImplementation robolectric
Module B: implementation A
B cannot reference robolectric classes at compile time (as expected), however, Module B's test/ pass with AndroidJUnit4 test cases (not expected). This shouldn't be possible because the robolectric dependency is only declared for Module A's test/ suite, not Module B's test/ suite. I don't recall testImplementation behaving this way before. Is that supposed to propagate test dependencies like this?
ga...@google.com
Re #10: By design, any dependency added to androidTestIimplementation/testImplementation configuration is only for that project. If they are added to the runtime classpath of the consuming projects, that's a bug. Can you please file a new issue with reproduction to track this?
ga...@google.com
This is the Gradle commit that fixes the issue - https://github.com/gradle/gradle/commit/e5577e4fd00d6c0049169599fc45055cd0376956 . This got merged in 5.4, and that's why it works with that version. I'll add an integration test on our end to make sure we do not regress, as it is not clear why this commit fixes the issue.
ga...@google.com
The issue form #1 still happens when Jetifier transform does not run. When android.enableJetifier=true, updating to 5.4 fixes the issue. However, if android.enableJetifier=false we still package external libraries from tested APK in the test APK.
ja...@gmail.com
Re #11 It turns out that the issue described in #10 only appears to be a problem in Android Studio. I filed that issue with a sample project at https://issuetracker.google.com/issues/132692227 .
cm...@google.com
For #10/#14 this is a known issues with us modelling each gradle project as one IDEA module, where module dependencies means that tests depend on tests.
cm...@google.com
Ok, Ivan and I have figured out the root cause.
The issue comes from the fact we subtract the *files* of the main from the dependencies.
However, desugaring is (rightly) dependent on the order of dependencies, and so the user adding dependencies that share transitives lead to different produced files, and the subtraction therefore doens't have the intended effect.
Instead we need to switch to subtracting by component identifier identity or something similar, which has the beneficial side effect of not dexing all of the main dependencies when not requested.
The issue comes from the fact we subtract the *files* of the main from the dependencies.
However, desugaring is (rightly) dependent on the order of dependencies, and so the user adding dependencies that share transitives lead to different produced files, and the subtraction therefore doens't have the intended effect.
Instead we need to switch to subtracting by component identifier identity or something similar, which has the beneficial side effect of not dexing all of the main dependencies when not requested.
cm...@google.com
This will ship in AGP 3.5.0-beta04
Description
Gradle 5.3.1
Android Plugin Version:
AGP 3.5.0-alpha12
Moving from AGP 3.5.0-alpha11 -> AGP 3.5.0-alpha12 there is a regression where applications that target Java 8 [1] will have test apks incorrectly include all the dependencies from the app regular dependencies. Namely, if your app depends on appcompat, test apk will also bundle appcompat, but it should not as test app can instrument the classes in the app.
Issue does not happen without specifying target and source compatibility.
Issue does not happen when using AGP 3.5.0-alpha11.
Attached hello world project that simply adds target version java 8.
[1]
android {
compileOptions {
sourceCompatibility = JavaVersion.VERSION_1_8
targetCompatibility = JavaVersion.VERSION_1_8
}
}