…#6908)
Part of flutter/flutter#148417.
I'm working on re-landing #6456, this time without using the `ActivityAware` interface (see flutter/flutter#148417). As part of that work, I'll need to better control the `ExoPlayer` lifecycle and save/restore internal state.
These are some proposed refactors to limit how much work `VideoPlayer` is doing, so I can better understand what needs to be reset (or not) internally. Specifically, `VideoPlayer` no longer knows what an `EventChannel` or `EventSink` is, and does not need to manage the lifecycle (it stores a `private final VideoPlayerCallbacks` instead), and instead there is a `VideoPlayerCallbacks` interface that does all that.
I'm totally open to:
- Landing this as-is (+/- nits) and making minor improvements in follow-up PRs
- Making more significant changes to this PR and then landing it
- Not landing this PR at all because it doesn't follow the approach the folks who maintain the plugin prefer
Also happy to chat in VC/person about any of the changes.

…`. (#6922)
Similar to #6908, as part of flutter/flutter#148417.
I'm working on re-landing #6456, this time without using the `ActivityAware` interface (see flutter/flutter#148417). As part of that work, I'll need to better control the `ExoPlayer` lifecycle and save/restore internal state.
In this PR, I've removed the concept of the class being "initialized" or not - the only thing "initialized" means is "for a given instance of `ExoPlayer`, has received the `'initialized'` event. As a result I removed the quasi-public API that was used for testing only and replaced it with observing what the real production instance does (`Player.STATE_READY`).
After this PR, I'll likely do one more pass around the constructors - the constructor that takes an `ExoPlayer` that is marked `@VisibleForTesting` _also_ doesn't make sense once we'll support suspending/resuming video players, so it will need to get reworked (probably into taking a factory method).

…allback`. (#6982)
I'm working on re-landing #6456,
this time without using the `ActivityAware` interface (see
flutter/flutter#148417). As part of that work,
I'll need to better control the `ExoPlayer` lifecycle and save/restore
internal state.
Follows the patterns of some of the previous PRs, i.e.
- #6922
- #6908
The changes in this PR are _mostly_ tests, it was extremely difficult to
just add more tests to the already very leaky `VideoPlayer` abstraction
which had lots of `@VisibleForTesting` methods and other "holes" to
observe state. This PR removes all of that, and adds test coverage where
it was missing.
Namely it:
- Adds a new class, `VideoAsset`, that builds and configures the media
that `ExoPlayer` uses.
- Removes all "testing" state from `VidePlayer`, keeping it nearly
immutable.
- Added tests for most of the classes I've added since, which were
mostly missing.
That being said, this is a large change. I'm happy to sit down with
either of you and walk through it.
---
Opening as a draft for the moment, since there is a pubspec change
needing I want to handle first.

…`setCallback` for suspend/resume lifecycles. (#6989)
_� BLOCKED: I guess this can't land until the new API makes it into stable in a week or two?_
---
Effectively enough towards flutter/flutter#148417, but we still need to document it on flutter.dev.
This is the last _technical_ PR I'll work on towards the plugin work (assuming we don't find additional bugs/issues).
/cc @jonahwilliams @chinmaygarde @johnmccutchan.

…this time with `setCallback` for suspend/resume lifecycles. (flutter#6989)"
This reverts commit  62b4cb0 .

…ucer, this time with setCallback for suspend/resume lifecycles" (flutter#7497)"
This reverts commit  f61a98a .

…r`. (flutter#6456)
_**WIP**: We do not plan to land this PR until the next stable release (>= April 3rd 2024)_.
Work towards flutter/flutter#145930.
## Details
Migrates uses of `createSurfaceTexture` to `createSurfaceProducer`, which is intended to have no change in behavior, but _does_ change the backend rendering path, so it will require more testing (and we're also open to minor API renames or changes before it becomes stable).
## Background
Android plugins previously requested a `SurfaceTexture` from the Android embedder, and used that to produce a `Surface` to render external textures on (i.e. `video_player`).  This worked because 100% of Flutter applications on Android used OpenGLES (via our Skia backend), and `SurfaceTexture` is actually an (opaque) OpenGLES-texture.
Starting soon (roughly ~Q3, this is not a guarantee and just an estimate), Flutter on Android will start to use our new Impeller graphics backend, which on newer devices (`>= API_VERSION_28`), will default to the Vulkan, _not_ OpenGLES. In other words, `SurfaceTexture` will cease to work (it is possible, but non-trivial, to map an OpenGLES texture over to Vulkan).
After consultation with the Android team, they helped us understand that vending `SurfaceTexture` (the _consumer-side_ API) was never the right abstraction, and we should have been vending the _producer-side_ API, or `Surface` directly. The new `SurfaceProducer` API is exactly that - it generates a `Surface`, and similar to our platform view strategy, picks the "right" _consumer-side_ implementation details _for_ the user/plugin packages.
The new `SurfaceProducer` API has 2 possible rendering types (as an implementation detail):
- `SurfaceTexture`, for older OpenGLES devices, which works exactly as it does today.
- `ImageReader`, for newer OpenGLES _or_ Vulkan devices.
These are some subtle nuances in how these two APIs work differently (one example: flutter/flutter#144407), but our theory at this point is we don't expect these changes to be observed by any users, and we have other ideas if necessary.
> [!NOTE]
> These invariants are [tested on CI in `flutter/engine`](https://github.com/flutter/engine/tree/main/testing/scenario_app/android#ci-configuration).
Points of contact:
- @matanlurey or @jonahwilliams  (Flutter Engine)
- @johnmccutchan or @reidbaker  (Flutter on Android)

…flutter#6908)
Part of flutter/flutter#148417.
I'm working on re-landing flutter#6456, this time without using the `ActivityAware` interface (see flutter/flutter#148417). As part of that work, I'll need to better control the `ExoPlayer` lifecycle and save/restore internal state.
These are some proposed refactors to limit how much work `VideoPlayer` is doing, so I can better understand what needs to be reset (or not) internally. Specifically, `VideoPlayer` no longer knows what an `EventChannel` or `EventSink` is, and does not need to manage the lifecycle (it stores a `private final VideoPlayerCallbacks` instead), and instead there is a `VideoPlayerCallbacks` interface that does all that.
I'm totally open to:
- Landing this as-is (+/- nits) and making minor improvements in follow-up PRs
- Making more significant changes to this PR and then landing it
- Not landing this PR at all because it doesn't follow the approach the folks who maintain the plugin prefer
Also happy to chat in VC/person about any of the changes.

…`. (flutter#6922)
Similar to flutter#6908, as part of flutter/flutter#148417.
I'm working on re-landing flutter#6456, this time without using the `ActivityAware` interface (see flutter/flutter#148417). As part of that work, I'll need to better control the `ExoPlayer` lifecycle and save/restore internal state.
In this PR, I've removed the concept of the class being "initialized" or not - the only thing "initialized" means is "for a given instance of `ExoPlayer`, has received the `'initialized'` event. As a result I removed the quasi-public API that was used for testing only and replaced it with observing what the real production instance does (`Player.STATE_READY`).
After this PR, I'll likely do one more pass around the constructors - the constructor that takes an `ExoPlayer` that is marked `@VisibleForTesting` _also_ doesn't make sense once we'll support suspending/resuming video players, so it will need to get reworked (probably into taking a factory method).

…allback`. (flutter#6982)
I'm working on re-landing flutter#6456,
this time without using the `ActivityAware` interface (see
flutter/flutter#148417). As part of that work,
I'll need to better control the `ExoPlayer` lifecycle and save/restore
internal state.
Follows the patterns of some of the previous PRs, i.e.
- flutter#6922
- flutter#6908
The changes in this PR are _mostly_ tests, it was extremely difficult to
just add more tests to the already very leaky `VideoPlayer` abstraction
which had lots of `@VisibleForTesting` methods and other "holes" to
observe state. This PR removes all of that, and adds test coverage where
it was missing.
Namely it:
- Adds a new class, `VideoAsset`, that builds and configures the media
that `ExoPlayer` uses.
- Removes all "testing" state from `VidePlayer`, keeping it nearly
immutable.
- Added tests for most of the classes I've added since, which were
mostly missing.
That being said, this is a large change. I'm happy to sit down with
either of you and walk through it.
---
Opening as a draft for the moment, since there is a pubspec change
needing I want to handle first.

…e with `setCallback` for suspend/resume lifecycles. (flutter#6989)
_� BLOCKED: I guess this can't land until the new API makes it into stable in a week or two?_
---
Effectively enough towards flutter/flutter#148417, but we still need to document it on flutter.dev.
This is the last _technical_ PR I'll work on towards the plugin work (assuming we don't find additional bugs/issues).
/cc @jonahwilliams @chinmaygarde @johnmccutchan.

…r`. (flutter#6456)
_**WIP**: We do not plan to land this PR until the next stable release (>= April 3rd 2024)_.
Work towards flutter/flutter#145930.
## Details
Migrates uses of `createSurfaceTexture` to `createSurfaceProducer`, which is intended to have no change in behavior, but _does_ change the backend rendering path, so it will require more testing (and we're also open to minor API renames or changes before it becomes stable).
## Background
Android plugins previously requested a `SurfaceTexture` from the Android embedder, and used that to produce a `Surface` to render external textures on (i.e. `video_player`).  This worked because 100% of Flutter applications on Android used OpenGLES (via our Skia backend), and `SurfaceTexture` is actually an (opaque) OpenGLES-texture.
Starting soon (roughly ~Q3, this is not a guarantee and just an estimate), Flutter on Android will start to use our new Impeller graphics backend, which on newer devices (`>= API_VERSION_28`), will default to the Vulkan, _not_ OpenGLES. In other words, `SurfaceTexture` will cease to work (it is possible, but non-trivial, to map an OpenGLES texture over to Vulkan).
After consultation with the Android team, they helped us understand that vending `SurfaceTexture` (the _consumer-side_ API) was never the right abstraction, and we should have been vending the _producer-side_ API, or `Surface` directly. The new `SurfaceProducer` API is exactly that - it generates a `Surface`, and similar to our platform view strategy, picks the "right" _consumer-side_ implementation details _for_ the user/plugin packages.
The new `SurfaceProducer` API has 2 possible rendering types (as an implementation detail):
- `SurfaceTexture`, for older OpenGLES devices, which works exactly as it does today.
- `ImageReader`, for newer OpenGLES _or_ Vulkan devices.
These are some subtle nuances in how these two APIs work differently (one example: flutter/flutter#144407), but our theory at this point is we don't expect these changes to be observed by any users, and we have other ideas if necessary.
> [!NOTE]
> These invariants are [tested on CI in `flutter/engine`](https://github.com/flutter/engine/tree/main/testing/scenario_app/android#ci-configuration).
Points of contact:
- @matanlurey or @jonahwilliams  (Flutter Engine)
- @johnmccutchan or @reidbaker  (Flutter on Android)

…flutter#6908)
Part of flutter/flutter#148417.
I'm working on re-landing flutter#6456, this time without using the `ActivityAware` interface (see flutter/flutter#148417). As part of that work, I'll need to better control the `ExoPlayer` lifecycle and save/restore internal state.
These are some proposed refactors to limit how much work `VideoPlayer` is doing, so I can better understand what needs to be reset (or not) internally. Specifically, `VideoPlayer` no longer knows what an `EventChannel` or `EventSink` is, and does not need to manage the lifecycle (it stores a `private final VideoPlayerCallbacks` instead), and instead there is a `VideoPlayerCallbacks` interface that does all that.
I'm totally open to:
- Landing this as-is (+/- nits) and making minor improvements in follow-up PRs
- Making more significant changes to this PR and then landing it
- Not landing this PR at all because it doesn't follow the approach the folks who maintain the plugin prefer
Also happy to chat in VC/person about any of the changes.

…`. (flutter#6922)
Similar to flutter#6908, as part of flutter/flutter#148417.
I'm working on re-landing flutter#6456, this time without using the `ActivityAware` interface (see flutter/flutter#148417). As part of that work, I'll need to better control the `ExoPlayer` lifecycle and save/restore internal state.
In this PR, I've removed the concept of the class being "initialized" or not - the only thing "initialized" means is "for a given instance of `ExoPlayer`, has received the `'initialized'` event. As a result I removed the quasi-public API that was used for testing only and replaced it with observing what the real production instance does (`Player.STATE_READY`).
After this PR, I'll likely do one more pass around the constructors - the constructor that takes an `ExoPlayer` that is marked `@VisibleForTesting` _also_ doesn't make sense once we'll support suspending/resuming video players, so it will need to get reworked (probably into taking a factory method).

…allback`. (flutter#6982)
I'm working on re-landing flutter#6456,
this time without using the `ActivityAware` interface (see
flutter/flutter#148417). As part of that work,
I'll need to better control the `ExoPlayer` lifecycle and save/restore
internal state.
Follows the patterns of some of the previous PRs, i.e.
- flutter#6922
- flutter#6908
The changes in this PR are _mostly_ tests, it was extremely difficult to
just add more tests to the already very leaky `VideoPlayer` abstraction
which had lots of `@VisibleForTesting` methods and other "holes" to
observe state. This PR removes all of that, and adds test coverage where
it was missing.
Namely it:
- Adds a new class, `VideoAsset`, that builds and configures the media
that `ExoPlayer` uses.
- Removes all "testing" state from `VidePlayer`, keeping it nearly
immutable.
- Added tests for most of the classes I've added since, which were
mostly missing.
That being said, this is a large change. I'm happy to sit down with
either of you and walk through it.
---
Opening as a draft for the moment, since there is a pubspec change
needing I want to handle first.

…e with `setCallback` for suspend/resume lifecycles. (flutter#6989)
_� BLOCKED: I guess this can't land until the new API makes it into stable in a week or two?_
---
Effectively enough towards flutter/flutter#148417, but we still need to document it on flutter.dev.
This is the last _technical_ PR I'll work on towards the plugin work (assuming we don't find additional bugs/issues).
/cc @jonahwilliams @chinmaygarde @johnmccutchan.