Since our existing `gradlew lint` check doesn't catch all warnings (notably, deprecation warnings, but also others like raw values), this:
- Configures our plugin example apps to enable `-Xlint:all -Werror` for the javac for the plugin project, so that we also get javac lint coverage in CI. This is done in the example app so that it won't affect plugin clients.
- Adds a check to `lint-android` that the example is configured this way, so that we don't forget to set it up when adding new plugins (or re-generating plugin examples from template).
Where it was trivial for me to just fix existing violations, I did so in this PR. For the rest that had violations, I commented out the enabling of the flags, with a TODO. Normally we would do this kind of thing with a `script/configs` file to opt packages out of a new check, but since this is part of an existing check rather than a whole new command, doing it that way would disable `gradlew lint` for those packages as well. Making a whole new command seemed more complex for the long term, so this seemed like the best short term option. We should try to remove as many of these opt-outs as possible ASAP.
Part of https://github.com/flutter/flutter/issues/91868
This allows building UWP plugin examples with `build-examples --winuwp`. As with previous pre-stable-template desktop support, this avoids the issue of unstable app templates by running `flutter create` on the fly before trying to build, so a template that will bitrot doesn't need to be checked in.
Also adds no-op "support" for `drive-examples --winuwp`, with warnings about it not doing anything. This is to handle the fact that the LUCI recipe is shared between Win32 and UWP, and didn't conditionalize `drive`. Rather than change that, then change it back later, this just adds the no-op support now (since changing the tooling is much easier than changing LUCI recipes currently).
This required some supporting tool changes:
- Adds the ability to check for the new platform variants in a pubspec
- Adds the ability to write test pubspecs that include variants, for testing
Part of https://github.com/flutter/flutter/issues/82817
The mock process runner used in most of the tests had poor handling of
stdout/stderr:
- By default it would return the `List<int>` output from the mock
process, which was never correct since the parent process runner
interface always sets encodings, thus the `dynamic` should always be
of type `String`
- The process for setting output on a `MockProcess` was awkward, since
it was based on a `Stream<Lint<int>>`, even though in every case what
we actually want to do is just set the full output to a string.
- A hack was at some point added (presumably due to the above issues)
to bypass that flow at the process runner level, and instead return a
`String` set there. That meant there were two ways of setting output
(one of which that only worked for one of the ways of running
processes)
- That hack wasn't updated when the ability to return multiple mock
processes instead of a single global mock process was added, so the
API was even more confusing, and there was no way to set different
output for different processes.
This changes the test APIs so that:
- `MockProcess` takes stdout and stderr as strings, and internally
manages converting them to a `Stream<List<int>>`.
- `RecordingProcessRunner` correctly decodes and returns the output
streams when constructing a process result.
It also removes the resultStdout and resultStderr hacks, as well as the
legacy `processToReturn` API, and converts all uses to the new
structure, which is both simpler to use, and clearly associates output
with specific processes.
Adds a new `lint-android` command to run `gradlew lint` on Android plugins.
Also standardizes the names of the Cirrus tasks that run all the build and platform-specific (i.e., not Dart unit test) tests for each platform, as they were getting unnecessarily long and complex in some cases.
Fixes https://github.com/flutter/flutter/issues/87071
