This was added because the dispose method doesn't seem to be called - something must still have a reference to the application after shutdown.
Solution for https://github.com/flutter/flutter/issues/136582
Support for FFI calls with `@Native external` functions through Native assets on Windows. This enables bundling native code without any build-system boilerplate code.
For more info see:
* https://github.com/flutter/flutter/issues/129757
### Implementation details for Windows.
Mainly follows the design of https://github.com/flutter/flutter/pull/134031.
Specifically for Windows in this PR is the logic for finding the compiler `cl.exe` and environment variables that contain the paths to the Windows headers `vcvars.bat` based on `vswhere.exe`.
Reland of #134031. (Reverted in #135069.) Contains the fix for b/301051367 together with cl/567233346.
Support for FFI calls with `@Native external` functions through Native assets on Linux. This enables bundling native code without any build-system boilerplate code.
For more info see:
* https://github.com/flutter/flutter/issues/129757
### Implementation details for Linux.
Mainly follows the design of https://github.com/flutter/flutter/pull/130494.
Some differences are:
* Linux does not support cross compiling or compiling for multiple architectures, so this has not been implemented.
* Linux has no add2app.
The assets copying is done in the install-phase of the CMake build of a flutter app.
CMake requires the native assets folder to exist, so we create it also when the feature is disabled or there are no assets.
### Tests
This PR adds new tests to cover the various use cases.
* packages/flutter_tools/test/general.shard/linux/native_assets_test.dart
* Unit tests the Linux-specific part of building native assets.
It also extends various existing tests:
* packages/flutter_tools/test/integration.shard/native_assets_test.dart
* Runs (incl hot reload/hot restart), builds, builds frameworks for Linux and flutter-tester.
Reverts flutter/flutter#134031
context: b/301051367
Looked at the error message from the broken TAP target, but seems like the failure might be non trivial to resolve. Would it be okay if we revert this for now while it is being triaged?
Support for FFI calls with `@Native external` functions through Native assets on Linux. This enables bundling native code without any build-system boilerplate code.
For more info see:
* https://github.com/flutter/flutter/issues/129757
### Implementation details for Linux.
Mainly follows the design of https://github.com/flutter/flutter/pull/130494.
Some differences are:
* Linux does not support cross compiling or compiling for multiple architectures, so this has not been implemented.
* Linux has no add2app.
The assets copying is done in the install-phase of the CMake build of a flutter app.
CMake requires the native assets folder to exist, so we create it also when the feature is disabled or there are no assets.
### Tests
This PR adds new tests to cover the various use cases.
* packages/flutter_tools/test/general.shard/linux/native_assets_test.dart
* Unit tests the Linux-specific part of building native assets.
It also extends various existing tests:
* packages/flutter_tools/test/integration.shard/native_assets_test.dart
* Runs (incl hot reload/hot restart), builds, builds frameworks for Linux and flutter-tester.
The `.packages` file was deprecated in Dart 2.8 and slowly discontinued until support being fully removed in Dart 2.19. The file will no longer be created, so it can be safely dropped from the generated `.gitignore` files.
## Background
The Windows runner has a race at startup:
1. **Platform thread**: creates a hidden window
2. **Platform thread**: launches the Flutter engine
3. **UI/Raster threads**: renders the first frame
4. **Platform thread**: Registers a callback to show the window once the next frame has been rendered.
Steps 3 and 4 happen in parallel and it is possible for step 3 to complete before step 4 starts. In this scenario, the next frame callback is never called and the window is never shown.
As a result the `windows_startup_test`'s test, which [verifies that the "show window" callback is called](1f09a8662d/dev/integration_tests/windows_startup_test/windows/runner/flutter_window.cpp (L60-L64)), can flake if the first frame is rendered before the show window callback has been registered.
## Solution
This change makes the runner schedule a frame after it registers the next frame callback. If step 3 hasn't completed yet, this no-ops as a frame is already scheduled. If step 3 has already completed, a new frame will be rendered, which will call the next frame callback and show the window.
Part of https://github.com/flutter/flutter/issues/119415
See this thread for alternatives that were considered: https://github.com/flutter/engine/pull/42061#issuecomment-1550080722
This PR removed the non-necessary required Koltin dependency. This is because the Kotlin Gradle adds the dependency on the standard library automatically.
Fixes#98212
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy]. *
1. Add iOS and macOS migration to mark "last upgraded" Xcode version to 14.3 to prevent `Update to recommended settings` warning.
2. Update iOS and macOS templates to same.
3. Update iOS template to set `BuildIndependentTargetsInParallel` to YES as suggested. I didn't add a migration for this since it seems like a minor optimization and I don't think it's worth a potentially botched/corrupted migration.
4. Run all example/integration test project to see migrator work.
5. Add some missing test projects to the build shard since I noticed they were missing and I had to build those manually outside `SHARD=build_tests`.
Fixes https://github.com/flutter/flutter/issues/125817
See https://github.com/flutter/flutter/pull/90304 for Xcode 13 example.
* Add Linux unit tests to plugin template
Adds an example native unit test to the plugin template for Linux,
matching the structure we use for our 1P plugin unit tests. Once these
have been added for all platforms+languages, they will be documented on
a new plugin development page to explain their use.
While ideally we would adjust the engine APIs first to allow for testing
the method call handler directly, it's unclear when we will have time
for that work, and for a complex plugin most of the testing wouldn't be
at that layer anyway, so having the structure in place with the
limitations documented is still a significant improvement over having
nothing in the template.
Part of https://github.com/flutter/flutter/issues/82458
* Add creation test
* Add integration tests
* Missing newlines
* test owner
* Typo
* Add Windows unit tests to plugin template
Adds an example native unit test to the plugin template for Windows,
matching the format we use for our 1P plugin example app unit tests.
Once these have been added for all platforms+languages, they will be
documented on a new plugin development page to explain their use.
Since we don't appear to be running our current plugin e2e tests for
Windows, this adds a new configuration to run them. I haven't
`led`-tested this, so it may not work, but this will give a starting
point for getting them running.
Part of https://github.com/flutter/flutter/issues/82458
* Minor fix
* Add test owner
* Fix typo
* Fix test feature flag
* Add Info.plist from build directory as input path to Thin Binary build phase
* fix directive ordering
* migrate benchmark, integration, and example tests
Increases the minimum macOS deployment target from macOS 10.13 (High Sierra) to 10.14 (Mojave) in the macOS app templates.
Includes:
* Update migration for macOS 10.11 apps to upgrade to 10.14
* Adds migration for macOS 10.13 apps to upgrade to 10.14
* Apply migration to all examples, and integration tests
This does not increase version in the plugin templates since those will need to wait until the 10.14 framework rolls to stable channel, so new plugins can build with apps created with `flutter create` on stable channel.
Issue: https://github.com/flutter/flutter/issues/114445
See RFC: http://flutter.dev/go/flutter-drop-macOS-10.13-2022-q4
See previous patch: https://github.com/flutter/flutter/pull/107689
Previously developers had to edit their `Runner.rc` file to update their executable's version information. Now, version information will automatically be set from `flutter build`'s arguments or the `pubspec.yaml` file for new projects.
Addresses https://github.com/flutter/flutter/issues/73652
