Update `engine.version` to Dart version + DEPS update: 3452d735bd
Tests will fail until https://ci.chromium.org/ui/p/dart-internal/builders/flutter/Linux%20flutter_release_builder/1198 completes.
**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.
As the title says :)
**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.
Bump dart revision to 1a420a3f9a and update DEPS.
**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?
https://github.com/flutter/flutter/issues/177992https://github.com/flutter/flutter/issues/175606
### 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 of production apps (the app crashes on launch).
This information is for domain experts and release engineers to understand the consequences of saying yes or no to the cherry pick.
The issues listed above impact app users. For instance #177992 prevents the user from interacting with hamburger menus on iPadOS 26.1+ for context, this probably has always been an issue but on iPadOS 26.1 the height of the status bar became taller so it gets in the way of the hamburger menu.
### Changelog Description:
Explain this cherry pick:
* In one line that is accessible to most Flutter developers.
* That describes the state prior to the fix.
* That includes which platforms are impacted.
See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples.
[flutter/177992] on iPadOS 26.1, tapping on the status bar dismisses the current modal route.
### Workaround:
Is there a workaround for this issue?
Yes. There is a relatively reliable workaround described here: https://github.com/flutter/flutter/issues/175606#issuecomment-3576240885
### Risk:
What is the risk level of this cherry-pick?
- [-] Low
### Test Coverage:
Are you confident that your fix is well-tested by automated tests?
- [-] Yes
### Validation Steps:
What are the steps to validate that this fix works?
Following the repro steps in #177992. I've tried the fix myself on master following the steps outlined in the issue and couldn't reproduce the issue.
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.
Cherry-pick of https://github.com/flutter/flutter/pull/181686
### Issue Link:
What is the link to the issue this cherry-pick is addressing?
https://github.com/flutter/flutter/issues/181573
### Impact Description:
What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)?
Crash
Does it impact development (ex. flutter doctor crashes when Android Studio is installed),
or the shipping of production apps (the app crashes on launch).
App crashes
This information is for domain experts and release engineers to understand the consequences of saying yes or no to the cherry pick.
Apps running this code will crash: https://buganizer.corp.google.com/issues/478788744
### Changelog Description:
Explain this cherry pick:
* Makes sure the JNI method is called on Android's UI thread.
* The JNI method would be called by the raster's thread and cause a crash.
* That includes which platforms are impacted.
See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples.
Android Apps
< Replace with changelog description here >
[flutter/181573] When resize JNI method is called on Android, apps will crash.
### 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 the sample app https://github.com/flutter/samples/pull/2787 and check it does not crash.
This PR creates a FlutterFramework swift package with no real content. This is a placeholder so that plugins may add a dependency on the FlutterFramework in their Package.swift before https://github.com/flutter/flutter/pull/178931 lands in stable. See go/swiftpm-flutter-release.
Impacted Users: Flutter iOS with SwiftPM feature flag enabled
Impact Description: Allows plugins to add a dependency on the FlutterFramework in their Package.swift.
Workaround: See Problem 2 alternatives in [go/swiftpm-flutter-release](http://goto.google.com/swiftpm-flutter-release)
Risk: This PR by itself is low risk. It just generates a couple files in an ephemeral directory. It only is actually used if a plugin adds a dependency on it in it's Package.swift. If a plugin does this, it's still low risk since it's basically just an empty Swift package. It's also behind a feature flag (`flutter config --enable-swift-package-manager`), which can be disabled.
Test Coverage: Yes
Validation Steps:
- `flutter config --enable-swift-package-manager`
- `flutter create my_plugin && cd my_plugin/example`
- Add `FlutterFramework` to Package.swift (see [example](https://github.com/flutter/flutter/blob/master/packages/integration_test/ios/integration_test/Package.swift#L15-L21))
- `flutter build ios`
**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?
https://github.com/flutter/flutter/issues/180191
### 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 of production apps (the app crashes on launch).
This information is for domain experts and release engineers to understand the consequences of saying yes or no to the cherry pick.
Updates a library that had multiple CVE's to a version that has those issues patched.
https://ubuntu.com/security/CVE-2025-64505https://ubuntu.com/security/CVE-2025-64506https://ubuntu.com/security/CVE-2025-64720https://ubuntu.com/security/CVE-2025-65018
FWIW I have not seen a working exploit against a flutter app.
### Changelog Description:
Explain this cherry pick:
* In one line that is accessible to most Flutter developers.
* That describes the state prior to the fix.
* That includes which platforms are impacted.
See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples.
< Replace with changelog description here >
[flutter/180191] Update libpng to 1.6.53 to mitigate multiple CVE's published November/December 2025.
### Workaround:
Is there a workaround for this issue?
No work around.
### Risk:
What is the risk level of this cherry-pick?
### Test Coverage:
Are you confident that your fix is well-tested by automated tests?
- [ x ] Yes
### Validation Steps:
What are the steps to validate that this fix works?
Run the standard test suite on CI including golden image tests.
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:
https://github.com/flutter/flutter/issues/181153
### Impact Description:
This PR is to fix a typo in a newly added API (AccessiblityFocusBlockType->AccessibilityFocusBlockType)
The typo was inroduced in this PR https://github.com/flutter/flutter/pull/175551 which was merged on Nov 3, 2025 and is in 3.39-3.41
What is the impact
The impact is to fix a small typo by hotfix, so we dont need to deprecate the API and add a new API.
The risk is small because the API was recently added in Nov, 2025 and it's an API to control accessibility focus. I don't think it's widely used by external developers yet.
Also the typo is not in the previous stable 3.38, so this only needs to be cp to beta.
### Changelog Description:
Explain this cherry pick:
* In one line that is accessible to most Flutter developers.
* That describes the state prior to the fix.
* That includes which platforms are impacted.
See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples.
[flutter/181153] fix a typo in a newly added API (AccessiblityFocusBlockType->AccessibilityFocusBlockType)
### 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?
N/A
This PR cherrypicks https://github.com/flutter/flutter/pull/181074 into beta, which is mostly a revert of https://github.com/flutter/flutter/pull/176711 (except that some docs are left unreverted and a few new tests are added.) This is needed to address a breakage as described in https://github.com/flutter/flutter/issues/180121.
**Impacted Users:** Apps that use `DropdownMenu` or `DropdownMenuFormField` for a nullable class, such as `DropdownMenu<int?>`.
**Impact Description:** Can not compile.
**Workaround:** Yes, through non-trivial changes. For example, the developer can replace `DropdownMenu<int?>` with `DropdownMenu<Maybe<int>>`, as long as they import `Maybe` or create their own equivalence.
**Risk:** Low. This PR is basically a revert.
**Test Coverage:** Yes. The widget has high test coverage.
**Validation Steps:** The PR compiles and tests pass.
This PR cherrypicks https://github.com/flutter/flutter/pull/181269 into beta. This is needed to address a breakage.
**Impacted Users:** Apps that directly use `CupertinoSheetTransition `.
**Impact Description:** Can not compile.
**Workaround:** Yes. They need to add `topGap: 0.08` to the constructor.
**Risk:** Low. This PR loosens the API, and reverts the behavior to that before https://github.com/flutter/flutter/pull/171348.
**Test Coverage:** Yes. The widget has high test coverage.
**Validation Steps:** The PR compiles and tests pass. `sheet_test.dart` contains constructors that do not specify `topGap` in the same way as existing apps.
The new general convex path shadow code was checking for duplicate vertices without actually checking if the vectors contained any vertices. Thus, <vector>.back() was being called on empty vectors, which is bad. This led to a crash in G3 as their code is being run with a vector implementation that protects against this, but apparently we do not have such a vector implementation in our local building and testing.
No tests because this covered by existing test cases and a new FML_DCHECK.
<!--
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
-->
Fixes https://github.com/flutter/flutter/issues/180827
Impacted users: Any user who uses shadows (pretty much every Flutter app) on a platform that has address sanitization built into its `std::vector` implementation, if they use Impeller (always used on iOS and the default on Android)
Impact Description: Every shadow render operation in Impeller backend will access `back()` on an empty `std::vector` which will crash immediately if the vector is using sanitization on that platform.
Workaround: Potentially look into disabling address sanitization? On platforms that still support Skia, it can be used as a workaround, but that is not an option on iOS
Risk: The fix was obvious and non-controversial.
Test Coverage: Existing tests cover this case really well and there is now an FML_DCHECK (engine assert) to check if we trigger the condition under testing.
Validation: The original issue indicates an app that will trigger the sanitization crash, but only in G3. None of the platforms we support directly through flutter perform this sanitization.
**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?
https://github.com/flutter/flutter/issues/178151
### 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 run -d chrome` can crash with a `DartDevelopmentServiceException` if the application shuts down during the startup sequence.
### 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)
Flaky crashes for users developing Flutter web applications. This is one of the top crashers for 3.38.
### 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?
Difficult to validate manually as the failure is timing based. Tests have been added to simulate the crash scenario and verify the fix.
### Issue Link:
What is the link to the issue this cherry-pick is addressing?
https://github.com/flutter/flutter/issues/179857
### 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 of production apps (the app crashes on launch).
This information is for domain experts and release engineers to understand the consequences of saying yes or no to the cherry pick.
`flutter run -d all` causes the tool to crash if multiple devices are available.
### Changelog Description:
Explain this cherry pick:
* In one line that is accessible to most Flutter developers.
* That describes the state prior to the fix.
* That includes which platforms are impacted.
See [best practices](https://github.com/flutter/flutter/blob/main/docs/releases/Hotfix-Documentation-Best-Practices.md) for examples.
`flutter run -d all` causes the tool to crash if multiple devices are available.
### 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 run -d all` with multiple non-web devices available and verify the application is deployed to all non-web devices.
Fixes#179076
**Solution**
When a modal dialog is present, temporarily move the existing aria-live
element inside the modal dialog before making the announcement, then
move it back afterward. A small delay is also added to allow VoiceOver
to finish reading the button's accessible name first.
**Demo**
Before (bug): https://flutter-demo-03-before.web.app
After (fix): https://flutter-demo-03-after.web.app
**Testing**
Enable VoiceOver (Cmd+F5 on macOS)
Open a dialog and click the "Announce" button
Verify the announcement is spoken after the button label
**Next step**
Filing a follow-up issue for: Adding a delay parameter to
SemanticsService.announce() API for developers who need custom delays
for long button labels
This PR introduces a significant refactoring of the web engine's
rendering layer by unifying the Surface and Rasterizer implementations.
These components have been moved from being renderer-specific to a
generic compositing directory, making the architecture more modular and
easier to maintain. The rasterizers are now renderer-agnostic and are
provided with renderer-specific surface factories via dependency
injection. A new CanvasProvider abstraction has also been introduced to
manage the lifecycle of the underlying canvas elements.
A key outcome of this work is that the Skwasm backend now correctly
handles WebGL context loss events. This was achieved by refactoring
SkwasmSurface to allow the Dart side to manage the OffscreenCanvas
lifecycle. A communication channel between the main thread and the web
worker is now used to gracefully handle context loss and recovery. This
effort also included fixing several related bugs around surface sizing,
resource cleanup, and callback handling in multi-surface scenarios.
To validate these changes, new testing APIs have been added to allow for
the creation of renderer-agnostic surface tests. A new test file,
surface_context_lost_test.dart, has been added to verify the context
loss and recovery behavior across all supported renderers, ensuring the
new architecture is robust and reliable.
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
**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.
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview
[Tree Hygiene]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
[test-exempt]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes
[Discord]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md
[Data Driven Fixes]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md
The diagnostics string builder responsible for building diagnostics
messages can sometimes wrap lines that are too long. This caused the
expectation for the 'flutter error messages include a DevTools links' to
sometimes be incorrect when run on systems where the absolute file path
of the file referenced in the diagnostic was too long.
This change updates the test expectation to allow for both wrapping and
non-wrapping scenarios to be accepted.
Fixes https://github.com/flutter/flutter/issues/174502
# flutter_tools: Auto-generate ExportOptions.plist for manual iOS code
signing
## Summary
Enhance `flutter build ipa` to automatically generate a complete
ExportOptions.plist for manual code signing configurations, eliminating
the need for users to create and maintain one manually.
**Fixes:** #177853
## Problem
When using manual code signing (`CODE_SIGN_STYLE=Manual`) with `flutter
build ipa` for Release/Profile builds, the archive succeeds but the
export step fails with:
```
error: exportArchive: "Runner.app" requires a provisioning profile with the Push Notifications and Sign in with Apple features.
```
**Root cause:** Flutter generated an incomplete ExportOptions.plist that
only included `method` and `uploadBitcode`. When using manual signing,
`xcodebuild -exportArchive` requires:
- `teamID` (from project's `DEVELOPMENT_TEAM`)
- `signingStyle=manual`
- `provisioningProfiles` (mapping bundle ID to provisioning profile
UUID)
Without these, Xcode cannot resolve the provisioning profile for export,
even if the profile is correctly configured and contains the required
entitlements.
## Solution
Enhanced `_createExportPlist()` in `BuildIOSArchiveCommand` to
automatically generate a complete ExportOptions.plist when:
1. `CODE_SIGN_STYLE=Manual` is detected for the main app target
2. Build mode is Release or Profile (production builds only)
3. A valid provisioning profile can be located and parsed
The generated plist includes:
- `method` (app-store, ad-hoc, enterprise, etc. - respects user's
`--export-method` flag)
- `teamID` (from `DEVELOPMENT_TEAM` build setting)
- `signingStyle=manual`
- `provisioningProfiles` mapping main app bundle ID to provisioning
profile UUID
**Fallback behavior:**
- If profile lookup fails: silently fall back to simple plist (no
regression)
- For Automatic signing: unchanged behavior
- For Debug builds: unchanged behavior (not App Store export)
- For multi-target apps (extensions): falls back to simple plist today
(see TODO below)
## Changes
### Core Implementation
- Added `ProfileData` class to encapsulate provisioning profile info
(UUID and name)
- Refactored profile handling into reusable static methods for
testability
- Enhanced `_createExportPlist()` with manual signing detection and
profile lookup
- Added `_findProvisioningProfileUuid()` to locate provisioning profiles
by specifier
- Added `_parseProvisioningProfileInfo()` to decode provisioning profile
data once
- Added comprehensive trace logging for debugging
### Testing
- Created `build_ipa_export_plist_test.dart` with 7 unit tests covering:
- Manual signing with profile found → enhanced plist generated ✓
- Automatic signing → simple plist (unchanged behavior) ✓
- Debug builds → simple plist (unchanged behavior) ✓
- Different export methods → respected in generated plist ✓
- Profile lookup failures → fallback to simple plist ✓
- Null codeSignStyle → handled gracefully ✓
- All existing flutter_tools tests continue to pass
## Documentation
Added extensive inline comments explaining:
- Enhancement conditions and fallback behavior
- Provisioning profile search strategy and error handling
- Performance and security considerations
- Future enhancements (multi-target support)
## Safety & Scope
### What This Fixes
- ✅ Manual signing export failures for apps with Push Notifications /
Sign in with Apple
- ✅ Auto-generates correct plist for **any** entitlements covered by
provisioning profile
- ✅ Unblocks users from manual `--export-options-plist` workaround
- ✅ Improves iOS build UX for enterprise teams doing manual signing
### What This Does NOT Change
- ✅ Automatic signing behavior (unchanged)
- ✅ Debug builds (unchanged)
- ✅ CLI interface (no new flags)
- ✅ Ad-hoc / enterprise distributions (unchanged if not using manual
signing)
### Known Limitations (Future Enhancements)
- Currently only supports single-target apps (main app bundle ID only)
- TODO: Multi-target apps with extensions (notification service,
widgets, watch, etc.) - each extension target bundle ID may need
separate entry in provisioningProfiles dict
- TODO: Support for multiple provisioning profiles if app uses multiple
signing identities
---
## Pre-merge Checklist
- [x] I have signed the CLA
- [x] I read the Contributor Guide and Tree Hygiene docs
- [x] I linked the issue this fixes (#177853) and explained the failure
scenario
- [x] I added documentation and trace logs so developers understand what
changed
- [x] I added comprehensive unit tests for the new behavior
- [x] All existing and new tests pass locally (`flutter test
packages/flutter_tools`)
- [x] Code passes linting (`dart analyze`)
## Safety Notes
- [x] This code only runs for manual code signing in `flutter build ipa`
for Release/Profile builds
- [x] Debug builds and automatic signing behavior are completely
unchanged
- [x] If no provisioning profile UUID is found, we silently fall back to
the old exportOptions.plist logic instead of failing
- [x] Added trace-level logging explaining success/fallback scenarios
for debugging
- [x] No breaking changes - existing workarounds continue to work
- [x] Minimal blast radius - only affects manual signing export path
## Verification
Users can verify the fix by:
1. Creating an iOS app with `CODE_SIGN_STYLE=Manual`, `DEVELOPMENT_TEAM`
set, and Push Notifications entitlements
2. Running `flutter build ipa --release --verbose`
3. Confirming the trace log shows "Generated ExportOptions.plist with
teamID, signingStyle=manual, and provisioningProfiles"
4. Verifying the IPA is successfully created without needing
`--export-options-plist`
---
## Related Issues
- #106612 - Support `flutter build ipa` with manual signing and
provisioning profiles
- #113977 - Flutter build IPA with --export-options-plist not working
---------
Co-authored-by: Elijah Okoroh <okorohelijah@google.com>
The raw widget used to make a
[Tooltip](https://api.flutter.dev/flutter/material/Tooltip-class.html).
Design doc: flutter.dev/go/codeshare-tooltip
## Constructor
```dart
class RawTooltip extends StatefulWidget {
const RawTooltip({
super.key,
required this.semanticsTooltip,
required this.tooltipBuilder,
this.enableTapToDismiss = true,
this.triggerMode = TooltipTriggerMode.longPress,
this.enableFeedback = true,
this.onTriggered,
this.hoverDelay = Duration.zero,
this.touchDelay = const Duration(milliseconds: 1500),
this.dismissDelay = const Duration(milliseconds: 100),
this.animationStyle = _kDefaultAnimationStyle,
this.positionDelegate,
required this.child,
});
```
## Properties
```dart
final String semanticsTooltip;
final TooltipComponentBuilder tooltipBuilder;
final Duration hoverDelay;
final Duration touchDelay;
final Duration dismissDelay;
final bool enableTapToDismiss;
final TooltipTriggerMode triggerMode;
final bool enableFeedback;
final TooltipTriggeredCallback? onTriggered;
final AnimationStyle animationStyle;
final TooltipPositionDelegate? positionDelegate;
final Widget child;
```
Part of [☂️ Reinforcement: Add more basic components to the core
framework](https://github.com/flutter/flutter/issues/97496)
Part of [☂️ Reinforcement: Refactor widgets from design into the core
before decoupling](https://github.com/flutter/flutter/issues/53059)
Fixes [Custom Overlay for Tooltip Widget
](https://github.com/flutter/flutter/issues/45034)
---------
Co-authored-by: Tong Mu <dkwingsmt@users.noreply.github.com>
Co-authored-by: chunhtai <47866232+chunhtai@users.noreply.github.com>
## Description
The docstring says "Typically a [SliverList]" but the class example uses
`ListView`.
`SliverList` is used inside `CustomScrollView`, not as a direct child of
`Drawer`.
## Related Issue
Fixes#100268
