Status Update
Comments
je...@google.com <je...@google.com>
ra...@google.com <ra...@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.
ra...@google.com <ra...@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...
je...@google.com <je...@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
wk...@google.com <wk...@google.com> #5
Not doing any post processing. No custom tasks. I will try to verify alignment now. Give me a sec.
al...@google.com <al...@google.com>
al...@google.com <al...@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"
al...@google.com <al...@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)
ca...@google.com <ca...@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'
}
}
al...@google.com <al...@google.com>
ra...@google.com <ra...@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.
al...@google.com <al...@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?
wk...@google.com <wk...@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.
je...@google.com <je...@google.com> #12
Thanks!
ke...@gmail.com <ke...@gmail.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
je...@google.com <je...@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.
ly...@gmail.com <ly...@gmail.com> #15
This is fixed by Change-Id: I12ec8785cd4dbb6e523c66b4620ed2388f448822, which will be in AGP 7.4.0-rc01 and 8.0.0-alpha08.
vi...@spotify.com <vi...@spotify.com> #16
Thanks for filing the bug, OP. Your observation in
al...@google.com <al...@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
li...@pinterest.com <li...@pinterest.com> #18
de...@google.com <de...@google.com> #19
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Dolphin Beta 2 (2021.3.1.11)
- Android Gradle Plugin 7.3.0-beta02
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
je...@gmail.com <je...@gmail.com> #20
Hi guys new here.. need your help to fix things right. Not for me I give you my word.. I had already refunded 2 times.. please don’t let your good system get exploited by malicious user that prey on end user. Really hope good pro skill guys like you all can keep a good image and uphold what’s right! Thanks again
je...@gmail.com <je...@gmail.com> #21
Even now I just notices the report I wrote to raise here but not under my name!? So many other user!!! Please help!
sh...@pinterest.com <sh...@pinterest.com> #22
jb...@twitter.com <jb...@twitter.com> #23
Hi there - just for clarification: the release notes here say this fix was merged for 7.2.1, back in May (patch 1):
However the discussion here in June indicates this will be part of 7.2.2 (which is unreleased afaik). Can anyone clear up this discrepancy?
jb...@twitter.com <jb...@twitter.com> #24
FYI for those following - it looks like AGP 7.2.2 was released yesterday so we should be unblocked to use baseline profiles with app bundles (I haven't yet verified personally).
ju...@arkea.com <ju...@arkea.com> #25
I have similar issue and just try it out the AGP 7.3.1.
The bad location of profile still remain in this release (com.android.tools.build.profiles instead of assets.dexopt)
Any update about this ?
Thanks
be...@google.com <be...@google.com> #26
Using the
- Build release bundle
- Extract apks
- Extract universal apk
- Inspect apk in Android Studio
The Baseline Profile can be found under assets/dexopt/baseline.prof{m}
when inspecting an apk, even though it is under com.android.tools.build.profiles
when inspecting an aab.
se...@gmail.com <se...@gmail.com> #27
je...@google.com <je...@google.com> #28
#27, please file a new bug, bonus if you include a repro case.
Description
go/baseline-profiles for context.
Currently when building app bundles, baseline profiles are not being packaged into
assets/dexopt/baseline.prof
.This causes the profiles to get dropped and the app is no longer optimized.