Status Update
No update yet.
Comments
xa...@google.com
As I understand it, we need to migrate namespace definitions both from AndroidManifest.xml and from implicit definitions from applicationId / testApplicationId? Is that right? So an 8.0 project would have a
namespace <n>
testNamespace <tn>
where <n> is taken from AndroidManifest.xml package definitions if present, and applicationId if not, and <tn> is testApplicationId if present and <n>.test if not?
au...@google.com
Sorry for the confusion. AGP would change how it computes the namespace for the androidTest variant. All the Upgrade assistant would need to do is update the source code for the import of the R class.
sp...@google.com
OK! And, I think, this should happen at the same time as the namespace declaration is migrated from AndroidManifest.xml?
sp...@google.com
It's unrelated, but it is possible that we move 8.0 to also only declare the namespace into the DSL. I would make it a separate refactoring because they are not tied at all.
sp...@google.com
I would consider first adding the right new value to models (as a new property) and then, to avoid Studio interpreting manifests and build configurations, just update to whatever the synced value of this new property is.
Description
AndroidLintTasklists the lint baseline file (e.g.lint-baseline.xml) as an@InputFilesproperty, but the file is also functioning as an@Outputof 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=trueThe 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