New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[video_player_android] Migrate ExoPlayer to ExoPlayer-Media3 1.3.1 #6535
base: main
Are you sure you want to change the base?
Conversation
e33e5a9
to
fc005d7
Compare
fc005d7
to
76a2837
Compare
packages/video_player/video_player_android/android/build.gradle
Outdated
Show resolved
Hide resolved
packages/video_player/video_player_android/android/build.gradle
Outdated
Show resolved
Hide resolved
@@ -40,6 +42,7 @@ | |||
import java.util.List; | |||
import java.util.Map; | |||
|
|||
@OptIn(markerClass = UnstableApi.class) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
essentially this just opts in into supporting future breaking changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you leave a comment with context from that issue here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated, is it okay?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is unclear to me how these APIs are safe to use in the context of the plugin. According to https://developer.android.com/media/media3/exoplayer/migration-guide#unstableapi (emphasis added):
This library follows semantic versioning and the stable API forms the 'public' API for the purposes of the versioning rules. Therefore an API bearing this annotation is exempt from any compatibility guarantees implied by the semantic versioning rules.
If unstable APIs can change in non-major-version updates to media3
, then it is definitely not safe to use them in the plugin, because plugin clients would be subject to compilation failure due to minor updates to the underlying library.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so, no migration to media3 then (at least until there is a stable alternative for such apis?)
or am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gradle will consider all requested versions, wherever they appear in the dependency graph. Out of these versions, it will select the highest one. More information on version ordering here.
https://docs.gradle.org/current/userguide/dependency_resolution.html
In case of conflict, Gradle by default uses the newest of conflicting versions
https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stuartmorgan I think this comment is saying that gradle considers all dependencies in the scope of the app which means that versions specified in the plugin could be overridden, if there was a higher version, by dependencies the app (or another plugin) has. Which both feels like a gotcha that might exist and also not how build systems should work and is not something I was aware of before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stuartmorgan should I drop the commit with highlighting unstable apis?
what is a path forward?
to me it seems we aren't making thing worse, and this pr migrates from deprecated lib (it also contains workaround for guava 32.1.+ on gradle 6.x, which I can move into separate issue)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's much better to clearly scope the use of unstable APIs as the current commit does, if (as sounds like is the case) we are stuck with using them for now. I would also comment the annotations with a TODO pointing to an issue discussing the issue and the need to track a long term solution.
Based on the discussion above it sounds like:
- Short term, we are no worse off than before by moving forward with the migration (but @reidbaker and @camsim99 should weigh in as well) in terms of potential for the plugin to stop compiling for clients due to upstream changes.
- Long term, we need to revisit how we express dependencies in our Android plugins, to see if we can prevent optimistic updates across major versions. I'll file an issue for that.
- Long term, we need to revisit the use of unstable APIs in this plugin (the TODO).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added TODOs and created flutter/flutter#147039
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!! Left a couple of thoughts.
@@ -40,6 +42,7 @@ | |||
import java.util.List; | |||
import java.util.Map; | |||
|
|||
@OptIn(markerClass = UnstableApi.class) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you leave a comment with context from that issue here?
packages/video_player/video_player_android/android/build.gradle
Outdated
Show resolved
Hide resolved
packages/video_player/video_player_android/android/build.gradle
Outdated
Show resolved
Hide resolved
76a2837
to
5b0a1cf
Compare
222c1a3
to
a26491d
Compare
packages/video_player/video_player_android/android/build.gradle
Outdated
Show resolved
Hide resolved
a6952b6
to
eb4fd61
Compare
@@ -40,6 +42,7 @@ | |||
import java.util.List; | |||
import java.util.Map; | |||
|
|||
@OptIn(markerClass = UnstableApi.class) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's much better to clearly scope the use of unstable APIs as the current commit does, if (as sounds like is the case) we are stuck with using them for now. I would also comment the annotations with a TODO pointing to an issue discussing the issue and the need to track a long term solution.
Based on the discussion above it sounds like:
- Short term, we are no worse off than before by moving forward with the migration (but @reidbaker and @camsim99 should weigh in as well) in terms of potential for the plugin to stop compiling for clients due to upstream changes.
- Long term, we need to revisit how we express dependencies in our Android plugins, to see if we can prevent optimistic updates across major versions. I'll file an issue for that.
- Long term, we need to revisit the use of unstable APIs in this plugin (the TODO).
eb4fd61
to
6981edd
Compare
6981edd
to
1f6bcc5
Compare
I've dropped controversial workarounds since they aren't needed anymore (all_packages uses gradle 7 now) |
Per these comments I think we should probably hold this until the next |
Resolves #130272
Migrated with https://developer.android.com/media/media3/exoplayer/migration-guide#usingscript
Pre-launch Checklist
dart format
.)[shared_preferences]
pubspec.yaml
with an appropriate new version according to the [pub versioning philosophy], or this PR is [exempt from version changes].CHANGELOG.md
to add a description of the change, [following repository CHANGELOG style].///
).