Skip to content

SDK / exoplayer

Go to a project
Switch branch/tag
  1. 18 Apr, 2019 4 commits
  3. 16 Apr, 2019 17 commits
  5. 13 Apr, 2019 19 commits
    • Cleanly detach DownloadThreads on release · 2e3eac25 
      - Make a best effort to avoid posting MSG_DOWNLOAD_THREAD_STOPPED
  if the internal thread has already quit. Doing so is harmless,
  but causes an error in Logcat. We used to generate this warning
  quite a bit in ExoPlayerImplInternal as well, and we got quite
  a few issues filed about it, so best to avoid it if possible.
- Null out the back reference DownloadThread holds to its manager
  on release. This avoids a potential issue where a download thread
  can prevent GC of its manager if it doesn't cancel quickly.
  There's similar logic (with a similar comment) in Loader.LoadTask.

PiperOrigin-RevId: 243365143
      olly committed
    • Add HlsMetadataEntries to HlsMasterPlaylist's variants and renditions · 97acc681 
      PiperOrigin-RevId: 243304549
      aquilescanta committed
    • Finalize DownloadManager interface · b2c29da6 
      - Rename getAllDownloads to getCurrentDownloads to make it clear
  that it doesn't include completed and failed downloads
- Change getDownloadCount to isWaitingForRequirements, which is
  what it's used for. Added TODO to make it returns the right thing

PiperOrigin-RevId: 243257856
      olly committed
    • Add check for retryDelayMs==C.TIME_UNSET in DASH and SS manifest onLoadError. · c1e25f77 
      If the returned retry delay is unset, we should use a DONT_RETRY_FATAL action
instead and dispatch the event with the "canceled" flag.

PiperOrigin-RevId: 243251554
      tonihei committed
    • Move download state transitions into DownloadManager · a588717b 
      Non-trivial download state transitions are currently split across
DownloadManager and Download. These transitions are part of the
same state machine, so it's clearer if they're all in the same place
(i.e. DownloadManager, since this is the component that transitions
downloads between states).

PiperOrigin-RevId: 243249915
      olly committed
    • Reduce use of DownloadInternal in DownloadManager · f623a9de 
      The only state DownloadInternal holds is duplicate of state contained
in Download, but can confusingly be temporarily out of sync. This is
error prone because it's easy to use the wrong variable (e.g.
download.state vs state). DownloadInternals methods are called into
and call out into DownloadManager, which makes some code paths that
are quite hard to follow.

It's possible to simplify DownloadManager quite a lot by removing the
duplicated state in DownloadInternal, at which point DownloadInternal's
methods flatten into DownloadManager, which can just hold an internal
list of Downloads directly.

This is a first step, which makes it clear that DownloadThready only
needs its immutable DownloadAction + an isRemove flag.

PiperOrigin-RevId: 243245288
      olly committed
    • Add DecryptionResource to FormatHolder · bd841b18 
      PiperOrigin-RevId: 243243975
      aquilescanta committed
    • Add an HLS metadata entry sublcass to populate HLS track formats · 936bc244 
      Include information to facilitate adaptive track selection in HLS.

PiperOrigin-RevId: 243238232
      aquilescanta committed
    • Rename CryptoResource to DecryptionResource · 9cfac7ea 
      PiperOrigin-RevId: 243237265
      aquilescanta committed
    • Select non-primary tunneling decoder · 53934c13 
      Issue: #3100
Issue: #5547
PiperOrigin-RevId: 243181217
      andrewlewis committed
    • Deprecate ActionFile and simplify upgrading · b84c5143 
      PiperOrigin-RevId: 243085292
      olly committed
    • Reorder DownloadManager methods · 112117a1 
      Put methods into a more sensible order (the same order as
in the switch statement, which is a more natural order with
e.g. initialize coming first and release coming last).

PiperOrigin-RevId: 242891742
      olly committed
    • Fix stopping downloads · 9779d71a 
      - Changed startDownloads/stopDownloads back to their previous behavior
  of starting and stopping all downloads at the manager level.
- Made setManualStopReason methods for the new case of setting a manual
  stop reason or some or all downloads.
- Added plumbing to specify an initial manual stop reason when adding a
  new download, without also overwriting the manual stop reasons of all
  other preexisting downloads. Using the value is left as a TODO pending
  a bit of further cleanup that'll make it easier.

PiperOrigin-RevId: 242891688
      olly committed
    • Improve DownloadNotificationHelper · 68993f23 
      - Remove completed downloads from progress notification.
- Treat restarting as a downloading, When there are both
remove and download tasks ongoing, we prefer to show a
download notification to a remove one. A restarting task
encapsulates is basically a (remove+download) task. Given
our preference, we should treat it as a download rather
than as a removal.

PiperOrigin-RevId: 242867228
      olly committed
    • Use LoadErrorHandlingPolicy.getRetryDelayMsFor for DASH/SS manifest loads. · c830c8dc 
      Both manifest loads currently use the default retry delay although a
LoadErrorHandlingPolicy is provided to the MediaSource.

PiperOrigin-RevId: 242852672
      tonihei committed
    • Add DownloadAction merge tests · 30beb9b3 
      PiperOrigin-RevId: 242851294
      olly committed
    • Rename DownloadState to Download · 8688bd2d 
      PiperOrigin-RevId: 242839480
      eguven committed
    • Update UI translations. · f0cd144b 
      We have new strings for track role types.

PiperOrigin-RevId: 242829944
      tonihei committed
    • Simplify offline Requirements · 3f565c33 
      - Remove NETWORK_TYPE_NOT_ROAMING and NETWORK_TYPE_METERED
  because JobScheduler doesn't support them, and they're
  probably not useful to many people (data when roaming is
  normally enabled/disabled at the OS level, and restricting
  to *only* metered networks seems niche)
- Convert network requirements proper flags
- Stop persisting requirements in DownloadIndex. The direction
  we're headed to solve the manager start/stop problem is
  going to involve state in DownloadManager determining whether
  downloads actually start, and if we're doing that then it's
  no worse to do it for this as well

PiperOrigin-RevId: 242713196
      olly committed