mirror of
https://github.com/flutter/flutter.git
synced 2026-02-12 13:56:40 +08: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>
This directory contains tools and resources that the Flutter team uses during the development of the framework. The tools in this directory should not be necessary for developing Flutter applications, though of course, they may be interesting if you are curious.
The tests in this directory are run in the framework_tests_misc-*
shards.