Status Update
Comments
sg...@google.com <sg...@google.com> #2
Okay. I tried a bunch of agp+android studio versions
The last working version was classpath("com.android.tools.build:gradle:7.4.0-alpha06")
once I moved to
classpath("com.android.tools.build:gradle:7.4.0-alpha07")
then things start breaking on firebase app dist.
ap...@google.com <ap...@google.com> #3
Scott, assigning to you as it seem to complain the zip is not aligned while packaging which is very puzzling considering the steps...
ap...@google.com <ap...@google.com> #4
OP, when you build the APK with AGP, are you doing any post-processing on the APK and/or do you have any custom tasks that are modifying the APK?
Can you try to verify the alignment of your APK with zipalign
locally (zipalign
is included in build-tools
):
zipalign -c -v 4 foo.apk
ap...@google.com <ap...@google.com> #5
Not doing any post processing. No custom tasks. I will try to verify alignment now. Give me a sec.
ap...@google.com <ap...@google.com> #6
Scenario 1:
built my apk with agp alpha09, but didn't update firebase (bom = 30.2.0)
/Users/idle/Library/Android/sdk/build-tools/31.0.0/zipalign -c -v 4 app-release.apk
"Verification succesful"
Scenario 2:
built my apk with agp alpha09, but I DID update firebase (bom = 30.3.1)
/Users/idle/Library/Android/sdk/build-tools/31.0.0/zipalign -c -v 4 app-release.apk
"Verification FAILED"
ap...@google.com <ap...@google.com> #7
Scenario 3:
built my apk with agp alpha09, with androidx.splash rc01
/Users/idle/Library/Android/sdk/build-tools/31.0.0/zipalign -c -v 4 app-release.apk
"Verification succesful"
Scenario 4:
built my apk with agp alpha09, with androidx.splash 1.0.0
/Users/idle/Library/Android/sdk/build-tools/31.0.0/zipalign -c -v 4 app-release.apk
"Verification FAILED"
In both failed cases if I do | grep BAD
I get
7216334 junit/runner/logo.gif (BAD - 2)
7217354 junit/runner/smalllogo.gif (BAD - 2)
ap...@google.com <ap...@google.com> #8
In the cases where zipalign
verification fails, is the APK generated by a clean build (e.g., ./gradlew clean :app:assembleRelease
)?
Does verification succeed if you add this to your build.gradle?
android {
packagingOptions {
exclude 'junit/runner/logo.gif'
exclude 'junit/runner/smalllogo.gif'
}
}
ap...@google.com <ap...@google.com> #9
In the cases where zipalign verification fails, is the APK generated by a clean build (e.g., ./gradlew clean :app:assembleRelease)?
I clean before i generate the apk using the Android Studio menu for generating an apk
Does verification succeed if you add this to your build.gradle?
I assume it will, but let me try. Any reason why changing from androidx.splash 1.0.0-rc01 to 1.0.0 stable (which is 0 changes. all it changed was the dependency version) that it fails verification. It seems like something else is wrong that's a bit deeper than just adding these two exclude statements.
ap...@google.com <ap...@google.com> #10
It seems like something else is wrong that's a bit deeper than just adding these two exclude statements.
I agree, but I'd like to find a workaround for you in the meantime.
I think I'll probably need a repro project to get to the bottom of it. In your other thread, it sounded like you weren't able to create a repro project... any luck since then?
ap...@google.com <ap...@google.com> #11
I was not able to create a repro unfortunately. As soon as I started to prune things out of my project it started to succeed.
Similarly. firebase came out with a new version. and if i use that new version... then it also succeeds. 🤯
I'm glad to hear there is a workaround for now (and i learned something new about zipalign). I will try to create a repo project again later today when I have about an hour or so free to play around with it, but for now I will just commit the
android {
packagingOptions {
exclude 'junit/runner/logo.gif'
exclude 'junit/runner/smalllogo.gif'
}
}
to my codebase because that did the trick for me. Everything works. Thank you for your quick response and helpful debugging steps.
ap...@google.com <ap...@google.com> #12
Thanks!
ap...@google.com <ap...@google.com> #13
not able to get a repro case. literally any minor thing i change makes this verify successfully. im a bit out of ideas. the only thing i can think of that might help is why is junit being packaged into my app.
and i think the reason for that is that I depend on okhttp3:mockwebserver:4.10.0
implementation("junit:junit:4.13.2") // Needed because mockwebserver has a dependency on it. This can be removed in okhttp 5+
so the apps i ship through firebase have a mockwebserver using okhttpmockwebserver, but version 4+ requires junit while okhttp 5+ (not yet released), removes this dep.
so maybe just playing around with adding junit as a dependency to an actual app might help repro?
source:
maybe still owrth checking out as there could be other deps that end up with the same issue. idk. just trying to be helpful i guess. but as for me. im going to consider this case closed. excluding the above like you mentioned has unblocked my team. cheers
ap...@google.com <ap...@google.com> #14
Thanks for looking into it!
I agree it's strange they have an implementation
dependency on junit, and I'm glad they're removing it in okhttp 5+.
I'll go ahead and close this bug for now.
ap...@google.com <ap...@google.com> #15
This is fixed by Change-Id: I12ec8785cd4dbb6e523c66b4620ed2388f448822, which will be in AGP 7.4.0-rc01 and 8.0.0-alpha08.
ap...@google.com <ap...@google.com> #16
Thanks for filing the bug, OP. Your observation in
ap...@google.com <ap...@google.com> #17
FUCK YEAH! Glad I was helpful! Appreciate you working through it with me here. Cheers. Once I update to alpha08 I will remove the workaround I added. cheers
ap...@google.com <ap...@google.com> #18
Branch: 8.0
commit 7b9dea5b4c29b5aa9dde2e4a7db4cb28b68c9caf
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Mar 03 08:43:32 2023
Fix test after changing API level for rewriting of JDK-8272564
Bug:
Change-Id: I67552a7fb13657ac9b4fb706592754d74d1b0653
M src/test/java/com/android/tools/r8/desugar/jdk8272564/Jdk8272564Test.java
ap...@google.com <ap...@google.com> #19
Branch: 8.0
commit 2a7c539ec35668c77b0eacb27612d7a5d8a2d11a
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Mar 03 08:43:21 2023
Also apply the rewriting for JDK-8272564 up to Andorid R
Bug:
Change-Id: I240de7d301677668b9c13b3b49c7b7951e6434b6
M src/main/java/com/android/tools/r8/utils/InternalOptions.java
sg...@google.com <sg...@google.com> #20
Backported to 8.0.33, 4.0.55 and 3.3.91 for AGP 8.0, 7.4 and 7.3 respectively. To use a specific R8 version merge the following into settings.gradle
or settings.gradle.kts
:
pluginManagement {
buildscript {
repositories {
mavenCentral()
maven {
url = uri("https://storage.googleapis.com/r8-releases/raw")
}
}
dependencies {
classpath("com.android.tools:r8:8.1.4-dev")
}
}
}
Description
From the issuehttps://github.com/android/android-test/issues/1642 reported on Espresso 3.5.1 it looks as if the rewrite for JDK-8272564 need to be applied to API level 28-30.
This was first applied before 26, but after b/231450655 it was also applied on API level 26 and 27. However the Espresso issue indicate that this can also cause issues on API level 28-30.
The failure is
The code as
androidx.test.espresso.matcher.ViewMatchers.getMismatchDescriptionString(ViewMatchers.java:3)
isHow that ends up in
org.hamcrest.BaseDescription.appendValueList(BaseDescription.java:76)
I cannot explain.If the JDK-8272564 rewrite is applied the
java.lang.IncompatibleClassChangeError
does not happen.