…figuration (#13014)

First landing PR for the background-color feature reviewed in #12357. This PR contains only the `google_maps_flutter_platform_interface` changes, as requested in [the combined PR discussion](#12357 (comment)).

Adds nullable `MapConfiguration.backgroundColor`, includes it in configuration diffing, equality, hashing, and legacy serialization, and adds tests for those contracts. Bumps the package to 2.18.0 and folds the existing `NEXT` minimum-SDK entry into that release.

The implementation and app-facing changes remain in #12357 and will be split into follow-up PRs after this package lands and is published. This is part of flutter/flutter#142520; the issue should remain open until the full feature lands.

Validation: repository formatter, analysis, Dart tests, validation, publish dry-run (zero warnings), and license check all pass.

## Pre-Review Checklist

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

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

On Android, embedding an `ExpansionTile` in a `WidgetSpan` can trigger a sibling-configuration conflict assertion when semantics are enabled. Its live-region `Semantics` uses `AccessibilityFocusBlockType.blockNode` but can merge into the surrounding semantics tree.

This makes the live region a semantics container, so `blockNode` applies to an explicit node. The regression test uses the simpler reproduction suggested in flutter/flutter#190639 and relies on the semantics handle managed by `testWidgets`.

Fixes flutter/flutter#188298.

This ports flutter/flutter#190639 to `packages/material_ui`. The earlier package PR, #12383, was closed while contributions were paused. On October 2, I rebased this replacement onto current `main` (`10cde9a3b`) to refresh its stale CI configuration. The contribution itself is unchanged: the semantics fix, its regression test, and a pending changelog entry. There are no custom CI changes in this PR.

I used AI to help with the fix and regression test.

## Pre-Review Checklist

Local validation after the October 2 rebase, on macOS with the already-installed Flutter 3.47.5 / Dart 3.13.4:

- Full `material_ui` suite: `flutter test --no-pub --concurrency=2` — 8,222 passed, 12 existing skips, no failures.
- Full example suite: `flutter test --no-pub --concurrency=1` in `packages/material_ui/example` — 406 passed, two existing skips, no failures.
- ExpansionTile file separately: 64 passed, one existing skip (also included in the full suite).
- Defaults generator suite: `dart test` — 72 passed.
- Full-package `flutter analyze --no-pub`: no issues.
- Dart formatting and `git diff --check`: passed.
- `dart run script/tool/bin/flutter_plugin_tools.dart validate --packages material_ui --check-for-missing-changes --base-branch upstream/main`: passed.

I repeated the regression's fail-without-fix check on the rebased branch: removing `container: true` produces the original `!conflict` assertion; restoring it makes the test pass. The existing `flutter_goldens` harness skips golden-image comparisons; I did not change that behavior. These are local test results, not a claim that repository-wide CI has passed.

GitHub automatically removed the `CICD` label after the October 2 push. Could a maintainer reapply it for the refreshed head so the repository presubmits can run?

The release metadata uses `material_ui`'s batch-release convention: a pending changelog entry with `version: patch`.

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

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