feat(android): ExoPlayer for Android

[Gustl22]

Description

Closes #1526

Checklist

• The title of my PR starts with a Conventional Commit prefix (fix:, feat:, refactor:,
  docs:, chore:, test:, ci: etc).
• I have read the Contributor Guide and followed the process outlined for submitting PRs.
• I have updated/added tests for ALL new/updated/fixed functionality.
• I have updated/added relevant documentation and added dartdoc comments with ///, where necessary.
• I have updated/added relevant examples in example.

Breaking Change

• Yes, this is a breaking change.
• No, this is not a breaking change.

Related Issues

Inspiration from androidx/media#310
Blocked by flutter/flutter#137040

[crimesp]

hi there i was able to get this branch running locally against an old alcatel pixi4 that was having issues playing mp3s with the mediaplayer library. Is this likely to get merged soon or does it need more work / is it safe for me to use in production please

thank you!

[Gustl22]

I have to work on a solution to support channel volumes to not break the library experience. I propose to fork the branch and use that in the meantime. This branch and also this functionality is not guaranteed to work and is not ready for the stable environment yet.

[Gustl22]

@spydon I finally had some time to wrap up the ExoPlayer implementation. But like with every new things we have some quirks coming along:

• I have not yet explored the possibility for Low latency mode in ExoPlayer, and also am not quite sure if that exists. But I also have never done any tests how much time this actually is saving in our current implementation.
• As long as we are unclear with Low latency mode in exoplayer I propose to keep the classic implementation as endorsed plugin and the audioplayers_android_exo implementation as non-endorsed. So one could easily use the exo package as described in the feature_parity_table docs, if wanted.
• As long as we haven't published audioplayers_android_exo, we cannot dynamically add it to the pubspec via the dart command (unless I have some own written script). So my plan is to currently test the example with overriding the endorsed plugin with audioplayers_android_exo, and as soon as it's released, test both implementation, by also overriding in a separate test, when the package is available.

[spydon]

@spydon I finally had some time to wrap up the ExoPlayer implementation. But like with every new things we have some quirks coming along:

• I have not yet explored the possibility for Low latency mode in ExoPlayer, and also am not quite sure if that exists. But I also have never done any tests how much time this actually is saving in our current implementation.
• As long as we are unclear with Low latency mode in exoplayer I propose to keep the classic implementation as endorsed plugin and the audioplayers_android_exo implementation as non-endorsed. So one could easily use the exo package as described in the feature_parity_table docs, if wanted.
• As long as we haven't published audioplayers_android_exo, we cannot dynamically add it to the pubspec via the dart command (unless I have some own written script). So my plan is to currently test the example with overriding the endorsed plugin with audioplayers_android_exo, and as soon as it's released, test both implementation, by also overriding in a separate test, when the package is available.

Exciting! Sounds like a great plan

[spydon]

Good job!

[spydon]

Is this duplicated from the promoted package? Is this the only one that is duplicated, otherwise maybe the promoted package could be imported and the files reused?

If it's only this one I think duplication is fine though.

[Gustl22]

Not 100% sure how this can be achieved. There are more files, which are the same, so it would be nice to have them unique.

Don't know how the files from the other package can be reused by importing them (that kind of defeats the purpose of a separate package to not be dependent on the other one). Or creating a separate kotlin package? That involes compiling and archiving and uploading it to some maven package repo(?). Pretty much effort also.

Best alternative I see: I don't know the exact outcome of this: dart-lang/pub#3298, but if symlinked files are also copied (and not referenced) during packaging, we could easily write a symlink to ensure both files are the same.

[spydon]

Oh nice, I didn't know the symlink one was finally merged!

But I guess we can do that later? Something similar needs to be done for macOS / iOS right?