* Revert "Revert "make LocalHistoryRoute a proper super-mixin (#23382)" (#23430)"
This reverts commit 3bbb3082b8.
This relands the LocalHistoryRoute change. The analyzer bug has been fixed.
* mark dartdocs as flaky
This reverts commit 93573de216.
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.
fuchsia_tester.dart still assumes Dart 1. Previously, it ran tests directly
from source, flutter_platform.dart automatically runs a kernel compile when
operating in Dart 2 mode, but this assumes a functional Dart SDK is available
in the artifacts directly, and fuchsia_tester.dart mocks out the artifacts
directory with an empty temp dir.
Remaining work is:
1. Get the frontend server building as a dependency on Fuchsia.
2. Patch fuchsia_tester.dart to use a valid Dart SDK and frontend server.
This also reverts migration to Dart 2 typedef syntax.
This reverts commit 6c56bb2. (#18362)
This reverts commit 3daebd0. (#18316)
* It's time to #deleteDart1 (#18293)
Eliminates support for Dart 1 in flutter_tools, and drops our Dart 1
benchmarks. All commands now run in Dart 1 mode only.
Eliminates --preview-dart-2 / --no-preview-dart-2 support.
* Fix indentation, remove no longer necessary .toList()
* Only push udpated kernel if >0 invalidated srcs
Eliminates support for Dart 1 in flutter_tools, and drops our Dart 1
benchmarks. All commands now run in Dart 1 mode only.
Eliminates --preview-dart-2 / --no-preview-dart-2 support.
This test fails consistently on mac2 and mac3 with the attached Moto G4
devices but passes consistently on other machines.
Adding a delay of 1s right after driver.connect() in setUpAll() causes
it to pass on the machines in question, which suggests a race condition.
Specifically it looks like connect returns the moment Flutter Driver
identifies that the isolate is up and running, but empirically it looks
like we start running the first test before the UI is actually up. This
triggers a failure wherein we start looking for elements before they're
onstage.
Link to viewport.dart:213 at HEAD:
b2b4665926/packages/flutter/lib/src/widgets/viewport.dart (L213)
Stack trace:
FlutterDriver waitFor should find text "present"
```
DriverError: Error in Flutter application: Uncaught extension error while executing waitFor: NoSuchMethodError: The getter 'visible' was called on null.
Receiver: null
Tried calling: visible
#0 Object.noSuchMethod (dart:core/runtime/libobject_patch.dart:46:5)
#1 _ViewportElement.debugVisitOnstageChildren. (package:flutter/src/widgets/viewport.dart:213:36)
#2 WhereIterator.moveNext (dart:_internal/iterable.dart:439:11)
#3 Iterable.forEach (dart:core/iterable.dart)
#4 _ViewportElement.debugVisitOnstageChildren (package:flutter/src/widgets/viewport.dart:214:8)
#5 _DepthFirstChildIterator._reverseChildrenOf (package:flutter_test/src/all_elements.dart:54:15)
#6 _DepthFirstChildIterator.moveNext (package:flutter_test/src/all_elements.dart:45:19)
#7 CachingIterable._fillNext (package:flutter/src/foundation/basic_types.dart:252:27)
#8 _LazyListIterator.moveNext (package:flutter/src/foundation/basic_types.dart:279:21)
#9 WhereIterator.moveNext (dart:_internal/iterable.dart:438:22)
#10 CachingIterable._fillNext (package:flutter/src/foundation/basic_types.dart:252:27)
#11 _LazyListIterator.moveNext (package:flutter/src/foundation/basic_types.dart:279:21)
#12 Iterable.isEmpty (dart:core/iterable.dart:449:33)
#13 Iterable.isNotEmpty (dart:core/iterable.dart:456:27)
#14 FlutterDriverExtension._waitForElement. (package:flutter_driver/src/extension/extension.dart:215:51)
#15 FlutterDriverExtension._waitUntilFrame (package:flutter_driver/src/extension/extension.dart:197:19)
#16 FlutterDriverExtension._waitForElement (package:flutter_driver/src/extension/extension.dart:215:11)
#17 FlutterDriverExtension._waitFor (package:flutter_driver/src/extension/extension.dart:286:11)
#18 FlutterDriverExtension.call (package:flutter_driver/src/extension/extension.dart:168:51)
#19 BindingBase.registerServiceExtension. (package:flutter/src/foundation/binding.dart:370:32)
```
Removes a previous hack that no longer appears to help (adding a 1
second delay in setUpAll() does seem to work around this issue though).
