This PR enables the `flutter screenshot` to work outside a Flutter project.
This works by enabling `ScreenshotCommand` to find target devices not supported by the project.
Before:
```bash
$ cd $HOME # not a Flutter directory
$ flutter screenshot
No devices found yet. Checking for wireless devices...
No supported devices connected.
The following devices were found, but are not supported by this project:
sdk gphone64 arm64 (mobile) ⢠emulator-5554 ⢠android-arm64 ⢠Android 13 (API 33) (emulator)
macOS (desktop) ⢠macos ⢠darwin-arm64 ⢠macOS 13.3.1 22E772610a darwin-arm64
Chrome (web) ⢠chrome ⢠web-javascript ⢠Google Chrome 119.0.6045.105
If you would like your app to run on android or macos or web, consider running `flutter create .` to generate projects for these platforms.
Must have a connected device for screenshot type device
```
After:
```bash
$ cd $HOME # not a Flutter directory
$ flutter_source screenshot
Screenshot written to flutter_01.png (313kB).
```
Fixes#115790
Part of tracker issue:
- https://github.com/flutter/flutter/issues/128251
This migrates the event being sent when the "--analyze-size" is used in a flutter invocation
The only file that had this event being sent from is `packages/flutter_tools/lib/src/base/analyze_size.dart`
ð«¡
This was terribly outdated and has long been superseded by `package:flutter_lints`. Also, as of c033718da0 support for this was removed from the analyzer and this file is now even more useless, if that's even possible.
Fixes https://github.com/flutter/flutter/issues/82948.
Related to tracker issue:
- https://github.com/flutter/flutter/issues/128251
This event was only called from one file (`flutter_command.dart`). With the previous implementation, we actually sent 2 events, one for the result of the `commandPath` and another containing the `maxRss` value from `ProcessInfo`.
I have consolidated this down to just one event and used a function to safely get the `maxRss` value, or return null when if there was an error getting that integer value
Fixes issues:
- https://github.com/flutter/flutter/issues/138035
Similar to GA3, we will now record the host running the flutter tool, such as VSCode, stored in the `FLUTTER_HOST` env variable
Fixes#135402
Add fallback logic for a different format of java version output and handle no patch versions.
Add tests for new logic output to prevent regressions.
Part of https://github.com/flutter/flutter/issues/130277
Without this, if a user runs an app that has plugins that call method channels with the `preview` device, the app will build successfully, however, they will get a runtime error when their dart code tries to call the method channel that does not exist in the native build (which was pre-built and thus does not include the plugin code).
This change adds a validation when injecting plugins that will tool exit if the device-id is `preview` and their project contains plugins with method channels.
Pin the dependencies from dart-lang/native to a specific version during testing (rather than having them auto-upgrade during pub resolution). This will prevent tests using the template to start failing if a bad version is published to pub.
Closes: https://github.com/flutter/flutter/issues/137418
Also bumps dep in flutter_tools.
Reverts flutter/flutter#137191
Initiated by: camsim99
This change reverts the following previous change:
Original Description:
Adds support for Android 34 in the following ways:
- Bumps integration tests compile SDK versions 33 --> 34
- Bumps template compile SDK version 33 --> 34
- Also changes deprecated `compileSdkVersion` to `compileSdk`
Part of https://github.com/flutter/flutter/issues/134220
Adds support for Android 34 in the following ways:
- Bumps integration tests compile SDK versions 33 --> 34
- Bumps template compile SDK version 33 --> 34
- Also changes deprecated `compileSdkVersion` to `compileSdk`
Part of https://github.com/flutter/flutter/issues/134220
Fixes https://github.com/flutter/flutter/issues/130808. Short context is that the migration guide doesn't help when a user has a newer java version than 17, and this tells them how to fix the error in that situation.
This is an alternative to https://github.com/flutter/flutter/pull/131354, because I think it is a bad idea to introduce branching in how we handle this error with some specialized regexp.
Relands #136851, which was rolled back in #137121
package:coverage has been rolled, so the breakages should be fixed.
Also, in this reland I've changed the `coverableLineCache` parameter to
be optional, which is safer.
Fixes https://github.com/flutter/flutter/issues/136698.
Alters how `throwToolExit` creates its matcher. This results is an improved description of the matcher.
The mismatch description isn't improved by this, but I writing an entirely custom matcher to fix this isn't ideal either. We can instead mitigate the issue by augmenting the `toString` implementation of `ToolExit` to include the exit code, if it is non-null.
With these changes, the first few lines of output from a test would look like this:
```
Expected: throws <Instance of 'ToolExit'> with `exitCode`: <42> and `message`: contains 'message'
Actual: <Closure: () => Never>
Which: threw ToolExit:<Exit code: 41232. Error: message>
```
Related to tracking issue:
- https://github.com/flutter/flutter/issues/128251
This PR sends analytic events for each of the doctor validators.
This PR below will need to land first in `dart-lang/tools` before this merges.
Reverts flutter/flutter#136851
Initiated by: CaseyHillers
This change reverts the following previous change:
Original Description:
One of the reasons gathering coverage information is expensive is that we have to force compile every function in the libraries we're interested in. Without this, functions that haven't been invoked (so haven't been compiled) won't have any line number information, so the coverage tool doesn't know which lines to add to the list of misses. In flutter's case, the test infra spawns many VMs, and each of these needs to recompile all those libraries.
To fix this, we need a way of skipping force compilation for libraries we've already seen in previous tests, without losing the information about which lines in each library are coverable. So I [added](https://github.com/dart-lang/coverage/pull/466) the `coverableLineCache` to `coverage.collect` in package:coverage v1.7.0. This cache starts out empty, but fills up with lists of all the lines that are coverable for every library as coverage is gathered. package:coverage can then tell the VM not to force compile any libraries in this cache (using `getSourceReport`'s `librariesAlreadyCompiled` param). So the first test suite will still have to compile everything, but subsequent test suites will be much faster.
This speeds up coverage collection significantly, for large test suites:
| Running flutter/packages/flutter tests... | Time | Overhead |
| --- | --- | --- |
| without coverage | 8:53 | - |
| with coverage | 20:25 | 130% |
| with `coverableLineCache` | 12:21 | 40% |
Bug: https://github.com/flutter/flutter/issues/100751
One of the reasons gathering coverage information is expensive is that we have to force compile every function in the libraries we're interested in. Without this, functions that haven't been invoked (so haven't been compiled) won't have any line number information, so the coverage tool doesn't know which lines to add to the list of misses. In flutter's case, the test infra spawns many VMs, and each of these needs to recompile all those libraries.
To fix this, we need a way of skipping force compilation for libraries we've already seen in previous tests, without losing the information about which lines in each library are coverable. So I [added](https://github.com/dart-lang/coverage/pull/466) the `coverableLineCache` to `coverage.collect` in package:coverage v1.7.0. This cache starts out empty, but fills up with lists of all the lines that are coverable for every library as coverage is gathered. package:coverage can then tell the VM not to force compile any libraries in this cache (using `getSourceReport`'s `librariesAlreadyCompiled` param). So the first test suite will still have to compile everything, but subsequent test suites will be much faster.
This speeds up coverage collection significantly, for large test suites:
| Running flutter/packages/flutter tests... | Time | Overhead |
| --- | --- | --- |
| without coverage | 8:53 | - |
| with coverage | 20:25 | 130% |
| with `coverableLineCache` | 12:21 | 40% |
Bug: https://github.com/flutter/flutter/issues/100751
