add lint script for Android with baseline

[dnfield]

Fixes flutter/flutter#28847 (still need post-submits Cirrus will run this on pre and post submits)

This will start running the linter on our Java files for each commit and catch if any new violations are created.

As we fix things, we can rerun the script with --rebaseline (which removes the baseline.xml file and regenerates it).

/cc @mklim @matthew-carroll @gspencergoog

[matthew-carroll]

But this isn't gonna block PRs, and reviewers aren't going to expect this to necessarily pass, right?

[dnfield]

This will mark a PR as failed unless it explicitly has re-created the baseline.xml file.

As we fix things, we should rebaseline. If we introduce new errors, we should make sure we have good reason to and that they won't cause runtime crashes.

[dnfield]

In case it's not clear, this PR does not actually fix any of our existing lint issues - it just sets up a file to track what they are and hopefully avoid introducing more.

[matthew-carroll]

I'm not sure if I'm misunderstanding something. We discussed failing PRs earlier today and agreed that we would not block any PRs on this linter....I don't know what rebaseline means, but it sounds like you're now saying this will block PRs. Am I understanding that correctly?

[jonahwilliams]

My understanding is that baseline file contains all existing errors, and this only prevents us from adding more?

[dnfield]

If you want to introduce what would cause a new linting error, you'd have to run dart tools/anroid_lint/bin/main.dart --rebaseline. That would re-generate the baseline.xml file, which would account for any new errors. A reviewer would have to LGTM allowing the new lint violation.

If we determine lints that we want to ignore, we can add those seperately. Right now we want to be sure to avoid adding NewApi violations that cause runtime crashes.

[matthew-carroll]

If what @jonahwilliams describes is true, then we can give this a try. But if it starts creating a bottleneck for me in the refactor then I'm gonna ask that we turn it back off because that timeline is far more important than imposing these restrictions right now.

[dnfield]

Yes - and we should eventually get to a point where the "baseline" file isn't necessary anymore because we've either fixed the issues or added the rule to an ignored rule list. This is purely to avoid adding new issues while we fix the old ones - or at least only add new ones we're consciously accepting.

[gspencergoog]

I agree that the goal should be to get rid of the baseline entirely. We should always be taking the free advice that the linter can give us about our code quality. To that end, we should set a timeline and perhaps even an OKR to resolve all of the linter warnings, depending on the extent of the debt here. That way it can be prioritized and factored in with our other priorities and tasks (like the refactor, which takes priority right now).

[mklim]

LGTM

@jonahwilliams' description is correct, this will treat existing linter failures as known issues and fail presubmits only if they introduce new ones.

A lot of the errors this linter is checking for, especially the NewApi check, are actual crashes and not subjective style issues or suggested best practices. This would have caught flutter/flutter#28640 for example. I think we should definitely start preventing any further introduction of bugs like that ASAP and work on reducing our existing ones. If the linter ends up causing problems I'd rather we disable specific arguable rules rather than turn it off entirely.

[dnfield]

Cirrus has actually finished all the tasks for this, the yellow one is actually green. Landing.