- 26 Jan, 2023 1 commit
-
-
PiperOrigin-RevId: 504281747 (cherry picked from commit 4c1be4c7)
christosts committed
-
- 25 Jan, 2023 39 commits
-
-
This makes it implicitly clear that if the value of a getter changes due to a change in command availability then the listener will be invoked, without needing to explicitly document every command on every listener method. #minor-release PiperOrigin-RevId: 503178383 (cherry picked from commit aa23920e)
ibaker committed -
We currently only document it for the getCurrentMediaItem(), but the command was always meant to cover all information about the current media item and the position therein. To correctly hide information for controllers, we need to filter the Timeline when bundling the PlayerInfo class if only this command is available. PiperOrigin-RevId: 503098124 (cherry picked from commit 5e9c9ed2)
tonihei committed -
When bundling PlayerInfo, we remove data when the controller is not allowed to access this data via getters. We also remove data for performance reasons. In the toBundle() method, it's currently hard to make the connection between allowed commands and filtering, because the values are checked at a different place. This can be made more readable by forwarding the applicable Commands directly. The only functional fix is to filter the Timeline when sending the first PlayerInfo after a connecting a controller if the command to get the Timeline is not available. This also allows us to remove a path to filter MediaItems from Timelines as it isn't used. PiperOrigin-RevId: 502607391 (cherry picked from commit 5461d5cb)
tonihei committed -
Starting with Android 13 (API 33) an app needs to request the permission to post notifications or notifications are suppressed. This change documents this in the class level JavaDoc of the `DownloadService`. Issue: google/ExoPlayer#10884 PiperOrigin-RevId: 501346908 (cherry picked from commit 055ed774)
bachinger committed -
Starting with API 33 the POST_NOTIFICATION permission needs to be requested at runtime or the notification is not shown. Note that with an app with targetSdkVersion < 33 but on a device with API 33 the notification permission is automatically requested when the app starts for the first time. If the user does not grant the permission, requesting the permission at runtime result in an empty array of grant results. Issue: google/ExoPlayer#10884 PiperOrigin-RevId: 501320632 (cherry picked from commit 6bacbaac)
bachinger committed -
Initialising the fields as Integer and then getting a String on compute time is slow. Instead we directly initialise these fields as String. Improves the time taken in bundling PlayerInfo further to less than 200ms from ~300ms. Also modified a test to improve productive coverage. PiperOrigin-RevId: 500003935 (cherry picked from commit d49437c6)
rohks committed -
Throw a ParserException instead of a NullPointerException if the sample table (stbl) is missing a required sample description (stsd). As per the javadoc for AtomParsers.parseTrack, ParserException should be "thrown if the trak atom can't be parsed." PiperOrigin-RevId: 499522748 (cherry picked from commit bbe78b10)
Googler committed -
Did not do this optimisation for `AdPlaybackState.AdGroup` as its length is zero for `AdPlaybackState` with no ads. No need to pass default values while fetching keys, which we always set in `AdPlaybackState.AdGroup.toBundle()`. PiperOrigin-RevId: 496995048 (cherry picked from commit f2eac2df)
rohks committed -
There are two overloads of this method due to a type 'rename' from `PlayerControlView.VisibilityListener` to `PlayerView.ControllerVisibilityListener`. Currently when you call one overload it passes `null` to the other one (to clear the other listener). Unfortunately this results in it clearing itself, because it receives a null call back! This change tweaks the documentation to clarify that the 'other' listener is only cleared if you pass a non-null listener in. This solves the recursive problem, and allows the 'legacy' visibility listener to be successfully registered. Issue: androidx/media#229 #minor-release PiperOrigin-RevId: 496876397 (cherry picked from commit 37fd65a8)
ibaker committed -
Users of this class may run into these assertions when creating the State and they need to check the source code to understand why the State is invalid. Adding error messages to all our correctness assertions helps to understand the root cause more easily. PiperOrigin-RevId: 496875109 (cherry picked from commit b7e887a5)
tonihei committed -
https://developer.android.com/reference/androidx/leanback/media/PlayerAdapter#seekTo(long) #minor-release PiperOrigin-RevId: 496378709 (cherry picked from commit d2a3d8f6)
ibaker committed -
These are the remaining setter operations. They all share the same logic that handles playlist and/or position changes. The logic to create the placeholder state is mostly copied from ExoPlayerImpl's maskTimelineAndPosition and getPeriodPositonUsAfterTimelineChanged. PiperOrigin-RevId: 496364712 (cherry picked from commit 09d37641)
tonihei committed -
The tunneling callbacks are sent via Handler messages and may be handled after the codec/surface was changed or released. We already guard against the codec/surface change condition by creating a new listener and verifying that the current callback happens for the correct listener instance, but we don't guard against a released codec yet. PiperOrigin-RevId: 495882353 (cherry picked from commit 5e23b8bf)
tonihei committed -
Some Player methods operate relative to existing indices in the playlist (add,remove,move,seek). As these operations may be issued from a place with a stale playlist (e.g. a controller that sends a command while the playlist is changing), we have to handle out- of-bounds indices gracefully. In most cases this is already documented and implemented correctly. However, some cases are not documented and the existing player implementations don't handle these cases consistently (or in some cases not even correctly). PiperOrigin-RevId: 495856295 (cherry picked from commit a1c0b104)
tonihei committed -
Improves the time taken to construct `playerInfo` from its bundle from ~450 ms to ~400 ms. Each `MediaItem` inside `Timeline.Window` contains `MediaMetadata` and hence is a good candidate for bundling optimisations. There already exists a test to check all parameters for null values when unset. PiperOrigin-RevId: 495614719 (cherry picked from commit 8dea624c)
rohks committed -
This simplifies some position tracking needs for an app implementing SimpleBasePlayer. - The period index can always be derived from the media item index and the position. So there is no need to set it separately. - The media item index can be left unset in the State in case the app doesn't care about the value or wants to set it the default start index (e.g. while the playlist is still empty where UNSET is different from zero). - Similarly, we should allow to set the content position (and buffered position) to C.TIME_UNSET to let the app ignore it or indicate the default position explictly. PiperOrigin-RevId: 495352633 (cherry picked from commit 91557ac9)
tonihei committed
