[camera_platform_interface] Add zero-shutter-lag API (#12996)

Platform interface portion of #12374, split out per the [federated plugin process](https://github.com/flutter/flutter/blob/master/docs/ecosystem/contributing/README.md#changing-federated-plugins) now that the combined PR is approved. No changes from what was reviewed there.

Adds two methods to `CameraPlatform`, with `false` / no-op defaults:

```dart
Future<bool> isZeroShutterLagSupported(int cameraId);
Future<void> setZeroShutterLagEnabled(int cameraId, bool enabled);
```

Part of flutter/flutter#190598

## Pre-Review Checklist

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

[pigeon] Reject unsupported native interop features and fix generated…

… code that doesn't compile (#13153)

Pigeon accepted several combinations of `swift_use_ffi` or `kotlin_use_jni` with other features and options that generated code that doesn't compile. One combination crashed pigeon. flutter/flutter#193881 reported two of them: event channels and ProxyApis with Swift FFI.

To find the rest, I generated every repo pigeon input and a set of edge-case inputs with each interop option. I then type-checked the Swift, compiled the Kotlin and analyzed the Dart. That found 19 broken combinations, and fixing them found a few more.

This PR adds a validation error where native interop has no implementation yet, and fixes the generators for everything else. It also adds a test API to the test plugin that uses the names JNIgen renames, so the integration tests check pigeon's copy of JNIgen's renaming rules at runtime.

**New validation errors.** Apart from event channels and ProxyApis with Kotlin JNI, none of these combinations ever produced code that compiled.

- **Swift FFI:**
  - Event channels, ProxyApis and sealed classes. The error says to move them to a separate pigeon file that doesn't use `swift_use_ffi`.
  - Data class fields that conflict with `NSObject` members, because FFI bridge classes extend `NSObject`. Examples are `hash`, `isProxy` and `superclass`, plus names that ffigen renames, such as `alloc` or `isEqual`.
  - HostApi parameters named `wrappedError`. ffigen would generate two `wrappedError:` named parameters.
  - `includeErrorClass: false`. swiftgen compiles each Swift file on its own, so the file must declare its error class. Give each file a different `errorClassName` instead.
- **Kotlin JNI:** Event channels, ProxyApis and sealed classes, the same as Swift FFI. The error says to move them to a separate pigeon file that doesn't use `kotlin_use_jni`.
  - Sealed classes never worked. The Kotlin compiles, but the generated Dart has no JNI conversion for them.
  - Event channels and ProxyApis did compile, because the Kotlin file falls back to channel code for them. They're rejected so that both interop options support the same features until these work over native interop. A file that generated before can now fail validation, but native interop is still marked experimental.
- **Dart:** API method names that conflict with generated native interop members:
  - HostApi: `getInstance` and `createWithNativeInteropApi`.
  - FlutterApi: `implement`, and with JNI also `dartApi` and `register`.

**Generator fixes**

- **Swift (FFI):**
  - The bridge for a class without fields didn't compile because its `init()` was missing `override`.
  - `@asyncCallback` host methods: the bridge `await`ed a callback-style method. It now wraps the call in `withCheckedThrowingContinuation`.
  - `@SwiftFunction` overloads that differ only in nullability were ambiguous. The bridge now declares the result type.
  - An API method named `type` broke error handling in every method of that API, because `type(of:)` resolved to the method. The bridge now uses `Swift.type(of:)`.
  - Parameters that shared a name with one of the bridge's own parameters, such as a FlutterApi parameter named `error`, collided with it. Internal parameter names now end in `Arg`. Selectors don't change.
  - Two FFI files in the same module both declared `_PigeonFfiCodec`. It's now `private`.
- **Dart:**
  - Pigeon crashed with `Bad state: No element` when a class without fields was used with Swift FFI.
  - JNI calls used the Kotlin member names, but JNIgen changes some of them:
    - It renames members that clash with its own, such as `type`, `release`, `use` and `isNull`.
    - It turns `getX()`, `isX()` and `setX()` into properties.
    - It turns `is`-prefixed data class properties that aren't `Boolean` into methods.

    A new `_JniBindingNamer` mirrors the JNIgen 1.0.1 renamer for data class fields, HostApi methods and FlutterApi overrides. It replaces `_getJniFieldName`, which handled only a few field names.
  - FFI calls assumed that Swift's Objective-C selectors always join the method name and the first argument label with `With`. Swift leaves out `With` when the method name ends with a preposition or the label starts with one. For example, `signIn(value:)` becomes `signInValue:` and `init(forKey:)` becomes `initForKey:`. Dart now applies the same rule to host API calls, FlutterApi callbacks and data class bridge initializers. It uses the preposition list from Swift's [`PartsOfSpeech.def`](https://github.com/swiftlang/swift/blob/main/lib/Basic/PartsOfSpeech.def) and Swift's camel-case word splitting.
  - Generated local variables shadowed parameters with the same name, such as `res`, `error`, `completer` and `response`. Generated locals now use the `pigeonVar_` prefix, and callback parameters use `arg_`.
  - Lists and maps of ProxyApis caused the interop codecs to contain the literal text `There is something wrong, a type is not classified`. The codecs now skip those types.
  - The class-name prefix for FFI types didn't match the Swift one in three cases:
    - The Swift file name wasn't UpperCamelCase.
    - `fileSpecificClassNameComponent` wasn't UpperCamelCase.
    - `SwiftOptions.fileSpecificClassNameComponent` was set.

    Dart now uses the same precedence and casing as the Swift generator.
  - Test files (`dartTestOut`) contained native interop code that referenced bindings they don't import. They're now generated with method channels only, which is all their mock handlers use.
- **Docs:** The `includeErrorClass` docs on `SwiftOptions` and `KotlinOptions` explain the native interop requirements.

**Test plugin**

`native_interop_tests.dart` adds `NativeInteropReservedNames`, `NativeInteropReservedNamesHostApi` and `NativeInteropReservedNamesFlutterApi`. Their names cover each JNIgen renaming rule:

- members that clash with JNIgen's own, such as `release`, `use`, `type`, `isNull`, `reference` and `jClass`;
- getters, setters and `is` methods that JNIgen turns into properties, including `getDefault`, which becomes a Dart keyword;
- `is` fields that aren't `bool`, which JNIgen turns into methods;
- an `@async` method, which JNIgen keeps as a method because it's a Kotlin `suspend` function;
- a FlutterApi method named `implementIn`, which clashes with JNIgen's `implementIn`.

The Kotlin and Swift test plugins implement both APIs, and new integration tests call every method and round-trip the data class. The tests use `true` for `isNull` and `isReleased`, so they fail if the generated code calls `JObject`'s own members instead, which return `false`. This API is also how I found the Swift selector bug above: `implementIn` ends with a preposition.

The test plugin and the native interop example are regenerated. Apart from the new test API, their diffs contain only:

- the renames above;
- `private` on `_PigeonFfiCodec`;
- `Swift.type(of:)`;
- the matching ffigen bindings and Objective-C header.

Selectors and public APIs don't change.

**Testing**

- New unit tests: 12 for validation, 6 for the Dart generator and 4 for the Swift generator. All 581 pigeon unit tests pass.
- The Android (emulator) and macOS integration suites pass, including the new reserved-name tests: 674 tests on Android, and 673 on macOS with 1 existing skip. I didn't run iOS locally.
- I compiled Kotlin that uses every JNIgen-reserved name and ran JNIgen 1.0.1 on it. The generated Dart analyzes against those bindings with no errors.
- I checked Swift's selector rule with `swiftc`, for every preposition and for names with underscores, digits and acronyms.
- I re-ran the full probe. Validation rejects exactly the unsupported combinations, and the generated Swift for every other case type-checks with `swiftc`.

Fixes flutter/flutter#193881

## Pre-Review Checklist

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

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

[video_player] Fix crash when videoTrack has zero-duration minFrameDu…

…ration (#12796)

Fixes a crash on iOS caused by a zero-duration frame duration. When creating the `AVMutableVideoComposition` a check is made against `CMTIME_IS_VALID` but this doesn't guard against a frame duration of 0. I just added one more check to make sure the frame duration is > 0.

Part of flutter/flutter#151031

## Pre-Review Checklist

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

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

[in_app_purchase_storekit] Complete StoreKit 2 `finish` when the tran…

…saction is not found (#13037)

StoreKit 2 `finish(id:completion:)` only called `completion` when `fetchTransaction` found the transaction. `fetchTransaction` searches `Transaction.all`, which by default does not contain finished consumables, so a second `completePurchase` for a consumable that was already finished (for example after a duplicate delivery) returned a `Future` that never completed. The StoreKit 1 path already treats a missing transaction as success (`testFinishTransactionSucceedsWithNilTransaction`).

This PR:
- Calls `completion(.success(Void()))` after the lookup whether or not a transaction was found.
- Removes the `throws` from `fetchTransaction`, which has no throwing call. This rules out the second hang the issue describes (an error thrown inside the `Task` in `finish` and never reported) and clears the Xcode 27 warning `unstructured throwing task ... may accidentally ignore errors thrown inside the task`. The one test caller drops its now unneeded `try`.
- Adds `testFinishTransactionSucceedsWhenAlreadyFinished`, which purchases a consumable and finishes it twice; the second `finish` times out without the fix and passes with it.
- Makes `testFinishTransaction` also check that the purchase is no longer unfinished, since its completion alone no longer proves the transaction was found.

Tested with the iOS `RunnerTests` on an iOS 26.2 simulator, the CI destination.

This only makes the `Future` complete; it does not change which transactions StoreKit redelivers.

Fixes flutter/flutter#192400

## Pre-Review Checklist

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

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

[image_picker_ios] Return an error for undecodable image data (#12267)

`PHPicker` can provide data for a type that conforms to `UTTypeImage` even when `UIImage` cannot decode the bytes. The linked issue reports this with an AVIF selection. The existing path continues with a `nil` image and can treat the selection as successfully saved.

This change completes the operation with the existing `invalid_image` error when decoding fails. It also adds a regression test that verifies the callback returns no path and that the `NSOperation` finishes.

Fixes flutter/flutter#132154

No public API documentation changes are needed because this uses the existing image-picker error contract.

Tests run:

- `flutter_plugin_tools format --packages image_picker_ios --fail-on-change`
- `flutter_plugin_tools analyze --ios --packages image_picker_ios`
- `flutter_plugin_tools dart-test --packages image_picker_ios`
- `flutter_plugin_tools native-test --ios --no-integration --packages image_picker_ios`
- `flutter_plugin_tools validate --packages image_picker_ios`
- `flutter_plugin_tools license-check`
- `(from packages/image_picker/image_picker_ios) dart pub publish --dry-run`

## Pre-Review Checklist

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

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

[pigeon] Fix native interop (JNI) calls in minified Android release b…

…uilds (#13151)

Flutter minifies Android release builds with R8, which removes or renames classes that it doesn't see being used. JNI looks up classes and members by name at runtime, from Dart code that R8 can't see. As a result, native interop calls that work in debug builds fail in release builds with `ClassNotFoundException` or `NoSuchMethodError`.

This PR:

- **Kotlin generator:** When `useJni` is set, adds `@Keep` to every generated class that JNI reaches by name:
  - data classes, including sealed classes;
  - enums and their companion objects;
  - the FlutterApi interface and its Registrar;
  - the error class.

  The HostApi interface and Registrar already had `@Keep`. The test plugin and example app are regenerated.
- **Docs:** Documents keep rules for six Kotlin standard library classes. `package:jni` and the generated Dart code look these up by name to call and implement `suspend` (`@async`) methods. Library classes can't be annotated, so these rules are needed until `package:jni` ships them (dart-lang/native#3732).
  - Updated `native_interop_guide.md`, `native_interop_migration_guide.md` and the migration skill.
  - Each spot has a TODO linking that issue.
- **CI:** Adds an `android_kotlin_native_interop_release_tests` suite to the `Linux_android custom_package_tests` shard. It runs the native interop integration tests in a minified release build.
  - `flutter test` and `flutter drive` don't support release builds on Android, so the suite uses `flutter run --release` and reads the test summary from its output.
  - The test plugin adds the six Kotlin rules in `consumer-rules.pro`, with a TODO to delete them once dart-lang/native#3732 is fixed.
  - It deliberately has no rule for its own package, so a missing `@Keep` on any generated class still fails the suite.

Results for the native interop suite (339 tests) in a minified release build on an arm64 emulator:

| | Passed | Failed | Didn't run |
|---|---|---|---|
| Before (old generated code, with the Kotlin rules) | 106 | 70 | 163 |
| This PR, without the Kotlin rules | 210 | 129 | 0 |
| This PR | 339 | 0 | 0 |

- **Before:** 163 tests didn't run. R8 had removed the FlutterApi interface, so registering the FlutterApi threw `ClassNotFoundException` during test setup.
- **Without the Kotlin rules:** every failure is a call through a `suspend` function. Each one fails with `NoSuchMethodError`, because R8 renames `kotlin.coroutines.Continuation`.

Fixes flutter/flutter#193880
Temporary fix for dart-lang/native#3732

## Pre-Review Checklist

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

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

[flutter shaders] update min flutter version (#13160)

I accidentally landed the new package with the wrong min versions, this will need to land to allow publishing to work.

[quick_actions_android] Return null from getLaunchAction when no acti…

…vity is attached (#12331)

`getLaunchAction` threw `quick_action_getlaunchaction_no_activity` when the plugin had no attached activity. `QuickActionsAndroid.initialize` calls `getLaunchAction` unconditionally, so `initialize` threw a `PlatformException` that callers could not prevent.

An engine can legitimately run without an attached activity. A cached engine warmed up by a background service is the common case: `audio_service` supplies a cached engine to its activity and also warms up that same engine from `AudioService.onCreate`, so `main()` runs with no activity when a media button or Android Auto starts the service.

This returns `null` in that case instead, and logs at debug level. The throw provided no recovery value:

* `initialize` registers the Dart handler before it calls `getLaunchAction`, so the handler is already installed when the exception is thrown.
* When an activity does attach, `QuickActionsPlugin.onAttachedToActivity` calls `onNewIntent(activity.getIntent())`, which reports the shortcut through `AndroidQuickActionsFlutterApi.launchAction`.

`null` is also already the return value for the other "cannot answer" case in this method, on the line directly above (`if (!isVersionAllowed())`).

Verified on an Android 12 emulator by pointing an app at this branch and starting its audio service with no UI: no exception, and a shortcut tap afterwards still routed correctly. A cold start from a shortcut still returns the action, so the activity-present path is unchanged. The new unit test fails with `io.flutter.plugins.quickactions.FlutterError` against the unmodified file.

Fixes flutter/flutter#190348

## Pre-Review Checklist

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

[material_ui] Batch release (#13127)

This PR was created automatically to batch release the `material_ui`.

[image_picker] Document that retrieving lost data is a one-time opera…

…tion (#12784)

Documents that lost-data retrieval is destructive: once the lost data is
returned it is cleared, so subsequent calls return an empty result. Adds the
note at both the app-facing layer (`ImagePicker.retrieveLostData`) and the
platform interface (`ImagePickerPlatform.getLostData`), matching the intended
behavior described in the issue.

This is a documentation-only change (dartdoc plus CHANGELOG), so adds no tests
(test-exempt).

Fixes flutter/flutter#164223

## Pre-Review Checklist

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

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.