patrol test feature parity

[bartekpacia]

This issue tracks feature parity of the new patrol test command, compared to patrol drive.

Features

• patrol test: Uninstalling the app after the test was run #816
• host features (doing things on the computer to which the device is connected). This includes access to the host's shell and taking screenshots with flutter screenshot. See this issue for a list of use-cases that will become invalidated.
• no Flutter-side logs (workaround: use flutter logs)

Bugs

• Android tests are flaky on GitHub Actions #765
• Example app's iOS tests always stall after opening the app #786
• Patrol is built into a release app, even when it is a dev_dependency #681

Inconveniences

• Setting up the native automation feature got harder. Hot take @mateuszwojtczak: maybe we should let our users use flutter run for test development (convenient_test does that, it also enables hot reload), and require the more complex native Android/iOS setup only if running on devicelab platforms is needed? The obvious problem is how are we going to build and install the second .apk/.app containing the native tests. After giving it some thought, it seems to be a no-go, unfortunately.

[mateuszwojtczak]

This should be covered in the migration guide

[bartekpacia]

See also #1341

[jBorkowska]

I think it's out-of-date, closing

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar problem, please file a new issue. Make sure to follow the template and provide all the information necessary to reproduce the issue.