Add TIF API for getting encryption status of each tracks in order for
TV App to use it.
Test: build
Bug: 112835103
Change-Id: I3065358d20d17c688e3349140b44d443fc34965d
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.
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
Change-Id: 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.
Test: Treehugger
Change-Id: I202c5653cb086d99228491e161a159bad640105a
For packages:
android.database
android.hardware.display
android.hardware.input
android.hardware.location
android.location
android.media
android.media.projection
android.media.tv
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Merged-In: I570c08292f8a9f512c96f9dce13f5337718f112c
Change-Id: I1d6c60fcb53f404d5775163bf6929395921f5a45
This change adds support for privileged apps with the MODIFY_PHONE_STATE
permission to mute the bluetooth sco stream using the adjustStreamVolume
method.
The change adds specific handling for BLUETOOTH_SCO as a mutable stream.
Bug: 111195322
Test: Mute works by AudioManager.adjustStreamVolume
(STREAM_BLUETOOTH_SCO, ADJUST_MUTE, 0)
Change-Id: I932f9e152e9b6df93a749b083a7bcc7e08c2ad70
Members modified herein are suspected to be false positives: i.e. things
that were added to the greylist in P, but subsequent data analysis
suggests that they are not, in fact, used after all.
Add a maxTargetSdk=P to these APIs. This is lower-risk that simply
removing these things from the greylist, as none of out data sources are
perfect nor complete.
For APIs that are not supported yet by annotations, move them to
hiddenapi-greylist-max-p.txt instead which has the same effect.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: Ia937d8c41512e7f1b6e7f67b9104c1878b5cc3a0
Merged-In: I020a9c09672ebcae64c5357abc4993e07e744687
Everything that is marked SystemApi or TestApi, but not @hide is still
part of the public SDK, it is therefore not sound to have that combination.
In the future, specifing such a combination will be considered an error
to prevent inadvertently exposing SystemApi and TestApi as public API.
Bug: 115333477
Change-Id: Ibd5d6a22862fdbc1e20a1cb3925280f5a682edea
Merged-In: Ibd5d6a22862fdbc1e20a1cb3925280f5a682edea
Test: METALAVA_PREPEND_ARGS="--error UnhiddenSystemApi" m checkapi
Exempt-From-Owner-Approval: API cleanup
available() bytes is counted after the last read position,
after the seek to new position, size should be compared
with the avaliable directly (without adding position).
bug: 120086693
test: Open .heic files in Downloads/Photos that's either
very small (b/117625929, b/111897855), or with the meta
at the very end (b/120086693). There shouldn't be error
in ExifInterface.
Change-Id: I37ac57823b26f03bb0ba555ee6213cf999942d21
The libnativehelper ScopedBytes class is being deprecated. It's use in
android_media_AudioTrack.cpp is unnecessary because the JNI method
takes a direct buffer as an argument whereas ScopedBytes classes exist
to mask the difference between byte arrays and byte buffers.
Bug: 119840313
Test: m -j32
Change-Id: I2a6478dbaa861c5391cc298871df0f8cd1f1439c
SD card after you set SD as internel phone storage
This JE is happening due to null pointer access in makeEntryFor() in
MediaScanner.Java.
Before accessing the cursor, check if cursor is available and not null.
It is a safe check.
Bug: 119392250
Test: manual, ran test 20 times and it passed every times.
Change-Id: I23039281b63a0a6a411860eb5989cf20a5663c8f
Add new keys for sample rate and bits per sample.
This makes it possible to indicate the specification of
the music files on application.
Bug: 112986969
Test: Check if sample rate and bits per sample can be retrieved
Change-Id: Ie5a90800297a0a7c2dd6f3a2bdf9e88c9221bee1
Add keys to retrieve color standard, color transfer and color range from
MediaMetadataRetriever.
Bug: 114329709
Test: put hdr/non-hdr contents and check media db
Change-Id: Ifa90f12a572b330f87acd6ef06e1e83ddceb8483
Add keys for color aspects to VideoColumns in MediaStore.
And standard, transfer and range is stored to database.
Bug: 114329709
Test: put hdr/non-hdr contents and check media db
Change-Id: Id4bf27a35720f5cf5a60f08eb3f30314e1a1a167
