1. 20 Apr, 2021 5 commits
  2. 19 Apr, 2021 9 commits
  3. 16 Apr, 2021 7 commits
    • Update release notes · 19c267b1
      PiperOrigin-RevId: 368822503
      bachinger committed
    • Make surfaceView non-clickable · 33f3e5fc
      PiperOrigin-RevId: 368818853
      olly committed
    • Refactor SEP prepare to clarify that it is equivalent to EPI prepare. · 2cc51db5
      Before this change:
      - SimpleExoPlayer.prepare(mediaSource) ended up calling
        ExoPlayerImpl.setMediaSourcesInternal() with startWindowIndex=0 and
        resetToDefaultPosition=false.
      - ExoPlayerImpl.prepare(mediaSource) ended up calling
        ExoPlayerImpl.setMediaSourcesInternal() with
        startWindowIndex=C.INDEX_UNSET and resetToDefaultPosition=true.
      
      This was functionaly equivalent but a bit confusing.
      
      #minor-release
      
      PiperOrigin-RevId: 368818143
      kimvde committed
    • Replace Util.toUpperInvariant() with Ascii.toUpperCase() · fff7b807
      Even when fixed to the US locale (and thus avoiding surprising behaviour
      in e.g. Turkish locale with "i" and "I") there are unexpected behaviours
      when upper and lower casing non-ASCII characters.
      
      For example it's sometimes not symmetric, e.g.:
      "ẞ".toLowerCase() -> "ß"
      "ß".toUpperCase() -> "SS"
      
      In all the ExoPlayer usages we are either dealing with known-ASCII
      strings (e.g. MIME types) or comparing against ASCII constant strings
      anyway, so it seems easier to just use Guava's ASCII-only class in these
      cases.
      
      Util.toUpperInvariant() is null-tolerant, while Ascii.toLowercase() is
      not. Most usages in this change are clearly non-null. The BandwidthMeter
      usages aren't annotated @Nullable, but the current code *would* work if
      countryCode was null in both cases. These methods will now throw NPE if
      they're passed null.
      
      PiperOrigin-RevId: 368816287
      ibaker committed
    • Merge pull request #8814 from dlafayet:line-height · 5511bb66
      PiperOrigin-RevId: 368803206
      Oliver Woodman committed
    • Fix typo · 66e4e47e
      PiperOrigin-RevId: 368789636
      jaewan committed
    • Add experimentalSetForegroundModeTimeoutMs on SimpleExoPlayer · b0260f7c
      This is necessary to migrate apps which are using
      ExoPlayer.Builder.experimentalSetForegroundModeTimeoutMs
      from ExoPlayerImpl to SimpleExoPlayer.
      
      PiperOrigin-RevId: 368657557
      kimvde committed
  4. 15 Apr, 2021 12 commits
    • Fix 1 ErrorProneStyle finding: · 3ab344c2
      * The Google Java Style Guide requires that each switch statement includes a default statement group, even if it contains no code. (This requirement is lifted for any switch statement that covers all values of an enum.)
        (see http://go/bugpattern/MissingDefault)
      
      This CL looks good? Just LGTM and Approve it!
      This CL doesn’t look good? This is what you can do:
      * Suggest a fix on the CL (go/how-to-suggest-fix).
      * Revert this CL, by replying "REVERT: <provide reason>"
      * File a bug under go/error-prone-bug for category ErrorProneStyle if the change looks generally problematic.
      * Revert this CL and not get a CL that cleans up these paths in the future by
      replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
      opt out the respective paths in your CL Robot configuration instead:
      go/clrobot-opt-out.
      
      This CL was generated by CL Robot - a tool that cleans up code findings
      (go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/exoplayer/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/exoplayer/METADATA.
      Anything wrong with the signup? File a bug at go/clrobot-bug.
      
      #codehealth
      
      PiperOrigin-RevId: 368586454
      olly committed
    • Update internal codebase location for av1 extension · 14e085d6
      PiperOrigin-RevId: 368585664
      andrewlewis committed
    • Tweak discontinuity reason definitions for remote players · 56899cb0
      Discontinuity reasons may not be precisely obtained for remote
      player. 'Remote Player' means that playback is owned by another
      app or device and the same playback can be controller by other
      clients simultaneously. The MediaController is an example.
      If the remote playback doesn't provide discontinuity reason, then
      player cannot differentiate between automatic playback transition
      and seekTo() from another client.
      
      This CL tweaks the discontinuity reason definitions, so reasons
      can be obtained without remote playback's support.
      This doesn't effect the local Players, such as SimpleExoPlayer.
      
      PiperOrigin-RevId: 368579577
      jaewan committed
    • Make PositionInfo Bundleable · f0d84f21
      PiperOrigin-RevId: 368453894
      jaewan committed
    • Core/UI decoupling: Replace SingleTapListener with OnClickListener · d7c71610
      PiperOrigin-RevId: 368448442
      olly committed
    • Move DeviceComponent in ExoPlayer · 54f3dfb4
      PiperOrigin-RevId: 368437660
      krocard committed
    • Move TextComponent to ExoPlayer · 5ae84ab5
      PiperOrigin-RevId: 368428647
      krocard committed
    • Core/UI decoupling: Remove SphericalGLSurfaceView cast · bd654279
      PiperOrigin-RevId: 368420961
      olly committed
    • Replace Util.toLowerInvariant() with Ascii.toLowerCase() · c50084e7
      Even when fixed to the US locale (and thus avoiding surprising behaviour
      in e.g. Turkish locale with "i" and "I") there are unexpected behaviours
      when upper and lower casing non-ASCII characters.
      
      For example it's sometimes not symmetric, e.g.:
      "ẞ".toLowerCase() -> "ß"
      "ß".toUpperCase() -> "SS"
      
      In all the ExoPlayer usages we are either dealing with known-ASCII
      strings (e.g. MIME types) or comparing against ASCII constant strings
      anyway, so it seems easier to just use Guava's ASCII-only class in these
      cases.
      
      This change also includes some null-twiddling, because
      Util.toLowerInvariant() is null tolerant, while Ascii.toLowerCase() is
      not. Most of the usages were already non-null, and it was easy enough to
      change the remaining ones to be so by simple reordering of statements.
      
      I'll make an equivalent change for Util.toUpperInvariant() next.
      
      PiperOrigin-RevId: 368419813
      ibaker committed
    • Move MetadataComponent from Player to ExoPlayer · 40d3e128
      PiperOrigin-RevId: 368418142
      krocard committed
    • Update to Gradle plugin 4.1 · f4f31273
      Some usage of += had to be changed to use .add
      because GString can be implitly converted to String
      and back, but it is not the case for List<GString>
      and List<String>.
      
      PiperOrigin-RevId: 368416727
      krocard committed
    • Move AudioComponent to ExoPlayer leaving key methods in Player · 4fc4ddbc
      PiperOrigin-RevId: 368413660
      krocard committed
  5. 14 Apr, 2021 3 commits
  6. 13 Apr, 2021 4 commits
    • Bump version to 2.13.3 · 0b3a3e6a
      PiperOrigin-RevId: 368235728
      bachinger committed
    • Upgrade JUnit to 4.13.2 · 10c3860b
      PiperOrigin-RevId: 368226576
      ibaker committed
    • Use a single message for setting video renderer outputs · 3032252f
      Previously, we had separate MSG_SET_SURFACE and
      MSG_SET_VIDEO_DECODER_OUTPUT_BUFFER_RENDERER messages for
      setting different types of supported output. Use of these
      constants to switch between outputs during use of a player
      was confusing because not all video renderers support both
      message types.
      
      To switch from VideoDecoderOutputBufferRenderer to a Surface,
      it was sufficient just to send MSG_SET_SURFACE, since all
      video renderers support this and clear any other output that
      might be set. Conversely, to switch in the opposite direction,
      just sending a MSG_SET_VIDEO_DECODER_OUTPUT_BUFFER_RENDERER was
      not sufficient, because not all video renderers handle this
      message to clear any previous output. Hence it was necessary to
      explicitly clear a previously set surface using a separate
      MSG_SET_SURFACE message. Passing two messages to switch the
      output may prevent renderers from implementing the output switch
      efficiently.
      
      This change passes all outputs using a single message type, and
      requires that all renderers treat unsupported outputs as though
      null were passed (i.e., they clear any existing output). There
      are some other miscellaneous improvements:
      
      1. Non-surface outputs are now passed to onRenderedFirstFrame.
         This fixes a bug in SimpleExoPlayer's onRenderedFirstFrame,
         where previously it could not correctly equality check the
         output corresponding to the event to its current output in
         the VideoDecoderOutputBufferRenderer case.
      2. Fix SimpleExoPlayer to report surface size changes for the
         VideoDecoderOutputBufferRenderer case. Even though the
         surface is rendered to indirectly in this case, we can still
         query (and listen to changes to) the surface's size.
      
      PiperOrigin-RevId: 368215850
      olly committed