Exoplayer needs this API for devices with timestamp issues.
Test: compiles
Bug: 112561552
Bug: 130237544
Change-Id: I136d80011765ac83be8f5258c4ba139ee1f1ef75
MediaHTTPConnection's public methods are called from multiple Binder
threads. Since both HttpURLConnection and access to the various
connection related fields is not thread safe, this CL guards most
methods by a single lock. This means that the methods can now block
when called, although this should be rare:
- there are two processes that call these methods. One process
only calls getSize(), and the other process calls methods
from a single thread (ie. at not overlapping clock times).
- should lock contention unexpectedly increase in future, then
that would be bad (because Binder thread pool threads would
be blocked/unavailable), but it would not be easy to detect.
It would be easy to detect if we could stop getSize() being
called at overlapping clock times, since we could then use
ReentrantLock.tryLock() to assert that the lock is never contended
outside of disconnect().
Because it's a requirement for disconnect() to quickly stop another
thread that is blocked in readAt(), disconnect() is the only method
that doesn't acquire the lock immediately; the mConnection field
is marked volatile so that disconnect() has a high chance of reading
that field and calling disconnect() on it without waiting for
another thread (there's a small risk that another thread might
acquire the lock and start a new connection while disconnect()
is waiting for the lock; in that case, after acquiring the lock,
disconnect() will also disconnect that new connection; this is
subject to potential change in future.
Initially, a ReentrantLock object was considered but for now this
CL instead uses the synchronized lock on "this" because:
- it minimizes churn on the lines of code in this file because
synchronized (this) { } can be expressed by introduction of
the word "synchronized" on the method header, whereas
mLock.lock(); try { ... } finally { mLock.unlock(); } would
indent all the lines in-between and thus pollute git annotate.
- some methods were already synchronized.
- ReentrantLock.tryLock() is not used for now; most of the time,
lock acquisition should be uncontended but the two cases of
lock contention mentioned above exist, which makes it difficult
to distinguish surprising from unsurprising lock contention.
While this is the case, it seems better to keep the code
simple and to just unconditionally block.
Bug: 114337214
Fixes: 114337214
Fixes: 119900000
Fixes: 129444137
Fixes: 128758794
Fixes: 63002045
Test: Checked manually that bug 114337214 no longer reproduces on
Android API level 27 (Oreo MR1) after cherrypicking this CL.
Test: Ran the following on internal master with this CL:
make cts && cts-tradefed run cts -m CtsMediaTestCases \
-t android.media.cts.NativeDecoderTest#testAMediaDataSourceClose \
--abi arm64-v8a
Test: Ran the following both on AOSP (158 tests) and internal master (178):
atest CtsMediaTestCases:android.media.cts.{MediaPlayer{,2},Routing}Test
All these tests pass except that on AOSP only, the following test
fails both before and after my CL (appears unrelated):
android.media.cts.RoutingTest#test_MediaPlayer_RoutingChangedCallback
(cherry picked from commit 8d9fccee62)
Change-Id: I4e32a58891c3ce60ddfa72d36060486d37906f8d
Merged-In: I4e32a58891c3ce60ddfa72d36060486d37906f8d
This reverts commit 621e7968ad.
Many of the fields that were moved are annotated @UnsupportedAppUsage,
so the CL would have had undesirable app compat impact. Further,
because investigation has revealed that lock contention *is* possible,
we need to always acquire the lock anyway so there is no longer a
benefit in keeping all of the mutable state in a single field that
can be atomically set to null.
Bug: 114337214
Test: Treehugger
(cherry picked from commit dc9f4b4d5d)
Change-Id: I202c5653cb086d99228491e161a159bad640105a
Merged-In: I202c5653cb086d99228491e161a159bad640105a
This reverts commit e6243996ef.
Bug: 129721367
Test: change volume in Play Music
(cherry picked from commit ab3a3f8c02)
Change-Id: Id6e63e87265717130dde0e1b46e28edbb0b53edb
The matching rule on audio attributes flags must be that ALL flags
set in the reference attributes are present in the compared attributes
and not just some flags.
Bug: 129721367
Test: change volume in Play Music
Change-Id: I462fd73fb9b78b094411c6f3b52004349f49bcf3
(cherry picked from commit 9b0bb840cd)
This reverts commit 48af5aeeba.
No idea on how this simple CL can cause this problem but A/B tests
and bisection show that the problem disabpears when reverted.
Bug: 129721367
Test: no repro on build with revert.
Change-Id: I13e3d788d255c4b6e873bb1e9ce2cf92d2a18e41
In case the apps start vibration while playing asserts containing haptic
channels, it will be safer to mute haptic channels by default. Apps will
need to explicitly enable haptic channels if they want haptic via audio.
Bug: 129544270
Test: play with/without enabling haptic channels.
Change-Id: Id35d25c2be1c0b26053389f0b277b1ce321ad29e
It used to be there to hide from API list, and since it's been addressed
in PlayerBase, this pseudo override is no longer needed.
Bug: 126702177
Test: make system-api-stubs-docs-update-current-api
Change-Id: I8caa75410d1ffb2b0e690a82396ac978b03a2844
This opens the door to the same consistent logic being shared by
anyone across the OS who wants to enforce storage permissions.
Bug: 126788266
Test: atest --test-mapping packages/apps/MediaProvider
Exempted-From-Owner-Approval: Trivial permissions refactoring
Change-Id: I3107425f8dafa6ba05918bb67c3c0cb5d3899657
Do not mute based on OP_PLAY_AUDIO client side.
Disable legacy behavior with constant without affecting
audio service logs.
Bug: 112339570
Test: enter DnD, play notifications, verify not heard
Change-Id: I8a963af02fc2b42844470a4212fec8e2f6a5e4e0
We're now enforcing the public API schema, so clients like MTP need
to query specific collections when asking for properties that are
specific to those media types.
Also refactor MediaScanner calls to go through MediaProvider, so
they can be handled by ModernMediaScanner. We no longer directly
try inserting items, and instead rely completely on the scanner.
Bug: 127625964, 122263824
Test: atest MediaProviderTests
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ic86982766606a619afafe725f9c60013a5671840
The platform media scanner has served faithfully for many years, but
it's become tedious to test and maintain, mainly due to the way it
weaves obscurely between managed and native code.
Bug: 128243527
Test: none
Change-Id: I44c5e9840acc0afde4aeaf9a44a21e0f8939b44b
Apps were previously forced to set their allowed capture policy from
either their manifest which is not flexible or from each track which is
a very fine grain but difficult when using libraries like exoplayer.
Thus add an application level policy set with AudioManager.
Test: atest android.media.cts.AudioPlaybackCaptureTest#testCaptureMediaUsage
Bug: 111453086
Change-Id: Id360f1c3f3157c60694c039e51ff16e71d8f93cd
Signed-off-by: Kevin Rocard <krocard@google.com>
For system application with the new permission CAPTURE_MEDIA_OUTPUT, or
CAPTURE_AUDIO_OUTPUT, allow to capture the audio of playing apps that
allow it.
Test: adb shell audiorecorder --target /data/file1.raw
Test: atest android.media.cts.AudioPlaybackCaptureTest
Bug: 111453086
Change-Id: I5bfca51e48992234508897c595a076d066db26b2
Signed-off-by: Kevin Rocard <krocard@google.com>
AudioAttributes can influence offload support, add them in
method to check for support
Bug: 86837964
Test: cts-tradefed run cts -m CtsMediaTestCases -t android.media.cts.AudioTrackOffloadTest#testAudioTrackOffload
Change-Id: If4037d0611ec1264d23d1779b9ac6efd9fd1244c
