Status Update
Comments
xa...@google.com <xa...@google.com>
to...@gmail.com <to...@gmail.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.
je...@google.com <je...@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...
to...@gmail.com <to...@gmail.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
ds...@gmail.com <ds...@gmail.com> #5
Not doing any post processing. No custom tasks. I will try to verify alignment now. Give me a sec.
je...@google.com <je...@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"
ds...@gmail.com <ds...@gmail.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)
je...@google.com <je...@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'
}
}
ds...@gmail.com <ds...@gmail.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.
je...@google.com <je...@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?
al...@google.com <al...@google.com>
je...@google.com <je...@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.
al...@google.com <al...@google.com> #12
Thanks!
al...@google.com <al...@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
al...@google.com <al...@google.com>
to...@gmail.com <to...@gmail.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.
to...@gmail.com <to...@gmail.com> #15
This is fixed by Change-Id: I12ec8785cd4dbb6e523c66b4620ed2388f448822, which will be in AGP 7.4.0-rc01 and 8.0.0-alpha08.
Description
For single file artifact like bundle
variant.artifacts.use(updateBundleArtifact)
.wiredWithFiles(
UpdateArtifactTask::initialArtifact,
UpdateArtifactTask::updatedArtifact
)
.toTransform(ArtifactType.BUNDLE)
it set this value
originalArtifact: app\build\outputs\bundle\debug\signDebugBundle\app-debug.aab
updatedArtifact: app\build\outputs\bundle\debug\debugUpdateArtifact\out
There are more weird things:
- why there is this "sign" prefix for the original file? It should be just "debugBundle"
- why output file is "out". and not app-debug.aab
- According to Xavier Ducrohet only the final artifact should be inside of outputs folder
- Then I don't see the reason for changing the name of the folder debugBundle to debugUpdateArtifact (if only final artifact should be there), it will really help with old plugins that will not use new variant API and will depend on the hardcoded path.
- I would really appreciate if there will be also the possibility to change the name of the output artifact during this transform, not the only file content.
And when I use this
variant.artifacts.use(updateApkArtifact)
.wiredWithDirectories(
UpdateDirArtifactTask::inputDir,
UpdateDirArtifactTask::outputDir
)
.toTransform(ArtifactType.APK)
It set this
Input folder: app\build\outputs\apk\debug
Output folder: app\build\intermediates\apk\debug\debugUpdateAPKArtifact
- output folder is inside of intermediates instead of input one
- also here I would expect that the output folder will be the same as the normal output folder for APK without transformation (for last one transformation in the chain). Why another level of the hierarchy?
There is one more unexpected thing that
val artifacts = builtArtifactsLoader.get().load(inputDir.get())
artifacts?.elements?.forEach {
it.outputFile is just String. I would expect File there.
Build: AI-202.7660.26.42.6987402, 202011210045,
AI-202.7660.26.42.6987402, JRE 11.0.8+10-b944.6842174x64 JetBrains s.r.o, OS Windows 10(amd64) v10.0 , screens 2560x1440, 2560x1440
AS: 4.2 Beta 1; Kotlin plugin: 1.4.20-release-Studio4.2-1; Android Gradle Plugin: 4.2.0-beta01; Gradle: 6.7; NDK: from local.properties: (not specified), latest from SDK: (not found); LLDB: pinned revision 3.1 not found, latest from SDK: (package not found); CMake: from local.properties: (not specified), latest from SDK: (not found), from PATH: (not found)
IMPORTANT: Please read