## Description
Print actionable warnings if `flutter drive` (where most of our performance benchmarks come from) is run in debug mode and it tries to gather benchmarks using `traceAction`.
## Related Issues
https://github.com/flutter/flutter/issues/30625
## Tests
I added the following tests:
* drive_perf_debug_warning devicelab test
This reverts commit adc8e159a548121a45ff7a45b4e556aff998d4bd.
This should be safe to land once https://github.com/flutter/flutter/pull/28530 gets merged
Merge on yellow doc test because the doc test is actually green.
This reverts commit a44f174efc218ac1b4b94b9d77dafdb5dfea1432.
Reason: start_up tests become flaky.
See https://github.com/flutter/flutter/issues/28374
TBR: xster
Merge on red to fix the tree
This patch adds a default shader warm up process which moves shader compilation from the animation time to the startup time. This also provides an extension for `runApp` so developers can customize the warm up process.
This should reduce our worst_frame_rasterizer_time_millis from ~100ms to ~20-30ms for both flutter_gallery and complex_layout benchmarks. Besides, this should also have a significant improvement on 90th and 99th percentile time (50%-100% speedup in some cases, but I haven't tested them thoroughly; I'll let our device lab collect the data afterwards).
The tradeoff the is the startup time (time to first frame). Our `flutter run --profile --trace-startup` seems to be a little noisy and I see about 100ms-200ms increase in that measurement for complex_layout and flutter_gallery. Note that this only happens on the first run after install or data wipe. Later the Skia persistent cache will remove the overhead.
This also adds a cubic_bezier benchmark to test the custom shader warm up process.
This should fix https://github.com/flutter/flutter/issues/813 (either by `defaultShaderWarmUp`, or a `customShaderWarmUp`).
* Revert "Revert "make LocalHistoryRoute a proper super-mixin (#23382)" (#23430)"
This reverts commit 3bbb3082b89ada4b0c44396148f3c2de731d1c6d.
This relands the LocalHistoryRoute change. The analyzer bug has been fixed.
* mark dartdocs as flaky
This reverts commit 93573de2165c750fdeefcd2d620e2b8bd494fed6.
Fails in the devicelab:
```
run:stderr: A problem occurred evaluating project ':app'.
run:stderr: > Could not resolve all files for configuration 'classpath'.2018-10-23T10:46:46.335864:
run:stderr: > Could not find aapt2-proto.jar (com.android.tools.build:aapt2-proto:0.3.1).2018-10-23T10:46:46.335960:
run:stderr: Searched in the following locations:2018-10-23T10:46:46.336048:
```
Adds an integration devicelab test that runs an Android app with two
custom named isolates. Tests that the isolate names are present and that
it's possible to attach to just one of the isolates.
Fixesflutter/flutter#22009
We decided that redefining the default for templates was premature. We're going to go back to having "module" in experimental land again, and we'll try again when we have the feature set fully baked.
This keeps the writing of the .metadata files, and writing the template type to them, because that was a good improvement, and there are still a bunch of added tests that improve our coverage.
* Prototype
* Fix paths to Flutter library resources
* Invoke pod install as necessary for materialized modules
* Add devicelab test for module use on iOS
* Remove debug output
* Rebase, reame materialize editable
* Add devicelab test editable iOS host app
* Removed add2app test section
This removes the final traces of Travis and Appveyor from the Flutter tree.
I've updated the documentation and fixed a couple of places where scripts look for Travis, and eliminated the dart tools runningOnTravis function (which was unused anyhow).
There are places in the flutter script that used to look for the environment variable TRAVIS. We actually do want to continue to detect that we're running on Travis there, since in the plugins repo we still use Travis (for the moment). In any case, it's OK, because the CI environment variable is set on all of the CI bots (Cirrus, Travis, and Appveyor).
FastLane doesn't have a setup_cirrus equivalent to setup_travis, but it actually doesn't matter there either, since it doesn't do Travis-specific things, and it also looks for the CI environment variable.
