All temporary directory start with `flutter_` and have their random component separated from the name by a period, as in `flutter_test_bundle.YFYQMY`.
I've tried to find some of the places where we didn't cleanly delete temporary directories, too. This greatly reduces, though it does not entirely eliminate, the directories we leave behind when running tests, especially `flutter_tools` tests.
While I was at it I standardized on `tempDir` as the variable name for temporary directories, since it was the most common, removing occurrences of `temp` and `tmp`, among others.
Also I factored out some common code that used to catch exceptions that happen on Windows, and made more places use that pattern.
* Upgrade everything except matcher.
* Roll matcher (and test)
* Adjust tests that depend on flutter:test directly to depend on a shim
* Require use of package:test shim and remove other references to package:test
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)
Now that Dart 1 is turned off, reapplying my change to turn on the prefer_generic_function_type_aliases analysis option, and fix all the typedefs to Dart 2 preferred syntax.
Also eliminated the unused analysis_options_repo.yaml file and turned on public_member_api_docs in analysys_options.yaml.
No logic changes, just changing the typedef syntax for all typedefs, and updating analysis options.
AndroidSdk and AndroidStudio depends relatively heavily on filesystem
access to locate installed tools. Testing code that relies on either of
these classes benefits from a utility method to generate a
legitimate-looking Android SDK directory layout for testing.
Moves MockProcess, MockStdio and a few other useful mocks from
packages_test.dart to common/mocks.dart. These are useful for testing
code with interactive IO.
This adds a new constructor to MockProcess to provide additional flexibility.
This makes command validation happen as part of `verifyThenRunCommand()`,
using a newly introduced protected method (`validateCommand()`) rather than
a `commandValidator` property (that subclasses were responsible for manually
invoking).
This reverts commit b2909a245a.
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 972be9c8b4.
* Revert "Use Xcode instruments to list devices (#10801)"
This reverts commit 37bb5f1300.
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.
`adb` can sometimes hang, which will in turn hang the Dart isolate if
we're using `Process.runSync()`. This changes many of the `Device` methods
to return `Future<T>` in order to allow them to use the async process
methods. A future change will add timeouts to the associated calls so
that we can properly alert the user to the hung `adb` process.
This is work towards #7102, #9567
* [devFS] Use URI to represent paths on device
Previosuly, regular file paths in the format of the host platform were used to represent paths on device. That works when host and device share the same (POSIX) file path format. With a Windows host, this breaks. URIs are the solution as they are platform independent and the VM service on the device already interpreted the file paths as URIs anyways.
* review comments
* switch to file paths
* fix tests on Windows
* review comments
* Revert "Revert "Simplify path handling logic in dependency checker and devFS (#8414)" (#8467)"
This reverts commit 96ba7f76d2.
* Intentionally use a self-package URI in flutter_gallery
* tests to catch problems with self-package imports
Refactor DevFS so that it's easier to add new types of content such as kernel code
* add tests for DevFS package scanning
* add tests for DevFS over VMService protocol
* which covers _DevFSHttpWriter and ServiceProtocolDevFSOperations
* replace AssetBundleEntry and DevFSEntry with DevFSContent
* refactor to cleanup common code and replace some fields with locals
* rework .package file generation refactor away DevFSOperations.writeSource
* only update .package file if it has changed
* only write/delete/evict assets that have been changed/removed
* iOS tools cleanup
1) Fix `flutter install` on both device and simulator to refer to the actual
bundle and not just the .generated folder
2) Fix `flutter run` on device to actually run vs just installing
Still TODO:
1) Discovered that isAppInstalled on iOS simulator always reports true,
meaning it'll never actually try to install the app.
Fixes#3947Fixes#1823
Host tools can be found in the artifact cache directory for the host platform.
If a developer wants to use a local engine build instead, then provide an
--engine-build flag that selects the specific engine build variant.
flutter start's method of finding devices to run the app on is not suitable for flutter drive.
This commit also refactors several tool services to allow mocking in unit tests.
1) Moved basic utility code into base/ directory to make it clear which code
doesn't depend on Flutter-specific knowldge.
2) Move the CommandRunner subclasses into a runner/ directory because these
aren't commands themselves.
This patch makes `flutter start` work without a clone of the engine git
repository. Making this work pulled a relatively large refactor of how the
commands interact with application packages and devices. Now commands that want
to interact with application packages or devices inherit from a common base
class that holds stores of those objects as members.
In production, the commands download and connect to devices based on the build
configuration stored on the FlutterCommandRunner. In testing, these fields are
used to mock out the real application package and devices.
