Update RecordActivityMonitor to use events sent from clients
about their recording activity and coalesce them with
configuration update events sent from audioserver (APM). This
allows providing a high-level view on the recording
configurations consistent with client expectations.
For recorders that are managed entrirely on the server side
(AAudio MMAP) all events do contain configs. These recorders
do not have an associated death handler and need to be cleared
on audioserver restart.
Clearing client-managed trackers on audioserver restart is not
needed anymore. Clients will either continue
recording (AudioRecord handles IAudioRecord re-instantation) or
stop recording and notify AudioService about that.
Bug: 123312504
Test: android.media.cts.AudioRecordingConfigurationTest
AudioRecordTest#testAudioRecordInfoCallback
MediaRecorderTest#testAudioRecordInfoCallback
manual testing using Oboe and Solo test apps
Change-Id: I4718f983c2d90e9c3e7480719a24bd187df7f80a
A regression was introduced by commit @6d69bde which caused a new
Builder instance to be created when using setLegacyStreamType(),
instead of returning the current one.
Bug: 130274354
Test: atest android.media.cts.AudioAttributesTest#testSetLegacyStreamOnBuilder
Change-Id: Ib66a0beb5f0f4489a6003cb9be6b8313b3318eac
The MediaStore.VOLUME_EXTERNAL volume is a merged view of all storage
devices, and clients working on a specific volume need to focus on
the volume they're interested in.
Bug: 129840030
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: I91cee6a96d7f9360e6a93a9a3c389b097b6b9967
For get/set APIs, FLAG_MUTE_HAPTIC is known as a boolean value instead
of a flag. In that case, it should not be changed when calling set flags
API to modify the flags. By doing this, it helps the FLAG_MUTE_HAPTIC is
set correctly.
Bug: 130670988
Test: Manually
Change-Id: I6a507d1f6f82e5ea6520f83279f73f851605c93f
Offload support check now supports passing AudioAttributes.
Do not require AudioTrack usage to be USAGE_MEDIA, check of use
case will be done in AudioSystem.isOffloadSupported().
Bug: 129133576
Test: use offload for USAGE_ASSISTANT
Change-Id: I00065fb936600cfcdf29bc019173699db7ec5a2f
Unfortunately AudioMixingRule being in a different package,
some of its members had to be made public @hide to be used
by AudioPlaybackCaptureConfiguration.
Bug: 129948989
Test: atest AudioAttributesTest
Change-Id: Ie8cdf67aee9ff7cf9144a66d47c301712516cf87
Signed-off-by: Kevin Rocard <krocard@google.com>
Add test api to check if a dynamic audio policy is already registered
Bug: 129708340
Test: atest AudioPolicyTest
Change-Id: Id9709e16d775f9552eccb52f60584588c320d9f0
Remove AudioPolicy.Builder.setIsTestFocusPolicy from system API
definitions.
Add the required AudioPolicy-related methods to test API, along
with the test-only AudioPolicy.Builder.setIsTestFocusPolicy
method
Bug: 130225439
Test: gts-tradefed run gts -m GtsGmscoreHostTestCases -t 'com.google.android.gts.audiopolicy.AudioPolicyHostTest#testFocusPolicy'
Change-Id: I14f52bdc33b7a342f21e664104718b40f4b8a932
For now the value is stored in AudioManager. It needs to be moved
in AudioService.
Bug: 129948989
Test: atest AudioAttributesTest
Change-Id: I7f3ef4c9dbeb00169374efcc5829666c0e8121d5
Signed-off-by: Kevin Rocard <krocard@google.com>
- Removed AudioProductStrategies and updated usages to work with
List<AudioProductStrategy>
- ditributed looping logic to the respective callers
Test: built successfully with make and ran on device
Bug: 129265140
Change-Id: If95ba9c2418a1fda29590ca1af2d04e7395c2130
Rename as setHapticChannelsMuted to keep symmetrical with the query API.
Test: make
Bug: 130247632
Change-Id: I5e32e414bd6e11f651e212347a883af4e08d8863
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)
