Status Update
Comments
xa...@google.com <xa...@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.
au...@google.com <au...@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...
sp...@google.com <sp...@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
sp...@google.com <sp...@google.com> #5
Not doing any post processing. No custom tasks. I will try to verify alignment now. Give me a sec.
sp...@google.com <sp...@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
AndroidLintTask
lists the lint baseline file (e.g.lint-baseline.xml
) as an@InputFiles
property, but the file is also functioning as an@Output
of the task, since Lint, as documentedThis isn't good practice in Gradle, and leads to some odd behavior.
For instance, if you:
gradlew app:lint -Dlint.baselines.continue=true
, generating a new baseline filegradlew app:lint -Dlint.baselines.continue=true
The baseline file is not re-created, since Gradle observes the same "before" state for both invocations and marks the task as
Up-To-Date
(Gradle doesn't include the file in the "after" snapshot for the task because the file isn't marked as an@Output
). A fix/workaround is pending for this particular issue, but there may be other issues inherent to this non-idiomatic use of the Gradle API.This comment proposes a fix in AGP for the broader issue.