Skip to content

flutter_tools: correct iOS signing log for manual code signing (CODE_SIGN_STYLE=Manual)#177851

Closed
MohammedTarigg wants to merge 67 commits into
flutter:masterfrom
MohammedTarigg:fix-ios-signing-log
Closed

flutter_tools: correct iOS signing log for manual code signing (CODE_SIGN_STYLE=Manual)#177851
MohammedTarigg wants to merge 67 commits into
flutter:masterfrom
MohammedTarigg:fix-ios-signing-log

Conversation

@MohammedTarigg

Copy link
Copy Markdown
Contributor

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: 93WG32C8SG

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:

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: 93WG32C8SG

(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.

matanlurey and others added 30 commits July 15, 2025 23:42
…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
…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.
@flutter-dashboard flutter-dashboard Bot requested a review from jtmcdole as a code owner October 31, 2025 18:02
@flutter-dashboard

Copy link
Copy Markdown

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.

@google-cla

google-cla Bot commented Oct 31, 2025

Copy link
Copy Markdown

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.

@github-actions github-actions Bot added a: tests "flutter test", flutter_test, or one of our tests a: text input Entering text in a text field or keyboard related problems platform-android Android applications specifically platform-ios iOS applications specifically tool Affects the "flutter" command-line tool. See also t: labels. framework flutter/packages/flutter repository. See also f: labels. engine flutter/engine related. See also e: labels. f: material design flutter/packages/flutter/material repository. a: accessibility Accessibility, e.g. VoiceOver or TalkBack. (aka a11y) f: cupertino flutter/packages/flutter/cupertino repository platform-web Web applications specifically platform-linux Building on or for Linux specifically a: desktop Running on desktop f: integration_test The flutter/packages/integration_test plugin e: impeller Impeller rendering backend issues and features requests team-android Owned by Android platform team team-ios Owned by iOS platform team labels Oct 31, 2025

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +1182 to +1184
processIdentifier: data['processIdentifier'] is int?
? data['processIdentifier'] as int?
: null,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

This type check and cast can be simplified for better readability while maintaining the same type safety.

Suggested change
processIdentifier: data['processIdentifier'] is int?
? data['processIdentifier'] as int?
: null,
processIdentifier: data['processIdentifier'] is int
? data['processIdentifier'] as int
: null,

@MohammedTarigg

Copy link
Copy Markdown
Contributor Author

Closing in favor of #177852 which contains only the intended changes on a clean branch.

github-merge-queue Bot pushed a commit that referenced this pull request Nov 13, 2025
…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>
IvoneDjaja pushed a commit to IvoneDjaja/flutter that referenced this pull request Nov 22, 2025
…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>
mboetger pushed a commit to mboetger/flutter that referenced this pull request Dec 2, 2025
…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>
reidbaker pushed a commit to AbdeMohlbi/flutter that referenced this pull request Dec 10, 2025
…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>
@MohammedTarigg MohammedTarigg deleted the fix-ios-signing-log branch March 6, 2026 11:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

a: accessibility Accessibility, e.g. VoiceOver or TalkBack. (aka a11y) a: desktop Running on desktop a: tests "flutter test", flutter_test, or one of our tests a: text input Entering text in a text field or keyboard related problems e: impeller Impeller rendering backend issues and features requests engine flutter/engine related. See also e: labels. f: cupertino flutter/packages/flutter/cupertino repository f: integration_test The flutter/packages/integration_test plugin f: material design flutter/packages/flutter/material repository. framework flutter/packages/flutter repository. See also f: labels. platform-android Android applications specifically platform-ios iOS applications specifically platform-linux Building on or for Linux specifically platform-web Web applications specifically team-android Owned by Android platform team team-ios Owned by iOS platform team tool Affects the "flutter" command-line tool. See also t: labels.

Projects

None yet

Development

Successfully merging this pull request may close these issues.