1. 01 Feb, 2018 20 commits
  2. 24 Jan, 2018 14 commits
  3. 23 Jan, 2018 6 commits
    • Add filtering manifest parsers for DASH, HLS and SmoothStreaming · 8b790288
      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
      eguven committed
    • Migrate ExoPlayerTest to Robolectric. · 4671c23c
      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
      tonihei committed
    • Use Truth instead of framework asserts in all tests. · e991a801
      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
      tonihei committed
    • Generalize parameter type in DemoApplication build methods · aa1b41bf
      Instead of DefaultBandwidthMeter, TransferListener<? super DataSource>
      is used.
      
      -------------
      Created by MOE: https://github.com/google/moe
      MOE_MIGRATED_REVID=182785785
      eguven committed
    • Remove further potential flakiness from ExoPlayerTest. · 32e6cf55
      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
      tonihei committed
    • Group binarySearchFloor overloads · d8c61532
      -------------
      Created by MOE: https://github.com/google/moe
      MOE_MIGRATED_REVID=182770109
      andrewlewis committed