Our current top crasher is an unclear error when ProcessManager fails to resolve an executable path. To fix this, we'd like to being adjusting the process resolution logic and adding more instrumentation to track failures. In order to begin the process, the ProcessManager has been folded back into the flutter tool
Overhaul of flutter drive in order to deliver a better experience, namely:
* flutter run and flutter drive now share more flags, so code paths that were previously only testable on run are now testable on drive.
* Removes web-initialize-platform as this is no longer used
* flutter drive correctly sets up a logger that shows native exceptions, by connecting to the vm service.
* VM service connection now provides access to memory info without launching devtools (only for debug/profile mode)
Web changes
* Passes on the one test in the repo, otherwise the webdriver code has been isolated as much as possible
Additional NNBD related bug fixes:
No longer passes --enable-experiment to the test script. (FYI @blasten ). earlier we might have assumed that the flutter gallery benchmarks would be migrated along side the app and flutter driver, but only the app under test needs to be migrated. The test scripts should never be run with the experiment.
Overhaul of flutter drive in order to deliver a better experience, namely:
flutter run and flutter drive now share more flags, so code paths that were previously only testable on run are now testable on drive.
Removes web-initialize-platform as this is no longer used
flutter drive correctly sets up a logger that shows native exceptions, by connecting to the vm service.
VM service connection now provides access to memory info without launching devtools (only for debug/profile mode)
Web changes
Passes on the one test in the repo, otherwise the webdriver code has been isolated as much as possible
Additional NNBD related bug fixes:
No longer passes --enable-experiment to the test script. (FYI @blasten ). earlier we might have assumed that the flutter gallery benchmarks would be migrated along side the app and flutter driver, but only the app under test needs to be migrated. The test scripts should never be run with the experiment.
Work towards #39925
Currently flutter run will uninstall and reinstall if the initial install fails and the APK was previously installed. Allow drive to share this same logic by moving it into installApp and out of startApp.
This should reduce the occurrence of the error in the devicelab.
Cleans up some undocumented classes and re-organizes the AndroidDevices class to avoid the need for the static testing only member. Adds a script for tracking globals.
Refactors the desktop devices and workflow to remove unnecessary usage of global variables. This should make it easier to test and continue enhancing the desktop functionality of the tooling
#47161
* Reland "Re-enable the Dart Development Service (DDS) (#64671)"
This reverts commit 2ae25cc2d725ff9875cfcfdc8ca3996eb39db13a.
* Fix MDNS building Observatory URI with port 0 instead of forwarding the device port
* Added MDNS test
This change re-enables DDS and outputs the DDS URI in place of the VM
service URI on the console. If --disable-dds is not provided,
--host-vmservice-port will be used to determine the port for DDS rather
than the host port for the VM service, which will instead be randomly
chosen.
Avoid creating AndroidDevice discovery if the SDK cannot be located. Previously the tool would use which/where adb, however this required us to handle the AndroidSdk class being potentially null - which required an additional layer of indirection around all access. Sometimes these were forgotten leading to NPEs.
In general, not much can be done with an Android Device if the actual SDK is not installed.
Reland with fixed code + tests for null SDK + adb in AndroidDeviceDiscovery
Avoid creating AndroidDevice discovery if the SDK cannot be located. Previously the tool would use which/where adb, however this required us to handle the AndroidSdk class being potentially null - which required an additional layer of indirection around all access. Sometimes these were forgotten leading to NPEs.
In general, not much can be done with an Android Device if the actual SDK is not installed.
instead of restricting profile/release mode based on whether the tool thinks the device is an emulator, restrict based on the device target architecture and the requested build mode. Notably, this enables release mode on x86_64 Android emulators, but not x86 emulators since we do not support that as an AOT target.
This does not add release mode support for simulators, since this requires us to build and upload artifacts for simulator/x86_64
The resident runner does not check if the ApplicationPackage is null when trying to stop the app. Update AndroidDevice.stopApp to handle this case by returning false.
The package will be null when flutter attach is used.
