…amera_avfoundation (#13199)

Platform implementation 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 `camera_platform_interface` 2.15.0 is published (#12996). No changes from what was reviewed there, other than rebasing onto `main` and resolving version/CHANGELOG conflicts.

Implements `isZeroShutterLagSupported` / `setZeroShutterLagEnabled` in:

- `camera_android_camerax` (0.7.6)
- `camera_avfoundation` (0.11.1, iOS 17+)

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.

This automated PR syncs the changes from the release branch release-go_router-18.1.1 back to the main branch.

…ptive_text_selection_toolbar_test, material_button_test, outlined_button_test, text_button_test (#13335)

Removes web skips (`skip: isBrowser`) from tests in `packages/material_ui/test` that now pass on both CI web renderers (CanvasKit and Skwasm). Keeping these skips hides web regressions in these tests.

- `adaptive_text_selection_toolbar_test.dart`: `Builds the right toolbar on each platform, including web, and shows buttonItems` was skipped for `Path.combine` not working with the (now removed) HTML renderer.
- `material_button_test.dart`, `outlined_button_test.dart`, `text_button_test.dart`: the `meetsGuideline(textContrastGuideline)` accessibility tests now run on the web.

Each file was run with `flutter test --platform chrome` (CanvasKit) and `flutter test --platform chrome --wasm` (Skwasm) and all tests passed. None of the unskipped tests use goldens. The diff is the skip removal plus the formatter rewrap that results from dropping the trailing `skip:` argument.

Part of flutter/flutter#44115
Related: flutter/flutter#108382 (closed)

Test-only change, so no version bump or CHANGELOG entry is needed.

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

…o load (#13059)

The web plugin reported a map as ready (triggering `onMapCreated`) only on the first `tilesloaded` event. That event requires every visible tile to download, so a single stalled or failed tile request leaves `onMapCreated` pending forever. On CI, this hangs `projection_test`, `overlays_test`, and `marker_clustering_test` until `flutter drive` fails with an opaque `DriverError` after 20 minutes.

Example CI failures:
- https://ci.chromium.org/b/8669392206413648801
- https://ci.chromium.org/b/8669672566864354113

- Report the map as ready on the first `tilesloaded` or the first `idle` event once the map `<div>` is attached and has a non-zero size, when the projection and bounds are available.
- Re-enable the tests skipped in #13047.

Fixes flutter/flutter#193452

This automated PR syncs the changes from the release branch release-cupertino_ui-1.1.4 back to the main branch.

#13341)

Fixes flutter/flutter#186488
Exposes the underlying `SK2Transaction` on `SK2PurchaseDetails` so callers can access fields like `originalId` and `quantity` from `purchaseStream` updates. Returns `null` when a purchase has not produced a transaction .
## Pre-Review Checklist

…r/flutter#186073) (#12863)

Ports flutter/flutter#186073 to `material_ui`, as per flutter/flutter#188444. The old PR (and tagged as `Decoupling: Port to flutter/packages`) was reviewed and approved by @QuncCccccc and @justinmc.

---

_quick recap_.

Fixes flutter/flutter#177454.

Adds a `barFocusNode` parameter to `SearchAnchor.bar` (and its internal `_SearchAnchorWithSearchBar` implementation), allowing external code to control the focus of the underlying `SearchBar`.

---

## Pre-Review Checklist

This automated PR syncs the changes from the release branch release-material_ui-1.8.0 back to the main branch.

I don't know why these analyzer issues are being reported one-at-a-time in CI on #13284 instead of all at once, but #13332 was only one of a few analyzer issues:
```
darwin/Tests/CameraSessionPresetsTests.swift:28:9: error: variable 'currentFormat' was never mutated; consider changing to 'let' constant
    var currentFormat: CaptureDeviceFormat = captureFormatMock
    ~~~ ^
    let
darwin/Tests/CameraInitRaceConditionsTests.swift:62:24: warning: immutable value '_captureSessionQueue' was never used; consider replacing with '_' or removing it [#NoUsage]
60 | 
61 |   func testFlutterChannelInitializedWhenStartingImageStream() {
62 |     let (cameraPlugin, _captureSessionQueue) = createCameraPlugin()
darwin/Tests/AvailableCamerasTests.swift:49:11: warning: variable 'requiredTypes' was never mutated; consider changing to 'let' constant [#VariableNeverMutated]
 47 |       telephotoCamera.position = .back
 48 | 
 49 |       var requiredTypes: [AVCaptureDevice.DeviceType] = [
darwin/Tests/AvailableCamerasTests.swift:52:11: warning: variable 'cameras' was never mutated; consider changing to 'let' constant [#VariableNeverMutated]
 50 |         .builtInWideAngleCamera, .builtInTelephotoCamera, .builtInUltraWideCamera,
 51 |       ]
 52 |       var cameras = [wideAngleCamera, frontFacingCamera, telephotoCamera, ultraWideCamera]
darwin/Tests/AvailableCamerasTests.swift:86:11: warning: variable 'requiredTypes' was never mutated; consider changing to 'let' constant [#VariableNeverMutated]
 84 |       frontFacingCamera.position = .front
 85 | 
 86 |       var requiredTypes: [AVCaptureDevice.DeviceType] = [
darwin/Tests/AvailableCamerasTests.swift:118:11: warning: variable 'requiredTypes' was never mutated; consider changing to 'let' constant [#VariableNeverMutated]
116 |       unspecifiedCamera.position = .unspecified
117 | 
118 |       var requiredTypes: [AVCaptureDevice.DeviceType] = [
darwin/Tests/CameraOrientationTests.swift:120:14: warning: weak variable 'weakDevice' was never mutated; consider changing to 'let' constant [#VariableNeverMutated::WeakMutability]
118 |     let captureSessionQueue = DispatchQueue(label: "capture_session_queue")
119 |     weak var weakPlugin: CameraPlugin?
120 |     weak var weakDevice = mockDevice
darwin/Tests/CameraOrientationTests.swift:157:14: warning: weak variable 'weakEventAPI' was never mutated; consider changing to 'let' constant [#VariableNeverMutated::WeakMutability]
155 |     }
156 | 
157 |     weak var weakEventAPI = mockEventAPI

```

This wasn't showing up in CI due to flutter/flutter#194517.

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

…gration tests (#13092)

Split out from #13059.

Integration tests have no default timeout, so when a map fails to initialize on CI, the test hangs until `flutter drive` gives up after 20 minutes with an opaque `DriverError` and no browser state in the log. Also, tests that construct multiple `GoogleMapController` instances reused `mapId = 33930`, which collides in `platformViewRegistry.registerViewFactory` so `controller.widget` renders the first test's `<div>`.

- Add `pumpMap` and `pumpPlatformMap` helpers that bound map creation to 30s and dump the Maps SDK / DOM `<div>` state on timeout.
- Add `getNextMapId()` so each test controller registers a unique platform view factory.
- Set a 2-minute per-test timeout in the real-map suites and a 5-minute driver timeout in `test_driver/integration_test.dart`.
- Fix `marker_clustering_test` waiting for `clusters.isNotEmpty` instead of `clusters.isEmpty` after removing all clusters.

Part of flutter/flutter#193452

This fixes a failure when running on iPhone 17. 

The reason is: 

```
case .low:
  if videoCaptureSession.canSetSessionPreset(.cif352x288) { ... break }
  fallthrough
default:
  if videoCaptureSession.canSetSessionPreset(.low) {
    videoCaptureSession.sessionPreset = .low   // size is up to the device
```

On iPhone 17, `.cif352x288` is not supported, so it falls back to `.low`, which is 480p (480x640). This actually fails even before iOS 27, but we didn't catch it because it requires hardware device. 

To prevent similar failures in the future, we shouldn't assume hardware capabilities (e.g. photo resolution). So I updated the test to verify photos in higher settings have relatively higher resolutions. 

Note that I did not change Android - I think it was as fragile as iOS and could break in the future. However, unlike iOS, the Android tests do run on real devices in our CI, so we should be able to catch any failure if that happens, so I wouldn't be concerned about it. 

*List which issues are fixed by this PR. You must list at least one issue.*
Fixes flutter/flutter#191202

## Pre-Review Checklist

- [ x I updated/added any relevant documentation (doc comments with `///`).

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

Revert part of #13294 that updated the iOS and macOS versions. Re-add the availability checks. Still fix the `SecTrustGetCertificateAtIndex` deprecation issue.
Due to Swift Package Manager issue flutter/flutter#194864, this broke plugins with dependencies targeting lower versions.

Unblocks flutter/flutter#194871

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

…release builds (#13311)

`shared_preferences_android` 2.5.0 calls its Kotlin code through JNI. The generated Dart bindings and `package:jni` look up some Kotlin standard library classes by name, but nothing keeps them, so R8 renames them in release builds. From `mapping.txt` of a release build with 2.5.0:

```
kotlin.Result -> l1.d:
kotlin.Result$Failure -> l1.c:
kotlin.Unit -> l1.g:
kotlin.coroutines.Continuation -> o1.d:
kotlin.coroutines.intrinsics.CoroutineSingletons -> p1.a:
```

The generated classes are kept by `@Keep`, but R8 rewrites their method descriptors with the renamed `Continuation`. So every call fails with a `NoSuchMethodError`, for example:

```
NoSuchMethodError: no non-static method "Lio/flutter/plugins/sharedpreferences/SharedPreferencesAsyncApiRegistrar;.getAll(Ljava/util/List;Lio/flutter/plugins/sharedpreferences/SharedPreferencesPigeonOptions;Lkotlin/coroutines/Continuation;)Ljava/lang/Object;"
```

and `SharedPreferences.getInstance()`, `SharedPreferencesAsync` and `SharedPreferencesWithCache.create()` all throw. Debug and profile builds work.

This PR adds `android/consumer-rules.pro` with the six keep rules from Pigeon's native interop guide ("Step 5: Android Release Build Configuration (JNI)") and lists it in `consumerProguardFiles`, the same way `packages/pigeon/platform_tests/test_plugin` does. R8 then applies the rules to every app that uses the plugin. The six classes are the ones looked up by name: `kotlin.coroutines.Continuation` in the descriptors of the `suspend` methods and `kotlin.Unit` in `messages*.g.dart`, plus `kotlin.Unit`, `kotlin.Result`, `kotlin.Result$Failure`, `kotlin.coroutines.Continuation`, `CoroutineSingletons` and `IntrinsicsKt` in `lib/src/kotlin.dart` of `jni` 1.1.0. The other Kotlin types in the bindings (`DefaultConstructorMarker`, `EnumEntries`) only appear in synthetic constructors and `getEntries`, which the plugin never calls. A TODO in `consumer-rules.pro` and `build.gradle.kts` points to dart-lang/native#3732, so the rules can be removed once `jni` ships them.

Fixes flutter/flutter#194649

How I verified it: a fresh `flutter create --platforms android` app with `shared_preferences: ^2.5.5` that calls `SharedPreferencesWithCache.create()` in `main()` and counts launches. I built it with `flutter build apk --release --target-platform android-arm64` (Flutter 3.44.2, AGP 9.0.1, Gradle 9.1.0, R8 on by default) and ran it on an API 37 arm64 emulator.

- With `shared_preferences_android` 2.5.0 from pub.dev, the app stays on the splash screen and logcat shows the `NoSuchMethodError` above from `SharedPreferencesWithCache.create`.
- With a `dependency_overrides` path to this branch, `configuration.txt` of the build lists the rules from the plugin's consumer file, `mapping.txt` maps each class to itself (for example `kotlin.coroutines.Continuation -> kotlin.coroutines.Continuation:`), and the app starts. It logs `launches=1`, and `launches=2` after a restart.
- A second entry point that round-trips every value type, `getKeys`, `getAll`, `remove` and `clear` through `SharedPreferencesAsync` and the legacy `SharedPreferences` API fails for both APIs with 2.5.0 and passes for both with this branch.

I also ran `flutter test` in the package (39 tests pass) and `validate --check-for-missing-changes`, `analyze`, `format`, `dart-test`, `publish-check` and `license-check` of the repo tooling for the package. None of them reported an issue.

Test exemption: I'd like to request one. The change is build configuration that only affects R8 in an app's release build, and as far as I can tell no CI target runs a release build of a plugin. `drive-examples`, the native integration tests and Firebase Test Lab use debug builds, and `android_build_all_packages` builds the all_packages app in release but doesn't run it. If there is a place where a release-mode test would fit, I'm happy to add one.

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