The main purpose of this PR is to make it so that when you set the
initial route and it's a hierarchical route (e.g. `/a/b/c`), it
implies multiple pushes, one for each step of the route (so in that
case, `/`, `/a`, `/a/b`, and `/a/b/c`, in that order). If any of those
routes don't exist, it falls back to '/'.
As part of doing that, I:
* Changed the default for MaterialApp.initialRoute to honor the
actual initial route.
* Added a MaterialApp.onUnknownRoute for handling bad routes.
* Added a feature to flutter_driver that allows the host test script
and the device test app to communicate.
* Added a test to make sure `flutter drive --route` works.
(Hopefully that will also prove `flutter run --route` works, though
this isn't testing the `flutter` tool's side of that. My main
concern is over whether the engine side works.)
* Fixed `flutter drive` to output the right target file name.
* Changed how the stocks app represents its data, so that we can
show a page for a stock before we know if it exists.
* Made it possible to show a stock page that doesn't exist. It shows
a progress indicator if we're loading the data, or else shows a
message saying it doesn't exist.
* Changed the pathing structure of routes in stocks to work more
sanely.
* Made search in the stocks app actually work (before it only worked
if we happened to accidentally trigger a rebuild). Added a test.
* Replaced some custom code in the stocks app with a BackButton.
* Added a "color" feature to BackButton to support the stocks use case.
* Spaced out the ErrorWidget text a bit more.
* Added `RouteSettings.copyWith`, which I ended up not using.
* Improved the error messages around routing.
While I was in some files I made a few formatting fixes, fixed some
code health issues, and also removed `flaky: true` from some devicelab
tests that have been stable for a while. Also added some documentation
here and there.
This allows us to take advantage of improved command-line tooling (e.g.,
improvements in device listing in Instruments). Now that the engine is
built with Xcode 8 and the framework is tested against Xcode 8, this
reduces the set of configurations we need to support to allow us to
focus on the supported ones: Xcode 8 and Xcode 9.
Going forward, Android support libraries are published on maven (instead of bundling them with the SDK). Many plugins depend on these. To avoid requiring plugin users to add the maven repository to their app this change adds the repository to the template for `flutter create`.
This also bumps the support-annotations dependency to 25.4.0 (which also requires the new maven repository).
This reverts commit b2909a245a607995ce7ec286585cd1f643124f57.
This resubmits the following patches:
1. Use Xcode instruments to list devices (#10801)
Eliminates the dependency on idevice_id from libimobiledevice. Instead,
uses Xcode built-in functionality.
2. Make device discovery asynchronous (#10803)
Migrates DeviceDiscovery.devices and all device-specific lookup to be
asynchronous.
* Revert "Make device discovery asynchronous (#10803)"
This reverts commit 972be9c8b4048e18ecfb8ab582159c8d78abace8.
* Revert "Use Xcode instruments to list devices (#10801)"
This reverts commit 37bb5f1300e67fe590c44bb9ecda653b2967e347.
This is to resolve a failure that looks related to a bad install of Xcode 8.0
on our build bots and should be reinstated when the infra issue is diagnosed
and resolved.
Instruments worked well when this was originally landed, and on the
following commit, but started failing two commits after this originally
landed. Manual invocation of instruments on the build host currently
results in:
```
dyld: Library not loaded: @rpath/InstrumentsAnalysisCore.framework/Versions/A/InstrumentsAnalysisCore
Referenced from: /Applications/Xcode8.0.app/Contents/Developer/usr/bin/instruments
Reason: image not found
Abort trap: 6
```
It appears the /Applications/Xcode8.0.app/Contents/Applications
directory (which contains Instruments) is missing on the host.
Moves all remaining calls to tools that are part of the libimobiledevice
suite of tools to the IMobileDevice class. This allows for better
tracking of this dependency, and easier mocking in tests.
Use a top-level getter in mac.dart rather than a static instance getter
and a top-level getter in ios_workflow.dart. Makes this code consistent
with how we do context lookups elsewhere.
Extract out IMobileDevice class, move class to idevice_id, ideviceinfo
(and eventually other libimobiledevice tools such as iproxy) behind this
interface.
Add tests for the case where libimobiledevice is not installed, the case
where it returns no devices, and the case where it returns device IDs.
Eliminates the need for the device/daemon code to get at the iOS/Android
tooling indirectly via Doctor. In tests, we now inject the workflow
objects (or mocks) directly.
This code is unused in any test. In upcoming changes that migrate to
Xcode instruments based device listing, we'll mock out the instruments
output separately.
