flutter_tools: correct iOS signing log for manual code signing (CODE_SIGN_STYLE=Manual)#177851
flutter_tools: correct iOS signing log for manual code signing (CODE_SIGN_STYLE=Manual)#177851MohammedTarigg wants to merge 67 commits into
Conversation
…r#172237) Cherrypick's flutter#172236 into the 3.35 release branch _and_ tests it live by setting `engine.version` in this PR.
… for some silly reason (flutter#172263) This pull request is created by [automatic cherry pick workflow](https://github.com/flutter/flutter/blob/main/docs/releases/Flutter-Cherrypick-Process.md#automatically-creates-a-cherry-pick-request) Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request. ### Issue Link: What is the link to the issue this cherry-pick is addressing? flutter#172257 ### Changelog Description: Explain this cherry pick in one line that is accessible to most Flutter developers. See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples N/A ### Impact Description: What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)? Does it impact development (ex. flutter doctor crashes when Android Studio is installed), or the shipping production app (the app crashes on launch) Cannot release (Windows builder fails) ### Workaround: Is there a workaround for this issue? No ### Risk: What is the risk level of this cherry-pick? ### Test Coverage: Are you confident that your fix is well-tested by automated tests? ### Validation Steps: What are the steps to validate that this fix works? Try publishing another release
to use, correctly, flutter@1c9c20e.
…er#172498) This pull request is created by [automatic cherry pick workflow](https://github.com/flutter/flutter/blob/main/docs/releases/Flutter-Cherrypick-Process.md#automatically-creates-a-cherry-pick-request) Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request. ### Issue Link: What is the link to the issue this cherry-pick is addressing? flutter#57497 ### Changelog Description: Explain this cherry pick in one line that is accessible to most Flutter developers. See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples N/A (Beta) ### Impact Description: What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)? Does it impact development (ex. flutter doctor crashes when Android Studio is installed), or the shipping production app (the app crashes on launch) Provides a CLI-issued warning to plugins using a workaround we wanted to remove in 2020. Once this is CP'd in 3.35, the `master` branch (post-3.35) can remove the workaround/tech debt. ### Workaround: Is there a workaround for this issue? N/A ### Risk: What is the risk level of this cherry-pick? ### Test Coverage: Are you confident that your fix is well-tested by automated tests? ### Validation Steps: What are the steps to validate that this fix works? N/A
…ontextAction.cancel (flutter#172675) This pull request is created by [automatic cherry pick workflow](https://github.com/flutter/flutter/blob/main/docs/releases/Flutter-Cherrypick-Process.md#automatically-creates-a-cherry-pick-request) Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request. ### Issue Link: What is the link to the issue this cherry-pick is addressing? flutter#172250 ### Changelog Description: Explain this cherry pick in one line that is accessible to most Flutter developers. See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples Fixes a bug where `TextInput.hide` call incorrect clears the text in the active text field. ### Impact Description: What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)? Does it impact development (ex. flutter doctor crashes when Android Studio is installed), or the shipping production app (the app crashes on launch) If an app calls `TextInput.hide` to hide the software keyboard, the user input in the current active text field will also be erased. It impacts the production app. The framework itself doesn't seem to call `TextInput.hide` in a way that would affect the user. ### Workaround: Is there a workaround for this issue? Yes, in theory, developers can store and restore the `TextEditingValue`, when they need to call `TextInput.hide`, to undo the clear. However I suspect the reverted PR may also [break voiceover](flutter#145681 (comment)). ### Risk: What is the risk level of this cherry-pick? This is a revert of flutter#160653. The reverted PR was merged in February, and the previous implementation was [introduced in 2021](flutter-team-archive/engine#23776). ### Test Coverage: Are you confident that your fix is well-tested by automated tests? - [] No This change is a revert so the added test will also get reverted. ### Validation Steps: What are the steps to validate that this fix works? To verify the fix on master (it has already landed on master), run this app: ```dart import 'package:flutter/material.dart'; import 'package:flutter/services.dart'; void main() { runApp(const MyApp()); } class MyApp extends StatelessWidget { const MyApp({super.key}); @OverRide Widget build(BuildContext context) { return MaterialApp( title: 'Flutter Demo', debugShowCheckedModeBanner: false, theme: ThemeData( colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple), useMaterial3: true, ), home: const MyHomePage(), ); } } class MyHomePage extends StatelessWidget { const MyHomePage({super.key}); @OverRide Widget build(BuildContext context) { return Scaffold( body: Center( child: SizedBox( child: ListView( children: [ TextButton( child: Text('hide keyboard'), onPressed: () => SystemChannels.textInput.invokeListMethod("TextInput.hide"), ), TextField( controller: TextEditingController(text: '️a' * 20), maxLines: 1, ), ], ), ), ), ); } } ``` focus the text field and then click the hide keyboard button. The text "aaaaaa..." should remain after the button is clicked.
…uage tag (flutter#172711) This pull request is created by [automatic cherry pick workflow](https://github.com/flutter/flutter/blob/main/docs/releases/Flutter-Cherrypick-Process.md#automatically-creates-a-cherry-pick-request) Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request. ### Issue Link: What is the link to the issue this cherry-pick is addressing? flutter#162324 ### Changelog Description: Explain this cherry pick in one line that is accessible to most Flutter developers. See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples This PR fixes a bug where the locale property of a Text widget was not being correctly passed to the accessibility layer, resulting in screen readers not knowing the language of the text. ### Impact Description: What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)? Does it impact development (ex. flutter doctor crashes when Android Studio is installed), or the shipping production app (the app crashes on launch) This bug critically impacted accessibility, causing screen readers to mispronounce text in foreign languages and creating a confusing, inaccessible experience for users with visual impairments. The fix ensures the locale property on the Text widget is no longer ignored, correctly passing the language information to the underlying accessibility services so the text is read intelligibly. ### Workaround: Is there a workaround for this issue? No. ### Risk: What is the risk level of this cherry-pick? ### Test Coverage: Are you confident that your fix is well-tested by automated tests? ### Validation Steps: What are the steps to validate that this fix works? Unit tests verify this change works as expected.
This pull request is created by [automatic cherry pick workflow](https://github.com/flutter/flutter/blob/main/docs/releases/Flutter-Cherrypick-Process.md#automatically-creates-a-cherry-pick-request) Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request. ### Issue Link: What is the link to the issue this cherry-pick is addressing? flutter#172789 ### Changelog Description: Explain this cherry pick in one line that is accessible to most Flutter developers. See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples flutter#172789 flutter#172789 Using a lower version of Gradle results in a warning message to bump to a minimum of version `8.7.2`, but the warning should bump to a minimum of version `8.7.0` Reids edit: [flutter/172789](flutter#172789) When building for Android, Change warning for minimum gradle version from 8.7.2 to 8.7.0. ### Impact Description: What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)? Does it impact development (ex. flutter doctor crashes when Android Studio is installed), or the shipping production app (the app crashes on launch) When on a lower version of Gradle, Flutter tooling would log a suggestion to bump to a minimum of `8.7.0` instead of `8.7.2` ### Workaround: Is there a workaround for this issue? Yes, the user would bump to a higher valid version of Gradle. ### Risk: What is the risk level of this cherry-pick? ### Test Coverage: Are you confident that your fix is well-tested by automated tests? ### Validation Steps: What are the steps to validate that this fix works? Use a low version of gradle and see that the Flutter tool recommends using gradle `8.7.0`
…s` (flutter#172790) This pull request is created by [automatic cherry pick workflow](https://github.com/flutter/flutter/blob/main/docs/releases/Flutter-Cherrypick-Process.md#automatically-creates-a-cherry-pick-request) Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request. ### Issue Link: What is the link to the issue this cherry-pick is addressing? flutter#150279 ### Changelog Description: Explain this cherry pick in one line that is accessible to most Flutter developers. See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples Emits a warning if `--[no-]disable-dds` is used, users should prefer `--[no-]dds`. ### Impact Description: What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)? Does it impact development (ex. flutter doctor crashes when Android Studio is installed), or the shipping production app (the app crashes on launch) Gives a full stable release of warnings before removing a deprecated feature. ### Workaround: Is there a workaround for this issue? N/A ### Risk: What is the risk level of this cherry-pick? ### Test Coverage: Are you confident that your fix is well-tested by automated tests? ### Validation Steps: What are the steps to validate that this fix works? N/A
…mium bots (flutter#172972) This pull request is created by [automatic cherry pick workflow](https://github.com/flutter/flutter/blob/main/docs/releases/Flutter-Cherrypick-Process.md#automatically-creates-a-cherry-pick-request) Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request. ### Issue Link: What is the link to the issue this cherry-pick is addressing? flutter#168427 ### Changelog Description: Explain this cherry pick in one line that is accessible to most Flutter developers. See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples Updates the provisioning profile that Flutter's CI uses. ### Impact Description: What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)? Does it impact development (ex. flutter doctor crashes when Android Studio is installed), or the shipping production app (the app crashes on launch) This only impacts the release team. Without this patch, codesigning on try and prod chromium bots will fail. ### Workaround: Is there a workaround for this issue? No ### Risk: What is the risk level of this cherry-pick? ### Test Coverage: Are you confident that your fix is well-tested by automated tests? ### Validation Steps: What are the steps to validate that this fix works? Run a test that requires codesigning, such as "Mac_x64 tool_host_cross_arch_tests"
…lutter#173053) This pull request is created by [automatic cherry pick workflow](https://github.com/flutter/flutter/blob/main/docs/releases/Flutter-Cherrypick-Process.md#automatically-creates-a-cherry-pick-request) ### Issue Link: flutter#172713 ### Changelog Description: Fix web engine unit tests to work on multiple versions of Firefox. ### Impact Description: Without this fix, some unit tests fail fairly regularly on Firefox. ### Workaround: This does not affect end-users, so no workaround necessary. ### Risk: Low ### Test Coverage: Are you confident that your fix is well-tested by automated tests? Yes ### Validation Steps: Run CI.
The most recent change to fix CI on the beta branch actually touches engine unit tests, so we need to bump the engine.version again.
flutter#173072) This pull request is created by [automatic cherry pick workflow](https://github.com/flutter/flutter/blob/main/docs/releases/Flutter-Cherrypick-Process.md#automatically-creates-a-cherry-pick-request) ### Issue Link: What is the link to the issue this cherry-pick is addressing? flutter#172180 ### Changelog Description: Fix a bug that causes the web engine to double report taps on dropdown menu items on iOS Safari. ### Impact Description: It breaks Flutter Web apps that use dropdown menus with semantics enabled on iOS Safari. ### Workaround: Is there a workaround for this issue? No. ### Risk: What is the risk level of this cherry-pick? ### Test Coverage: Are you confident that your fix is well-tested by automated tests? ### Validation Steps: What are the steps to validate that this fix works? Follow repro steps in flutter#172180
…tter#173304) This pull request is created by [automatic cherry pick workflow](https://github.com/flutter/flutter/blob/main/docs/releases/Flutter-Cherrypick-Process.md#automatically-creates-a-cherry-pick-request) Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request. ### Issue Link: What is the link to the issue this cherry-pick is addressing? flutter#154365 (comment) ### Changelog Description: Explain this cherry pick in one line that is accessible to most Flutter developers. See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples Suppress an iOS deprecation warning to unblock Xcode 26 testing in CI ### Impact Description: What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)? Does it impact development (ex. flutter doctor crashes when Android Studio is installed), or the shipping production app (the app crashes on launch) Blocks Xcode 26 from being tested for the pacakges repo in CI flutter#170437 ### Workaround: Is there a workaround for this issue? No. Packages runs the Xcode analyzer against the Flutter master and stable branches, so this deprecation suppression must go to stable ASAP. ### Risk: What is the risk level of this cherry-pick? ### Test Coverage: Are you confident that your fix is well-tested by automated tests? Tested here: https://github.com/flutter/flutter/blob/de33a3b2ab94844b091e35cae1d30b853369d308/packages/integration_test/example/integration_test/matches_golden_test.dart#L43-L45 ### Validation Steps: What are the steps to validate that this fix works? Current CI analysis will pass with or without this suppression. However, we will no longer see failures like this in packages while upgrading to Xcode 26, or increasing the minimum target version. ``` integration_test/Sources/integration_test/IntegrationTestPlugin.m:76:55: error: 'windows' is deprecated: first deprecated in iOS 15.0 - Use UIWindowScene.windows on a relevant window scene instead [-Werror,-Wdeprecated-declarations] UIWindow *window = [UIApplication.sharedApplication.windows ``` https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8738245141115055857/+/u/Run_package_tests/xcode_analyze_deprecation/stdout From flutter/packages#7542
…tter#173438) This pull request is created by [automatic cherry pick workflow](https://github.com/flutter/flutter/blob/main/docs/releases/Flutter-Cherrypick-Process.md#automatically-creates-a-cherry-pick-request) Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request. ### Issue Link: What is the link to the issue this cherry-pick is addressing? flutter#172627 ### Changelog Description: Explain this cherry pick in one line that is accessible to most Flutter developers. See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples Prevents a non-fatal error from causing Xcode compilation failures on macOS 26. ### Impact Description: What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)? Does it impact development (ex. flutter doctor crashes when Android Studio is installed), or the shipping production app (the app crashes on launch) Building iOS flutter apps may crash with Xcode 26. ### Workaround: Is there a workaround for this issue? Add NSBonjourServices and NSLocalNetworkUsageDescription settings to your iOS app's Info.plist. ### Risk: What is the risk level of this cherry-pick? ### Test Coverage: Are you confident that your fix is well-tested by automated tests? ### Validation Steps: What are the steps to validate that this fix works? 1. `flutter create` a new app on macOS 26 beta 2. Install Xcode 26 beta 5 3. `flutter run`
…73439) This pull request is created by [automatic cherry pick workflow](https://github.com/flutter/flutter/blob/main/docs/releases/Flutter-Cherrypick-Process.md#automatically-creates-a-cherry-pick-request) Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request. ### Issue Link: Part 1 of flutter#144218 ### Changelog Description: Explain this cherry pick in one line that is accessible to most Flutter developers. See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples Preliminary work for a future fix to allow Xcode 26 to `flutter run` twice in a row. ### Impact Description: What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)? Does it impact development (ex. flutter doctor crashes when Android Studio is installed), or the shipping production app (the app crashes on launch) Flutter developers running Xcode 26 can `flutter run` to a tethered iOS device once. However subsequent `flutter run` attempts are likely to fail. This is the first of several PRs to work around that issue. ### Workaround: Is there a workaround for this issue? Quitting and reopening Xcode. ### Risk: What is the risk level of this cherry-pick? ### Test Coverage: Are you confident that your fix is well-tested by automated tests? ### Validation Steps: What are the steps to validate that this fix works? N/A. This PR adds the classes and functions needed for a future commit, which will turn the new feature on.
…ode 26+ (flutter#173443) (flutter#173472) Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request. ### Issue Link: Part 2 of flutter#144218 ### Changelog Description: Explain this cherry pick in one line that is accessible to most Flutter developers. See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples Implementation of a future fix to allow Xcode 26 to `flutter run` twice in a row. ### Impact Description: What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)? Does it impact development (ex. flutter doctor crashes when Android Studio is installed), or the shipping production app (the app crashes on launch) Flutter developers running Xcode 26 can `flutter run` to a tethered iOS device once. However subsequent `flutter run` attempts are likely to fail. ### Workaround: Is there a workaround for this issue? Quitting and reopening Xcode. ### Risk: What is the risk level of this cherry-pick? ### Test Coverage: Are you confident that your fix is well-tested by automated tests? ### Validation Steps: What are the steps to validate that this fix works? Create a flutter project and run `flutter run` twice in a row with a physical iOS 17+ device and Xcode 26.
Updates Dart has for 3.35 stable release to Dart 3.9 hash -- https://dart.googlesource.com/sdk/+/54588cb8088890ea08fe1a31b95efe478a4609b5. Steps I took: 1. Updated hash to desired version. 2. Run `engine/src/tools/dart/create_updated_flutter_deps.py -f DEPS` to update any Dart dependencies if needed (none updated). 3. Updated `engine/src/flutter/ci/licenses_golden/licenses_dart` with diff produced in error from https://ci.chromium.org/ui/p/flutter/builders/try/Linux%20linux_license/36032/overview build failure. **Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.
…ad (flutter#173667) Cherry pick of flutter#173602 Impacted users: All Linux users of Flutter Impact Description: Due to calling gtk_window_redraw on a Flutter thread a lock up may occur. The Flutter app will then become unresponsive. Workaround: No workaround Risk: Low - fix is to run the GTK call on the GTK thread which is what the correct behaviour should be. Test coverage: Rendering covered by existing tests, use of thread not explicitly tested, but flutter#173660 opened to add this in future. Validation Steps: Run test program in flutter#173447 which generates many frames and maximizes the chance of a lock up.
…#173734) This pull request is created by [automatic cherry pick workflow](https://github.com/flutter/flutter/blob/main/docs/releases/Flutter-Cherrypick-Process.md#automatically-creates-a-cherry-pick-request) Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request. ### Issue Link: What is the link to the issue this cherry-pick is addressing? flutter#173728 ### Changelog Description: Explain this cherry pick in one line that is accessible to most Flutter developers. See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples N/A ### Impact Description: What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)? Does it impact development (ex. flutter doctor crashes when Android Studio is installed), or the shipping production app (the app crashes on launch) Skips building Android unit tests during the engine release builder ### Workaround: Is there a workaround for this issue? No ### Risk: What is the risk level of this cherry-pick? ### Test Coverage: Are you confident that your fix is well-tested by automated tests? ### Validation Steps: What are the steps to validate that this fix works? The release builder step works.
<!-- Thanks for filing a pull request! Reviewers are typically assigned within a week of filing a request. To learn more about code review, see our documentation on Tree Hygiene: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md --> add link to 3.35 blog post as proxy for 3.35 changelog - [ x] I signed the [CLA].
… to invalid nodes (flutter#173979) Fixes flutter#173959 This is a top-10 crasher on `3.35.{0,1}`, but the underlying preview detection logic has been completely rewritten since the stable branch cut.
(cherry picked from commit 4abea34) Fixes of flutter#171992 for the stable branch. Cherry-pick of [https://github.com/flutter/flutter/pull/173807](https://github.com/flutter/flutter/pull/173807) onto stable. **Impacted Users** Developers and end-users of Flutter applications running on Samsung Galaxy S10 or Note 10 series devices equipped with Exynos 9820/9825 SoCs. **Impact Description** Due to malfunctioning Vulkan drivers on these SoCs, platform views that rely on `SurfaceView` fail to render correctly. The original PR addresses this by blocklisting the affected SoCs, forcing them to use Impeller with OpenGL ES instead of Vulkan. **Workaround** Aside from setting `io.flutter.embedding.android.ImpellerBackend` (which is not available in production) or disabling Impeller entirely, there is no practical workaround for this issue on affected devices. **Risk** The risk of this cherry-pick is low. The original PR only adds specific SoCs to the blocklist and renames a static variable, which does not affect other devices regardless of whether they use this mechanism. **Test Coverage** Due to the nature of the issue and the fix, validation can only be performed through manual testing on the affected devices. As the reporter of the original issue, I have verified the fix on the Galaxy S10 5G(SM-G977N, Exynos 9820), confirming that the change resolves the rendering problem. **Validation Steps** 1. Create a test Flutter app that uses a platform view with `SurfaceView` (e.g., [https://github.com/bc-lee/test-flutter-android-texture](https://github.com/bc-lee/test-flutter-android-texture) or [https://github.com/gaaclarke/surface_platformview](https://github.com/gaaclarke/surface_platformview)). 2. Run the app on the targeted devices. 3. Verify that the application renders correctly without graphical issues. **Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.
This pull request is created by [automatic cherry pick workflow](https://github.com/flutter/flutter/blob/main/docs/releases/Flutter-Cherrypick-Process.md#automatically-creates-a-cherry-pick-request) Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request. ### Issue Link: What is the link to the issue this cherry-pick is addressing? Stablize infrastructure. ### Changelog Description: Explain this cherry pick in one line that is accessible to most Flutter developers. See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples N/A ### Impact Description: What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)? Does it impact development (ex. flutter doctor crashes when Android Studio is installed), or the shipping production app (the app crashes on launch) Failed pre-submit/post-submit builds that are not actionable. ### Workaround: Is there a workaround for this issue? No ### Risk: What is the risk level of this cherry-pick? - [x] Low - [ ] Medium - [ ] High ### Test Coverage: Are you confident that your fix is well-tested by automated tests? - [ ] Yes - [x] No ### Validation Steps: What are the steps to validate that this fix works? You can merge PRs. Co-authored-by: Matan Lurey <matanlurey@users.noreply.github.com>
…flutter#174078) This pull request is created by [automatic cherry pick workflow](https://github.com/flutter/flutter/blob/main/docs/releases/Flutter-Cherrypick-Process.md#automatically-creates-a-cherry-pick-request) Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request. ### Issue Link: What is the link to the issue this cherry-pick is addressing? Stablize infrastructure. ### Changelog Description: Explain this cherry pick in one line that is accessible to most Flutter developers. See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples N/A ### Impact Description: What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)? Does it impact development (ex. flutter doctor crashes when Android Studio is installed), or the shipping production app (the app crashes on launch) Failed pre-submit/post-submit builds that are not actionable. ### Workaround: Is there a workaround for this issue? No ### Risk: What is the risk level of this cherry-pick? - [x] Low - [ ] Medium - [ ] High ### Test Coverage: Are you confident that your fix is well-tested by automated tests? - [ ] Yes - [x] No ### Validation Steps: What are the steps to validate that this fix works? You can merge PRs. Co-authored-by: Matan Lurey <matanlurey@users.noreply.github.com>
…arts on Windows (flutter#174055) This pull request is created by [automatic cherry pick workflow](https://github.com/flutter/flutter/blob/main/docs/releases/Flutter-Cherrypick-Process.md#automatically-creates-a-cherry-pick-request) Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request. ### Issue Link: What is the link to the issue this cherry-pick is addressing? flutter#173895 ### Changelog Description: Explain this cherry pick in one line that is accessible to most Flutter developers. See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples When running on Windows, `flutter widget-preview start` eventually crashes due to an unhandled exception from the Windows file system watcher that should not be considered fatal. ### Impact Description: What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)? Does it impact development (ex. flutter doctor crashes when Android Studio is installed), or the shipping production app (the app crashes on launch) Given enough time, the file system watcher backing the `WindowsDirectoryWatcher` instance will add an error to the stream with the `Directory watcher closed unexpectedly` message. The `WindowsDirectoryWatcher` restarts the backing file system watcher, but if the event stream doesn't have an error handler registered, the tool crashes due to the unhandled exception. ### Workaround: Is there a workaround for this issue? No. ### Risk: What is the risk level of this cherry-pick? ### Test Coverage: Are you confident that your fix is well-tested by automated tests? ### Validation Steps: What are the steps to validate that this fix works? Run `flutter widget-preview start` on Windows for a prolonged period of time.
|
This pull request was opened against a branch other than master. Since Flutter pull requests should not normally be opened against branches other than master, I have changed the base to master. If this was intended, you may modify the base back to stable. See the Release Process for information about how other branches get updated. Reviewers: Use caution before merging pull requests to branches other than master, unless this is an intentional hotfix/cherrypick. |
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
There was a problem hiding this comment.
Code Review
This pull request primarily corrects a misleading log message for manual iOS code signing. Additionally, it includes a substantial number of other improvements and fixes across the repository. Key changes include a new LLDB-based debugging workflow for physical iOS devices, updates to Android Gradle and Java compatibility checks, and various fixes in the web UI, engine, and framework. The changes are well-implemented and improve the robustness and user experience of the tool.
| processIdentifier: data['processIdentifier'] is int? | ||
| ? data['processIdentifier'] as int? | ||
| : null, |
There was a problem hiding this comment.
This type check and cast can be simplified for better readability while maintaining the same type safety.
| processIdentifier: data['processIdentifier'] is int? | |
| ? data['processIdentifier'] as int? | |
| : null, | |
| processIdentifier: data['processIdentifier'] is int | |
| ? data['processIdentifier'] as int | |
| : null, |
|
Closing in favor of #177852 which contains only the intended changes on a clean branch. |
…SIGN_STYLE=Manual) (#177852) ## Summary When running `flutter build ipa` with a project that uses manual code signing (`CODE_SIGN_STYLE=Manual`) for Release/Profile, the tool currently prints: ``` Automatically signing iOS for device deployment using specified development team in Xcode project: x ``` This is misleading in two ways: 1. The project is not using automatic signing for Release/Profile, it's explicitly using manual signing with a provisioning profile. 2. The build in this mode is typically for App Store/TestFlight distribution, not just device deployment. Users who rely on manual signing (for example, Push Notifications + Sign in with Apple entitlements) often hit an `xcodebuild -exportArchive` failure later (`"Runner.app" requires a provisioning profile ...`) and assume Flutter overrode their signing, because of this log line. This confusion has been reported in the context of `flutter build ipa` where archive succeeds but export fails, and Flutter's messaging doesn't match the actual signing setup. **Related issues:** - #106612 - Support `flutter build ipa` with manual signing and provisioning profiles - #113977 - Flutter build IPA with --export-options-plist not working ## What this change does * Before logging "Automatically signing iOS ...", we now check the active build configuration's `CODE_SIGN_STYLE`. * If the style is `Manual`, we suppress the automatic-signing message (since manual signing is not automatic). * If the style is `Automatic` or not set, we keep the original behavior. * No functional behavior of signing or export is changed. ## Before ``` Automatically signing iOS for device deployment using specified development team in Xcode project: x ``` (This message appears even when `CODE_SIGN_STYLE=Manual`) ## After ``` (No message when CODE_SIGN_STYLE=Manual, since signing is not automatic) ``` (The message only appears when `CODE_SIGN_STYLE=Automatic` or not set) ## Tests * Added test in `packages/flutter_tools/test/general.shard/ios/code_signing_test.dart` to assert we don't emit the automatic-signing message when `CODE_SIGN_STYLE=Manual`. * All existing tests pass (40/40 tests in code_signing_test.dart). ## Why this helps * Reduces confusion around manual signing / App Store export flows. * Matches expectations from users who configure provisioning profiles manually and expect Flutter to respect that configuration. * Prevents users from thinking Flutter is overriding their manual signing setup based on misleading log output. ## Breaking Changes None. This change only affects log output and does not modify any signing behavior, export behavior, or CLI interface. ## Verification Reviewers can verify this fix by: 1. Creating a test iOS project with `CODE_SIGN_STYLE=Manual` and `DEVELOPMENT_TEAM` set in Xcode project settings 2. Running `flutter build ipa --release --verbose` 3. Confirming the log does NOT show "Automatically signing iOS..." 4. Verifying the app still builds/signs correctly The included unit test covers this scenario automatically. --- Supersedes #177851 (that PR accidentally included unrelated commits from my fork history). This version only includes the intended change and tests. --------- Co-authored-by: Navaron Bracke <brackenavaron@gmail.com>
…SIGN_STYLE=Manual) (flutter#177852) ## Summary When running `flutter build ipa` with a project that uses manual code signing (`CODE_SIGN_STYLE=Manual`) for Release/Profile, the tool currently prints: ``` Automatically signing iOS for device deployment using specified development team in Xcode project: x ``` This is misleading in two ways: 1. The project is not using automatic signing for Release/Profile, it's explicitly using manual signing with a provisioning profile. 2. The build in this mode is typically for App Store/TestFlight distribution, not just device deployment. Users who rely on manual signing (for example, Push Notifications + Sign in with Apple entitlements) often hit an `xcodebuild -exportArchive` failure later (`"Runner.app" requires a provisioning profile ...`) and assume Flutter overrode their signing, because of this log line. This confusion has been reported in the context of `flutter build ipa` where archive succeeds but export fails, and Flutter's messaging doesn't match the actual signing setup. **Related issues:** - flutter#106612 - Support `flutter build ipa` with manual signing and provisioning profiles - flutter#113977 - Flutter build IPA with --export-options-plist not working ## What this change does * Before logging "Automatically signing iOS ...", we now check the active build configuration's `CODE_SIGN_STYLE`. * If the style is `Manual`, we suppress the automatic-signing message (since manual signing is not automatic). * If the style is `Automatic` or not set, we keep the original behavior. * No functional behavior of signing or export is changed. ## Before ``` Automatically signing iOS for device deployment using specified development team in Xcode project: x ``` (This message appears even when `CODE_SIGN_STYLE=Manual`) ## After ``` (No message when CODE_SIGN_STYLE=Manual, since signing is not automatic) ``` (The message only appears when `CODE_SIGN_STYLE=Automatic` or not set) ## Tests * Added test in `packages/flutter_tools/test/general.shard/ios/code_signing_test.dart` to assert we don't emit the automatic-signing message when `CODE_SIGN_STYLE=Manual`. * All existing tests pass (40/40 tests in code_signing_test.dart). ## Why this helps * Reduces confusion around manual signing / App Store export flows. * Matches expectations from users who configure provisioning profiles manually and expect Flutter to respect that configuration. * Prevents users from thinking Flutter is overriding their manual signing setup based on misleading log output. ## Breaking Changes None. This change only affects log output and does not modify any signing behavior, export behavior, or CLI interface. ## Verification Reviewers can verify this fix by: 1. Creating a test iOS project with `CODE_SIGN_STYLE=Manual` and `DEVELOPMENT_TEAM` set in Xcode project settings 2. Running `flutter build ipa --release --verbose` 3. Confirming the log does NOT show "Automatically signing iOS..." 4. Verifying the app still builds/signs correctly The included unit test covers this scenario automatically. --- Supersedes flutter#177851 (that PR accidentally included unrelated commits from my fork history). This version only includes the intended change and tests. --------- Co-authored-by: Navaron Bracke <brackenavaron@gmail.com>
…SIGN_STYLE=Manual) (flutter#177852) ## Summary When running `flutter build ipa` with a project that uses manual code signing (`CODE_SIGN_STYLE=Manual`) for Release/Profile, the tool currently prints: ``` Automatically signing iOS for device deployment using specified development team in Xcode project: x ``` This is misleading in two ways: 1. The project is not using automatic signing for Release/Profile, it's explicitly using manual signing with a provisioning profile. 2. The build in this mode is typically for App Store/TestFlight distribution, not just device deployment. Users who rely on manual signing (for example, Push Notifications + Sign in with Apple entitlements) often hit an `xcodebuild -exportArchive` failure later (`"Runner.app" requires a provisioning profile ...`) and assume Flutter overrode their signing, because of this log line. This confusion has been reported in the context of `flutter build ipa` where archive succeeds but export fails, and Flutter's messaging doesn't match the actual signing setup. **Related issues:** - flutter#106612 - Support `flutter build ipa` with manual signing and provisioning profiles - flutter#113977 - Flutter build IPA with --export-options-plist not working ## What this change does * Before logging "Automatically signing iOS ...", we now check the active build configuration's `CODE_SIGN_STYLE`. * If the style is `Manual`, we suppress the automatic-signing message (since manual signing is not automatic). * If the style is `Automatic` or not set, we keep the original behavior. * No functional behavior of signing or export is changed. ## Before ``` Automatically signing iOS for device deployment using specified development team in Xcode project: x ``` (This message appears even when `CODE_SIGN_STYLE=Manual`) ## After ``` (No message when CODE_SIGN_STYLE=Manual, since signing is not automatic) ``` (The message only appears when `CODE_SIGN_STYLE=Automatic` or not set) ## Tests * Added test in `packages/flutter_tools/test/general.shard/ios/code_signing_test.dart` to assert we don't emit the automatic-signing message when `CODE_SIGN_STYLE=Manual`. * All existing tests pass (40/40 tests in code_signing_test.dart). ## Why this helps * Reduces confusion around manual signing / App Store export flows. * Matches expectations from users who configure provisioning profiles manually and expect Flutter to respect that configuration. * Prevents users from thinking Flutter is overriding their manual signing setup based on misleading log output. ## Breaking Changes None. This change only affects log output and does not modify any signing behavior, export behavior, or CLI interface. ## Verification Reviewers can verify this fix by: 1. Creating a test iOS project with `CODE_SIGN_STYLE=Manual` and `DEVELOPMENT_TEAM` set in Xcode project settings 2. Running `flutter build ipa --release --verbose` 3. Confirming the log does NOT show "Automatically signing iOS..." 4. Verifying the app still builds/signs correctly The included unit test covers this scenario automatically. --- Supersedes flutter#177851 (that PR accidentally included unrelated commits from my fork history). This version only includes the intended change and tests. --------- Co-authored-by: Navaron Bracke <brackenavaron@gmail.com>
…SIGN_STYLE=Manual) (flutter#177852) ## Summary When running `flutter build ipa` with a project that uses manual code signing (`CODE_SIGN_STYLE=Manual`) for Release/Profile, the tool currently prints: ``` Automatically signing iOS for device deployment using specified development team in Xcode project: x ``` This is misleading in two ways: 1. The project is not using automatic signing for Release/Profile, it's explicitly using manual signing with a provisioning profile. 2. The build in this mode is typically for App Store/TestFlight distribution, not just device deployment. Users who rely on manual signing (for example, Push Notifications + Sign in with Apple entitlements) often hit an `xcodebuild -exportArchive` failure later (`"Runner.app" requires a provisioning profile ...`) and assume Flutter overrode their signing, because of this log line. This confusion has been reported in the context of `flutter build ipa` where archive succeeds but export fails, and Flutter's messaging doesn't match the actual signing setup. **Related issues:** - flutter#106612 - Support `flutter build ipa` with manual signing and provisioning profiles - flutter#113977 - Flutter build IPA with --export-options-plist not working ## What this change does * Before logging "Automatically signing iOS ...", we now check the active build configuration's `CODE_SIGN_STYLE`. * If the style is `Manual`, we suppress the automatic-signing message (since manual signing is not automatic). * If the style is `Automatic` or not set, we keep the original behavior. * No functional behavior of signing or export is changed. ## Before ``` Automatically signing iOS for device deployment using specified development team in Xcode project: x ``` (This message appears even when `CODE_SIGN_STYLE=Manual`) ## After ``` (No message when CODE_SIGN_STYLE=Manual, since signing is not automatic) ``` (The message only appears when `CODE_SIGN_STYLE=Automatic` or not set) ## Tests * Added test in `packages/flutter_tools/test/general.shard/ios/code_signing_test.dart` to assert we don't emit the automatic-signing message when `CODE_SIGN_STYLE=Manual`. * All existing tests pass (40/40 tests in code_signing_test.dart). ## Why this helps * Reduces confusion around manual signing / App Store export flows. * Matches expectations from users who configure provisioning profiles manually and expect Flutter to respect that configuration. * Prevents users from thinking Flutter is overriding their manual signing setup based on misleading log output. ## Breaking Changes None. This change only affects log output and does not modify any signing behavior, export behavior, or CLI interface. ## Verification Reviewers can verify this fix by: 1. Creating a test iOS project with `CODE_SIGN_STYLE=Manual` and `DEVELOPMENT_TEAM` set in Xcode project settings 2. Running `flutter build ipa --release --verbose` 3. Confirming the log does NOT show "Automatically signing iOS..." 4. Verifying the app still builds/signs correctly The included unit test covers this scenario automatically. --- Supersedes flutter#177851 (that PR accidentally included unrelated commits from my fork history). This version only includes the intended change and tests. --------- Co-authored-by: Navaron Bracke <brackenavaron@gmail.com>
Summary
When running
flutter build ipawith a project that uses manual code signing (CODE_SIGN_STYLE=Manual) for Release/Profile, the tool currently prints:This is misleading in two ways:
Users who rely on manual signing (for example, Push Notifications + Sign in with Apple entitlements) often hit an
xcodebuild -exportArchivefailure later ("Runner.app" requires a provisioning profile ...) and assume Flutter overrode their signing, because of this log line. This confusion has been reported in the context offlutter build ipawhere archive succeeds but export fails, and Flutter's messaging doesn't match the actual signing setup.Related issues:
flutter build ipawith manual signing and provisioning profiles #106612 - Users report the misleading "Automatically signing..." message even when using manual signingWhat this change does
CODE_SIGN_STYLE.Manual, we suppress the automatic-signing message (since manual signing is not automatic).Automaticor not set, we keep the original behavior.Before
(This message appears even when
CODE_SIGN_STYLE=Manual)After
(The message only appears when
CODE_SIGN_STYLE=Automaticor not set)Tests
packages/flutter_tools/test/general.shard/ios/code_signing_test.dartto assert we don't emit the automatic-signing message whenCODE_SIGN_STYLE=Manual.Why this helps