Status Update
Comments
je...@google.com <je...@google.com>
al...@google.com <al...@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.
al...@google.com <al...@google.com>
al...@google.com <al...@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...
al...@google.com <al...@google.com>
xa...@google.com <xa...@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
sa...@google.com <sa...@google.com> #5
Not doing any post processing. No custom tasks. I will try to verify alignment now. Give me a sec.
sa...@google.com <sa...@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"
Description
Using a basic project with 1 app and 1 lib, using AGP 7.4.0 alpha 2, we see the following manifest files after a build:
The fact that we have 3 intermediate manifests in the app and (more importantly) 2 in the library is probably something we can optimize, in some cases.
The most important aspect here is the library as we need this for scaling. If the reason to have 2 is something we can put behind an opt-in feature that would be better.