The longer list of targets is only necessary for backwards
compatibility with existing Kotlin code that will stop compiling
if the position of the annotation becomes 'wrong' by marking it only
TYPE_USE. Since none of these IntDefs have been released (except in
media3 alpha1) we don't need to maintain this compatibility.
Also add a comment to all the places that *do* need the longer list of
targets, in order to explain why it's there and discourage copy-pasting
when defining new IntDefs in future.
Also fix some single-element arrays to remove the array notation.
#minor-release
PiperOrigin-RevId: 426108537
This change closes an edge case when an app is connecting a controller to a session that is already playing. In such a case `MediaControllerImplBase.getContentPosition()` keeps returning the first estimation for every call until `playWhenReady` changes for the first time.
Reproduction: Launch the demo-session app and start audio playback. Put the activity to the background and then to the foreground again. Go to the playlist view and `PlayerActivity` without interrupting playback and try to seek in the timebar. The position is stuck and snaps back.
PiperOrigin-RevId: 422795360
This is a small refactoring toward merging
MediaNotificationHandler and PlayerNotificationManager
In detail, this CL includes following changes:
- Use MediaController to dispatch commands to sessions in
MediaSessionService, rather than media key events.
- Use MediaController to monitor changes in MediaSession's
underlying Player, rather than ForegroundServiceEventCallback.
Removed the callback interface as well.
PiperOrigin-RevId: 422049265
MediaController tries to release itself when the binder to the
session becomes unavailable. However, if such thing happens while
connecting in the constructor, it causes NPE when accessing
MediaControllerImpl which is only initialized after it's
connected.
This fixes random failures in existing tests.
PiperOrigin-RevId: 421423381
A session may not notify its release back to the controller
when the controller is connecting while the session is releasing.
Here are issues in detail:
- MediaSession doesn't respond to controller's connection
request when it's released.
- MediaSession discards incoming connection requests when it's
released. The requests are only kept in the application
looper, but the looper is cleared when the session is
released.
This CL fixes the above issues, and fixes some flaky tests.
PiperOrigin-RevId: 419756158
MediaController.getContentPosition() estimates the content position
based on the last position info sent by the player and the elapsed
real-time since the position info was received. After calling
MediaController's play/pause/setPlayWhenReady, the position estimation
logic is still applying, therefore advancing the position until the
underlying player's actual position is received. This can make the
MediaController's content position to be out of sync with player's
actual content position.
With this change, MediaController stops making content position
estimations after any of play/pause/setPlayWhenReady is called and
until a new position info is received from the underlying player.
Tested manually with the the session demo app, pausing/resuming content
from the UI.
PiperOrigin-RevId: 418000800
* Remove casting getInstance and getCallback methods and just
use member variables that have the more specific types. I
didn't manage to get rid of casting completely; there are
still one-off casts during construction. We should look at
removing those in the future, but it's not completely
trivial due to the way the Impl classes back-reference
their wrapping classes.
* Move all callback invocations inside the Impl classes for
consistency, and properly encapsulate the callbacks there.
Sticking with the "OnHandler" naming convention for these
methods, but we should probably tweak that in a subsequent
change.
* Encapsulate MediaItemFiller in MediaSessionImpl.
* Some misc cleanup (e.g., converting anonymous inner classes
to lambdas where possible).
PiperOrigin-RevId: 414401978
This is required for correct subscription notifications, as per the
referenced bug. It also just seems better to plumb things this way
in general, rather than re-implementing the functionality in the stub.
PiperOrigin-RevId: 413963824
This change removes the requirement that callback implementations
need to be able to handle two specific callbacks being called on
two different threads.
PiperOrigin-RevId: 413958545
SessionResult stores SystemClock.elapsedRealtime() into
this.completionTimeMs, so a statically initialized instance will have
a meaningless value.
PiperOrigin-RevId: 407865809
This commit doesn't resolve all the violations. Specifically,
INDEX_UNSET is still being incorrectly passed as various IntDef values
to the PlayerInfo constructor, but making these parameters (and the
corresponding PlayerInfo fields) @Nullable is a more involved change
(and it's not obvious at what point we can guarantee the value will be
non-null/non-INDEX_UNSET), so it's left for a later commit.
PiperOrigin-RevId: 407294091
Where this introduced an inconsistency (e.g. assigning to something
called `windowIndex`), I generally renamed the transitive closure of
identifiers to maintain consistency (meaning this change is quite
large). The exception is code that interacts with Timeline and Window
directly, where sometimes I kept the 'window' nomenclature.
#minor-release
PiperOrigin-RevId: 407040052
This allows the use of the intdef in parameterized types,
e.g. List<@MyIntDef Integer>
For IntDefs that are already released in ExoPlayer 2.15.1 we add
TYPE_USE in addition to all other reasonable targets, to maintain
backwards compatibility with Kotlin code (where an incorrectly
positioned annotation is a compilation failure). 'reasonable targets'
includes FIELD, METHOD, PARAMETER and LOCAL_VARIABLE but not TYPE,
CONSTRUCTOR, ANNOTATION_TYPE, PACKAGE or MODULE. TYPE_PARAMETER is
implied by TYPE_USE.
For not-yet-released IntDefs we just add TYPE_USE.
#minor-release
PiperOrigin-RevId: 406793413
deviceVolume (int) and volume (float) are not the same. Elsewhere
MediaControllerImplLegacy doesn't support volume and defaults to 1
(setVolume, getVolume), so defaulting to 1 here seems correct.
PiperOrigin-RevId: 406780391
These seem to be describing an exception being thrown based on a
property of the value being returned from this method? Or is the
expectation that every implementation of this interface throws the
AssertionError themselves.
Given AssertionError is unchecked, and shouldn't be explicitly caught
anywhere, it seems easiest just to remove all this documentation?
PiperOrigin-RevId: 406107606
Only deprecated references remain.
Usages of the deprecated methods will be migrated in a follow-up change.
#minor-release
PiperOrigin-RevId: 405927141
Our package-info.java files are annotated with @NonNullApi which results
in everything being non-null by default, so this annotation is never
needed.
#minor-release
PiperOrigin-RevId: 405864737
