mirror of
https://github.com/flutter/flutter.git
synced 2025-06-03 00:51:18 +00:00
85564cbba9
<!-- start_original_pr_link --> Reverts: flutter/flutter#169276 <!-- end_original_pr_link --> <!-- start_initiating_author --> Initiated by: vashworth <!-- end_initiating_author --> <!-- start_revert_reason --> Reason for reverting: Causing google testing failures <!-- end_revert_reason --> <!-- start_original_pr_author --> Original PR Author: gaaclarke <!-- end_original_pr_author --> <!-- start_reviewers --> Reviewed By: {vashworth} <!-- end_reviewers --> <!-- start_revert_body --> This change reverts the following previous change: ## **BREAKING CHANGE** Adopting Apple's UISceneDelegate protocol shifts the initialization order of apps. For the common cases we've made sure they will work without change. The one case that will require a change is any app that in `-[UIApplicateDelegate didFinishLaunchingWithOptions:]` assumes that `UIApplicationDelegate.window.rootViewController` is a `FlutterViewController` instance. This is sometimes done to register platform channels directly on the `FlutterViewController`. Instead users should use the `FlutterPluginRegistry` API's to create platform channels in `-[UIApplicateDelegate didFinishLaunchingWithOptions:]`, like `FlutterPlugin`s do. An example can be seen here: https://github.com/flutter/flutter/pull/168914/files#diff-9f59c5248b58124beca7e290a57646023cda3ca024607092c6c6932606ce16ee In extreme cases, like bespoke test harnesses, the startup logic can be moved to `-[FlutterViewController awakeFromNib]` in a FlutterViewController subclass. An example can be seen here: https://github.com/flutter/flutter/pull/169276/files#diff-dbe39c23a0a380447b90b7559a878dae8564616e0875c4ef0d9e99e02b91adac ## Changes since revert I changed the init in `//dev/integration_tests/external_textures` from the UIApplicationDelegate to the FlutterViewController's awakeFromNib. This is a more appropriate place for initialization post-UISceneDelegate since it avoids the launch engine altogether. I tried avoiding to make the big change to prove we could do a small change to migrate that project. I don't think this big refactor is indicative of what users will experience. There was a timing assumption in the integration test that required not using the launch engine at all. ## Description fixes: https://github.com/flutter/flutter/issues/167267 design doc: https://docs.google.com/document/d/1ZfcQOs-UKRa9jsFG84-MTFeibZTLKCvPQLxF2eskx44/edit?tab=t.0 relands https://github.com/flutter/flutter/pull/168396 relands https://github.com/flutter/flutter/pull/168914 ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [x] All existing and new tests are passing. <!-- end_revert_body --> Co-authored-by: auto-submit[bot] <flutter-engprod-team@google.com> |
||
|---|---|---|
| .. | ||
| android_engine_test | ||
| android_module_host_with_custom_build_v2_embedding/app/src/main/java/io/flutter/addtoapp | ||
| android_semantics_testing | ||
| android_views | ||
| channels | ||
| deferred_components_test | ||
| display_cutout_rotation | ||
| external_textures | ||
| flavors | ||
| flutter_gallery | ||
| hook_user_defines | ||
| ios_add2app_life_cycle | ||
| ios_app_with_extensions | ||
| ios_host_app | ||
| ios_host_app_swift | ||
| ios_platform_view_tests | ||
| keyboard_hot_restart | ||
| link_hook | ||
| module_host_with_custom_build/.gradle | ||
| module_host_with_custom_build_v2_embedding | ||
| new_gallery | ||
| platform_interaction | ||
| pure_android_host_apps | ||
| release_smoke_test | ||
| spell_check | ||
| ui | ||
| web | ||
| web_compile_tests | ||
| web_e2e_tests | ||
| wide_gamut_test | ||
| windows_startup_test | ||
| README.md | ||
Automated Flutter integration test suites
Each suite consists of either a complete Flutter app and a flutter_driver
specification that drives tests from the UI, or a native app that is meant to
integrate with Flutter for testing.
Intended for use with devicelab tests.
If you want to run a driver test locally, to debug a problem with a test, you can use this command from the appropriate subdirectory:
flutter drive -t <test> --driver <driver>
For example:
flutter drive -t lib/keyboard_resize.dart --driver test_driver/keyboard_resize_test.dart
New tests require new CI runner
Adding code to this directory will not automatically cause it to be run by any already existing ci tooling. This directory is intentinally a "choose your own adventure" piece of tooling.