…and avoid `SurfaceProducer` returning invalid `Surface` (#169899)

> [!NOTE]  
> For anyone reviewing this PR, see
flutter/packages#9360 for how I'd use the
`getSurface(boolean forceNewSurface)` method.

> [!NOTE]  
> For anyone coming across this PR post-landing, in the code review
process, I renamed `getSurface(boolean forceNewSurface)` to
`getForcedNewSurface()`.

### What this does
(1) Adds method `getSurface(boolean forceNewSurface)` to
`SurfaceProducer` that will force the creation of a new `Surface` when
`SurfaceProducer.getSurface()` is called.
(2) Fixes `SurfaceProducer` to avoid returning invalid `Surface`s when
`SurfaceProducer.getSurface()`/`getSurface(boolean forceNewSurface)` is
called.

### Why we should...

#### (1) Add `getSurface(boolean forceNewSurface)`

My motivation for adding this is directly tied to
#155294. The
`camera_android_camerax` plugin supports a camera preview use case that
requires providing a `Surface` to in order to render the preview. It
does so via `SurfaceProducer`; we provide a `Surface` retrieved from
`SurfaceProducer.getSurface()` to the CameraX library to render a camera
preview, and when the camera preview is done, a callback that we provide
is called, reporting that `Surface` as used and that it now should be
released/invalidated (see
[`SurfaceRequest`](https://developer.android.com/reference/androidx/camera/core/SurfaceRequest),
[`SurfaceRequest.Result`](https://developer.android.com/reference/androidx/camera/core/SurfaceRequest#provideSurface(android.view.Surface,java.util.concurrent.Executor,androidx.core.util.Consumer%3Candroidx.camera.core.SurfaceRequest.Result%3E))).
However, the CameraX library [makes no
guarantees](https://developer.android.com/reference/androidx/camera/core/Preview.SurfaceProvider#onSurfaceRequested(androidx.camera.core.SurfaceRequest):~:text=The%20camera%20may%20repeatedly%20request%20surfaces%20throughout%20usage%20of%20a%20Preview%20use%20case%2C%20but%20only%20a%20single%20request%20will%20be%20active%20at%20a%20time.)
about when requests for new `Surface`s are made, so the following race
condition can happen:

1. CameraX requests a `Surface`
2. We provide `Surface` A from `SurfaceProducer.getSurface()`
3. The camera preview was paused; CameraX requests a new `Surface`
4. The camera preview is resumed
5. We provide `Surface` A from `SurfaceProducer.getSurface()` because it
is still technically valid
6. CameraX calls our callback and now `Surface` A is released/invalid

I believe `SurfaceProducer` currently has no way to handle the level of
complexity of `Surface` handling required for use cases like the
`camera_android_camerax` camera preview, where a `Surface` may be
invalidated between calls to `SurfaceProducer.getSurface()`. So,
`getSurface(boolean forceNewSurface)` can support these use cases.*

`getSurface(boolean forceNewSurface)` simply will force
`SurfaceProducer` to return a new `Surface` when
`SurfaceProducer.getSurface` is called versus potentially returning the
same `Surface` as the previous invocation.

For `camera_android_camerax`, see
flutter/packages#9360 for an example of how it
would be used.

*I'd like to note that I also played around with creating new
`SurfaceProducer`s to solve the camera problem, which _was_ successful
and probably could be generally for that use case, but I think it's
cleaner to support this functionality from within the same
`SurfaceProducer` since we can 🤷‍♀️ It also helps avoid the user from
needing to create/manage multiple Flutter `Texture`s, from my
understanding.

#### (2) Fix `SurfaceProducer.getSurface()`/`getSurface(boolean
forceNewSurface)` to never return an invalid `Surface`s

I noticed that `SurfaceProducer.getSurface()`/`getSurface(boolean
forceNewSurface)` does not check for `Surface` validity before returning
them while I was working on (1). Honestly, this just feels right? We
should ensure that a `Surface` is valid and can be used before returning
it and potentially confusing the user.

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

<!-- 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

flutter#9360)

> [!IMPORTANT]  
> flutter/flutter#169899 must be rolled into packages in order for this fix to land.

Since timing for `Surface` requests cannot be guaranteed, request a new `Surface` from `SurfaceProducer.getSurface` each time a `Surface` is requested for rendering the camera preview to.

Fixes flutter/flutter#155294.
Fixes flutter/flutter#169506.

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

…aceRequest` (flutter/packages#9360)

flutter/packages@d9d3191...5963ecd

2025-06-24 43054281+camsim99@users.noreply.github.com
[camera_android_camerax] Force new `Surface` for each `SurfaceRequest`
(flutter/packages#9360)
2025-06-24 48065222+MsYoda@users.noreply.github.com
[google_maps_flutter_web] Fix no effect behavior of cameraTargetBounds
option on web (flutter/packages#9153)

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-packages-flutter-autoroll
Please CC flutter-ecosystem@google.com on the revert to ensure that a
human
is aware of the problem.

To file a bug in Flutter:
https://github.com/flutter/flutter/issues/new/choose

To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

…eRequest`" (#9500)

Reverts #9360

It uses an API that's not available on `stable`, breaking compilation of the plugin on `stable`.

…and avoid `SurfaceProducer` returning invalid `Surface` (flutter#169899)

> [!NOTE]  
> For anyone reviewing this PR, see
flutter/packages#9360 for how I'd use the
`getSurface(boolean forceNewSurface)` method.

> [!NOTE]  
> For anyone coming across this PR post-landing, in the code review
process, I renamed `getSurface(boolean forceNewSurface)` to
`getForcedNewSurface()`.

### What this does
(1) Adds method `getSurface(boolean forceNewSurface)` to
`SurfaceProducer` that will force the creation of a new `Surface` when
`SurfaceProducer.getSurface()` is called.
(2) Fixes `SurfaceProducer` to avoid returning invalid `Surface`s when
`SurfaceProducer.getSurface()`/`getSurface(boolean forceNewSurface)` is
called.

### Why we should...

#### (1) Add `getSurface(boolean forceNewSurface)`

My motivation for adding this is directly tied to
flutter#155294. The
`camera_android_camerax` plugin supports a camera preview use case that
requires providing a `Surface` to in order to render the preview. It
does so via `SurfaceProducer`; we provide a `Surface` retrieved from
`SurfaceProducer.getSurface()` to the CameraX library to render a camera
preview, and when the camera preview is done, a callback that we provide
is called, reporting that `Surface` as used and that it now should be
released/invalidated (see
[`SurfaceRequest`](https://developer.android.com/reference/androidx/camera/core/SurfaceRequest),
[`SurfaceRequest.Result`](https://developer.android.com/reference/androidx/camera/core/SurfaceRequest#provideSurface(android.view.Surface,java.util.concurrent.Executor,androidx.core.util.Consumer%3Candroidx.camera.core.SurfaceRequest.Result%3E))).
However, the CameraX library [makes no
guarantees](https://developer.android.com/reference/androidx/camera/core/Preview.SurfaceProvider#onSurfaceRequested(androidx.camera.core.SurfaceRequest):~:text=The%20camera%20may%20repeatedly%20request%20surfaces%20throughout%20usage%20of%20a%20Preview%20use%20case%2C%20but%20only%20a%20single%20request%20will%20be%20active%20at%20a%20time.)
about when requests for new `Surface`s are made, so the following race
condition can happen:

1. CameraX requests a `Surface`
2. We provide `Surface` A from `SurfaceProducer.getSurface()`
3. The camera preview was paused; CameraX requests a new `Surface`
4. The camera preview is resumed
5. We provide `Surface` A from `SurfaceProducer.getSurface()` because it
is still technically valid
6. CameraX calls our callback and now `Surface` A is released/invalid

I believe `SurfaceProducer` currently has no way to handle the level of
complexity of `Surface` handling required for use cases like the
`camera_android_camerax` camera preview, where a `Surface` may be
invalidated between calls to `SurfaceProducer.getSurface()`. So,
`getSurface(boolean forceNewSurface)` can support these use cases.*

`getSurface(boolean forceNewSurface)` simply will force
`SurfaceProducer` to return a new `Surface` when
`SurfaceProducer.getSurface` is called versus potentially returning the
same `Surface` as the previous invocation.

For `camera_android_camerax`, see
flutter/packages#9360 for an example of how it
would be used.

*I'd like to note that I also played around with creating new
`SurfaceProducer`s to solve the camera problem, which _was_ successful
and probably could be generally for that use case, but I think it's
cleaner to support this functionality from within the same
`SurfaceProducer` since we can 🤷‍♀️ It also helps avoid the user from
needing to create/manage multiple Flutter `Texture`s, from my
understanding.

#### (2) Fix `SurfaceProducer.getSurface()`/`getSurface(boolean
forceNewSurface)` to never return an invalid `Surface`s

I noticed that `SurfaceProducer.getSurface()`/`getSurface(boolean
forceNewSurface)` does not check for `Surface` validity before returning
them while I was working on (1). Honestly, this just feels right? We
should ensure that a `Surface` is valid and can be used before returning
it and potentially confusing the user.

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

<!-- 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

…and avoid `SurfaceProducer` returning invalid `Surface` (flutter#169899)

> [!NOTE]
> For anyone reviewing this PR, see
flutter/packages#9360 for how I'd use the
`getSurface(boolean forceNewSurface)` method.

> [!NOTE]
> For anyone coming across this PR post-landing, in the code review
process, I renamed `getSurface(boolean forceNewSurface)` to
`getForcedNewSurface()`.

(1) Adds method `getSurface(boolean forceNewSurface)` to
`SurfaceProducer` that will force the creation of a new `Surface` when
`SurfaceProducer.getSurface()` is called.
(2) Fixes `SurfaceProducer` to avoid returning invalid `Surface`s when
`SurfaceProducer.getSurface()`/`getSurface(boolean forceNewSurface)` is
called.

My motivation for adding this is directly tied to
flutter#155294. The
`camera_android_camerax` plugin supports a camera preview use case that
requires providing a `Surface` to in order to render the preview. It
does so via `SurfaceProducer`; we provide a `Surface` retrieved from
`SurfaceProducer.getSurface()` to the CameraX library to render a camera
preview, and when the camera preview is done, a callback that we provide
is called, reporting that `Surface` as used and that it now should be
released/invalidated (see
[`SurfaceRequest`](https://developer.android.com/reference/androidx/camera/core/SurfaceRequest),
[`SurfaceRequest.Result`](https://developer.android.com/reference/androidx/camera/core/SurfaceRequest#provideSurface(android.view.Surface,java.util.concurrent.Executor,androidx.core.util.Consumer%3Candroidx.camera.core.SurfaceRequest.Result%3E))).
However, the CameraX library [makes no
guarantees](https://developer.android.com/reference/androidx/camera/core/Preview.SurfaceProvider#onSurfaceRequested(androidx.camera.core.SurfaceRequest):~:text=The%20camera%20may%20repeatedly%20request%20surfaces%20throughout%20usage%20of%20a%20Preview%20use%20case%2C%20but%20only%20a%20single%20request%20will%20be%20active%20at%20a%20time.)
about when requests for new `Surface`s are made, so the following race
condition can happen:

1. CameraX requests a `Surface`
2. We provide `Surface` A from `SurfaceProducer.getSurface()`
3. The camera preview was paused; CameraX requests a new `Surface`
4. The camera preview is resumed
5. We provide `Surface` A from `SurfaceProducer.getSurface()` because it
is still technically valid
6. CameraX calls our callback and now `Surface` A is released/invalid

I believe `SurfaceProducer` currently has no way to handle the level of
complexity of `Surface` handling required for use cases like the
`camera_android_camerax` camera preview, where a `Surface` may be
invalidated between calls to `SurfaceProducer.getSurface()`. So,
`getSurface(boolean forceNewSurface)` can support these use cases.*

`getSurface(boolean forceNewSurface)` simply will force
`SurfaceProducer` to return a new `Surface` when
`SurfaceProducer.getSurface` is called versus potentially returning the
same `Surface` as the previous invocation.

For `camera_android_camerax`, see
flutter/packages#9360 for an example of how it
would be used.

*I'd like to note that I also played around with creating new
`SurfaceProducer`s to solve the camera problem, which _was_ successful
and probably could be generally for that use case, but I think it's
cleaner to support this functionality from within the same
`SurfaceProducer` since we can 🤷‍♀️ It also helps avoid the user from
needing to create/manage multiple Flutter `Texture`s, from my
understanding.

forceNewSurface)` to never return an invalid `Surface`s

I noticed that `SurfaceProducer.getSurface()`/`getSurface(boolean
forceNewSurface)` does not check for `Surface` validity before returning
them while I was working on (1). Honestly, this just feels right? We
should ensure that a `Surface` is valid and can be used before returning
it and potentially confusing the user.

- [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].

<!-- 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

…and avoid `SurfaceProducer` returning invalid `Surface` (flutter#169899)

> [!NOTE]  
> For anyone reviewing this PR, see
flutter/packages#9360 for how I'd use the
`getSurface(boolean forceNewSurface)` method.

> [!NOTE]  
> For anyone coming across this PR post-landing, in the code review
process, I renamed `getSurface(boolean forceNewSurface)` to
`getForcedNewSurface()`.

### What this does
(1) Adds method `getSurface(boolean forceNewSurface)` to
`SurfaceProducer` that will force the creation of a new `Surface` when
`SurfaceProducer.getSurface()` is called.
(2) Fixes `SurfaceProducer` to avoid returning invalid `Surface`s when
`SurfaceProducer.getSurface()`/`getSurface(boolean forceNewSurface)` is
called.

### Why we should...

#### (1) Add `getSurface(boolean forceNewSurface)`

My motivation for adding this is directly tied to
flutter#155294. The
`camera_android_camerax` plugin supports a camera preview use case that
requires providing a `Surface` to in order to render the preview. It
does so via `SurfaceProducer`; we provide a `Surface` retrieved from
`SurfaceProducer.getSurface()` to the CameraX library to render a camera
preview, and when the camera preview is done, a callback that we provide
is called, reporting that `Surface` as used and that it now should be
released/invalidated (see
[`SurfaceRequest`](https://developer.android.com/reference/androidx/camera/core/SurfaceRequest),
[`SurfaceRequest.Result`](https://developer.android.com/reference/androidx/camera/core/SurfaceRequest#provideSurface(android.view.Surface,java.util.concurrent.Executor,androidx.core.util.Consumer%3Candroidx.camera.core.SurfaceRequest.Result%3E))).
However, the CameraX library [makes no
guarantees](https://developer.android.com/reference/androidx/camera/core/Preview.SurfaceProvider#onSurfaceRequested(androidx.camera.core.SurfaceRequest):~:text=The%20camera%20may%20repeatedly%20request%20surfaces%20throughout%20usage%20of%20a%20Preview%20use%20case%2C%20but%20only%20a%20single%20request%20will%20be%20active%20at%20a%20time.)
about when requests for new `Surface`s are made, so the following race
condition can happen:

1. CameraX requests a `Surface`
2. We provide `Surface` A from `SurfaceProducer.getSurface()`
3. The camera preview was paused; CameraX requests a new `Surface`
4. The camera preview is resumed
5. We provide `Surface` A from `SurfaceProducer.getSurface()` because it
is still technically valid
6. CameraX calls our callback and now `Surface` A is released/invalid

I believe `SurfaceProducer` currently has no way to handle the level of
complexity of `Surface` handling required for use cases like the
`camera_android_camerax` camera preview, where a `Surface` may be
invalidated between calls to `SurfaceProducer.getSurface()`. So,
`getSurface(boolean forceNewSurface)` can support these use cases.*

`getSurface(boolean forceNewSurface)` simply will force
`SurfaceProducer` to return a new `Surface` when
`SurfaceProducer.getSurface` is called versus potentially returning the
same `Surface` as the previous invocation.

For `camera_android_camerax`, see
flutter/packages#9360 for an example of how it
would be used.

*I'd like to note that I also played around with creating new
`SurfaceProducer`s to solve the camera problem, which _was_ successful
and probably could be generally for that use case, but I think it's
cleaner to support this functionality from within the same
`SurfaceProducer` since we can 🤷‍♀️ It also helps avoid the user from
needing to create/manage multiple Flutter `Texture`s, from my
understanding.

#### (2) Fix `SurfaceProducer.getSurface()`/`getSurface(boolean
forceNewSurface)` to never return an invalid `Surface`s

I noticed that `SurfaceProducer.getSurface()`/`getSurface(boolean
forceNewSurface)` does not check for `Surface` validity before returning
them while I was working on (1). Honestly, this just feels right? We
should ensure that a `Surface` is valid and can be used before returning
it and potentially confusing the user.

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

<!-- 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

…r#171163)

flutter/packages@d9d3191...5963ecd

2025-06-24 43054281+camsim99@users.noreply.github.com
[camera_android_camerax] Force new `Surface` for each `SurfaceRequest`
(flutter/packages#9360)
2025-06-24 48065222+MsYoda@users.noreply.github.com
[google_maps_flutter_web] Fix no effect behavior of cameraTargetBounds
option on web (flutter/packages#9153)

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-packages-flutter-autoroll
Please CC flutter-ecosystem@google.com on the revert to ensure that a
human
is aware of the problem.

To file a bug in Flutter:
https://github.com/flutter/flutter/issues/new/choose

To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

…er` … (#172384)

Cherry-picks c7362b4 to 3.32 stable **without** the changes to the pre-existing `SurfaceProducer.getSurface` method, only the addition of `SurfaceProducer.getForcedNewSurface`.

Note that this change is already present in the 3.35 beta.

### Issue Link:
What is the link to the issue this cherry-pick is addressing?
#155294, #169506

### Changelog Description:
Adds a new method for requesting a new surface from the embedder than any previously returned.

### Impact Description:
Developers using `SurfaceProducer.getForcedNewSurface` will receive a `Surface` that is different than previous calls to `SurfaceProducer.getForcedNewSurface` or pre-existing method  `SurfaceProducer.getSurface`.

In other words, there is no impact to current users. This is a new method, so there will be a gap between 3.32.0 and 3.32.8, but I think it's worth landing because this would unblock fixing resuming/pausing the camera preview as described by the linked issues.

### Workaround:

Working around the need for the new `getForcedSurface` method (like the `camera` issues linked above require) can be done by creating new `SurfaceProducer`s; however, this might have other side-effect unbeknownst to me.

### Risk:

### Test Coverage:
Are you confident that your fix is well-tested by automated tests?

### Validation Steps:

You can test with flutter/packages#9360 (which I accidentally landed because I forgot this wasn't in stable yet...oops).

flutter#9360)

> [!IMPORTANT]  
> flutter/flutter#169899 must be rolled into packages in order for this fix to land.

Since timing for `Surface` requests cannot be guaranteed, request a new `Surface` from `SurfaceProducer.getSurface` each time a `Surface` is requested for rendering the camera preview to.

Fixes flutter/flutter#155294.
Fixes flutter/flutter#169506.

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

…eRequest`" (flutter#9500)

Reverts flutter#9360

It uses an API that's not available on `stable`, breaking compilation of the plugin on `stable`.

…equest" (#9760)

> [!IMPORTANT]  
> **(DONE ✅ in flutter/flutter#172384
> flutter/flutter#169899 must be rolled into packages AND be in Flutter stable for this to land. I will try to cherry-pick this change into 3.32 stable once the 3.35 beta is cut.

> [!NOTE]
> Several files are not changed but simply formatted as a result of the bumped Flutter/Dart versions for `camera_android_camerax` that include flutter/flutter#171703. I will comment on these files for clarity.

Re-lands #9360.

Since timing for `Surface` requests cannot be guaranteed, request a new `Surface` from `SurfaceProducer.getSurface` each time a `Surface` is requested for rendering the camera preview to.

Fixes flutter/flutter#155294.
Fixes flutter/flutter#169506.

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