SDK / exoplayer

When SsMediaSource loads Manifest, it dispatches loadCompleted event even when
the load is cancelled. This change makes sure SsMediaSource dispatch
loadCancelled event instead.

GitHub: #3754

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183241940

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183238240

Since AspectRatioFrameLayout supports zoom mode as another resize_mode,
PlayerView's resize mode xml attribute should include this as well.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183237663

Helper class to create notifications for downloads using DownloadManager.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183225948

- This gives LoadControl enough information in shouldContinueLoading
  to know whether returning false will result in a terminal non-playback
  state.
- DefaultLoadControl will always return true when returning false will
  result in a terminal non-playback state, unless the target buffer size
  is exceeded. This can help to avoid getting stuck in the case that a
  MediaPeriod is providing samples from an unexpected starting time.
- Make the terminal state actually terminal. Previously the player would
  end up in an indefinite buffering state. We now fail with an error.
- Also remove the opportunity for LoadControl implementations to livelock
  playback. No sane LoadControl should simultaneously tell the player that
  it doesn't want to load anything and that it doesn't want to start
  playback. So this change removes the opportunity and starts playback in
  EPII instead in this case.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183114797

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183102837

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183098172

Try to delay failure for as long as possible. That is, propagate
DRM session failures only after an encrypted buffer arrives or clear
sample playback without session is not allowed.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183076348

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183068548

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183065262

add support in mediacodecaudiorenderer for 24bit pcm to float

Improve raw resource data source (recreated)

Issue: #1606

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183058160

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183056883

Track the expected next ad group index so that it can be used as a fallback if
IMA does not notify the ad index via a LOADED event.

Also do some miscellaneous minor cleanup (including logging all LOG events, and
logging at debug level where appropriate).

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183048612

setBytesRemaining() doesn't work when called after closeCurrentSource()

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182999254

These parsers can be used to get a manifest which includes only the
representations identified by the given keys.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182932874

So far this wasn't possible because Robolectric's Looper and MessageQueue
implementations have multiple shortcomings:
 1. The message loop of new HandlerThreads is an not an actual loop and
    scheduled messages are executed on the thread the message is enqueued
    (not the handler thread).
 2. The scheduler used to replace the message queue is synchronizing all its
    methods. Thus, when a test attempts to add messages to a Handler from
    two different threads, it may easily run into a deadlock.
 3. The scheduler doesn't correctly emulate the order of messages as they
    would be in an actual MessageQueue:
   a. If the message is enqueued on the handler thread, it gets executed
      immediately (and not after all other messages at the same time).
   b. The list of messages is always re-sorted by time, meaning that the
      order of execution for messages at the same time is indeterminate.
 4. Robolectric's SystemClock implementation returns the current scheduler
    time of the main UI thread. So, unless this scheduler is used to add
    messages in the future, the SystemClock time never advances.

This CL adds two helper classes which extend and replace Robolectric's
ShadowLooper and ShadowMessageQueue.
 1. We intercept messages being enqueued or deleted in the message queue.
    Thus Robolectric's faulty scheduler gets never used. Instead, we keep
    a blocking priority queue of messages, sorted first by execution time
    and then by FIFO order to correctly emulate the real MessageQueue.
 2. We also keep a list of deleted messages to know which messages to ignore
    when they come up in the looper.
 3. When a new Looper is started, we override the dummy loop to an actual
    eternal while loop which waits for new messages, checks if they haven't
    been deleted, and runs the messages (similar to what Robolectric's
    MessageQueue would have done at this point).

Because we don't actually use the main UI thread in our tests, we can't rely
on the SystemClock to progress in any sensible manner. To overcome this issue,
we can use the auto-advancing FakeClock also used for the simulation tests.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182912510

This achieves two things:
1. All our tests use the same type of assertions.
2. The tests currently run as instrumentation test can be moved to
   Robolectric without changing the assertions.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182910542

Instead of DefaultBandwidthMeter, TransferListener<? super DataSource>
is used.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182785785

These were caused by two issues:
1. The FakeMediaSource can be updated with a new timeline. The setNewSourceInfo
is called from a different thread than prepareSource and both access local
variables without synchronization.
2. For multi-window playback, the FakeRenderer claims that isReady and isEnded
are both set to false if it read the end of the stream. However isReady should be
true because it is able to "render" its data until the end of the stream.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182785169

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182770109

When a loaded DASH manifest is invalid (either some periods were removed
illegally, or a manifest for a live event is stale), we will retry using 1
logic:
- Retry loading with back-off up-to a limit.
- Throw a DashManifestExpiredException() if we exceed retry limit.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182770028

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182754993

Also disable use of dummy surface for devices that require the
workaround. It's only useful in the case that we can use
setOutputSurfaceWorkaround, so if it's disabled the dummy surface
has no purpose (it actually makes things worse by consuming past
the key-frame prior to the current position, which doesn't happen
if you have no surface at all).

Issue: #3724

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182750068

This fixes a very specific case where the data read has non-cached gaps
and a read-only CDS switches to read from upstream in a gap then the
cached data is deleted. When the CDS reaches the end of the gap, it
tries to open the next source. As there is no cached data, it tries to
continue with the already opened upstream data source but as it reached
end of the gap range, the code starts looping.

Also fixes infinite lock which occurs when in the previous case CDS isn't
readonly. It locks the content while filling the gap in the cache. At the
end of the gap, as the following data is deleted it tries to lock the
content for writing but the content is already locked by itself.

The last fix is preventing removal of CachedContent entry from
CachedContentIndex while associated key is locked.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182595426

Some tests in ExoPlayerTest issue commands to the player from the test thread
while the player is actively playing media (playWhenReady=true). Due to the
indeterminate time taken to enqueue the commands on the playback thread, they
may arrive when the player already proceeded to another window or finished
playback.

To ensure the tests are always deterministic, this change pauses playback in
the tests where this may happen before issuing the commands.
Also, for tests where we need to wait for a new window before issuing the
next command, a new action is added which allows to play until a specified
position.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182535096

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182534505

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182533415

- Get handling of "stale" and "out of sync" manifests so
  they're right next to each other (to be merged)
- Move startLoadingManifest to be next to the methods that
  schedule it, and actually start loading stuff.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182530683

As soon as the seek gets acknowledged by EPII, EPI returns the actual position
from the playback info again which is set by EPII. Thus, EPII needs to update
the position to reflect the changes expected by EPI.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182515106

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182512582

- In IDLE, the button will now call a preparer. This allows
  removal of the separate retry button from the demo app.
- In ENDED, the button will seek back to the default position
  and play.
- Behavior is made consistent with LeanbackPlayerAdapter.

Issue: #3689

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182506855

When determining the next sample to load, the Mp4Extractor now takes
into account how far one stream is reading ahead of the others.
If one stream is reading ahead more than a threshold (default: 10 seconds),
the extractor continues reading the other stream even though it needs
to reload the source at a new position.

GitHub:#3481
GitHub:#3214
GitHub:#3670

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182504396

Add SAMPLE-AES-CTR, which replaces SAMPLE-AES-CENC per latest spefication: https://storage.googleapis.com/wvdocs/Widevine_DRM_HLS.pdf.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182407790

It seems good to have EventLogger available from the library.
In particular because when app developers use it and then
submit bug reports, it makes it much easier to work out what
happened. It will also allow EventLogger to be used across
our (now multiple) demo apps.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182389407

This gets rid of the manual tracking of this queue with reading, playing,
and loading period holders. Still keeping these names for queue access methods.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182378944

Also sanitize naming (PlayerView/PlayerControlView).

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182364487