Let the audioserver record metrics with media.metrics service.
This is for 'audiopolicy' metrics.
Bug: 78595399
Test: record from different apps, see records in 'dumpsys media.metrics'
Change-Id: Ie5c403d0e5ac8c6d614db5e7b700611ddd6d07e9
Merged-In: I63f9d4ad2d2b08eb98a49b8de5f86b6797ba2995
Values of the following properties are set by SoC vendors on some
devices including Pixels.
- persist.bluetooth.a2dp_offload.cap
- persist.bluetooth.a2dp_offload.enable
- persist.vendor.bluetooth.a2dp_offload.enable
- ro.bt.bdaddr_path
- wlan.driver.status
So they should be whitelisted for compatibility.
Bug: 77633703
Test: succeeded building and tested with Pixels
Change-Id: Ib2b81bcc1fd70ddd571dc7fb2b923b576d62b7d5
Provide read/write access to audioserver for Bluetooth
properties used with A2DP offload.
Bug: 68824150
Test: Manual; TestTracker/148125
Change-Id: I40c932d085ac55bc45e6654f966b2c9d244263d0
(cherry picked from commit 041049bc7a)
Now that Bluetooth supports delay reporting, audioserver needs
access to Bluetooth Properties in order to determine whether the
feature is enabled or disabled.
Bug: 32755225
Test: Enable the property and see that there was no error accessing it
Change-Id: I519d49deb2df4efb3cc2cce9c6d497db18b50c13
If a UID is in an idle state we don't allow recording to protect
user's privacy. If the UID is in an idle state we allow recording
but report empty data (all zeros in the byte array) and once
the process goes in an active state we report the real mic data.
This avoids the race between the app being notified aboout its
lifecycle and the audio system being notified about the state
of a UID.
Test: Added - AudioRecordTest#testRecordNoDataForIdleUids
Passing - cts-tradefed run cts-dev -m CtsMediaTestCases
-t android.media.cts.AudioRecordTest
bug:63938985
Change-Id: I8c044e588bac4182efcdc08197925fddf593a717
Audioserver loads A2DP module directly. The A2DP module
talks to the bluetooth server.
Bug: 37640821
Test: Play Music over BT headset
Change-Id: Ie6233e52a3773b636a81234b73e5e64cfbff458e
Bug: 37504387
Test: aaudio example write_sine, needs MMAP support
Change-Id: I7fbd87ad4803e8edbde4ba79220cb5c0bd6e85a0
Signed-off-by: Phil Burk <philburk@google.com>
audioserver uses an always-passthrough Allocator HAL (ashmem / mapper)
whose .so is loaded from /system/lib64/hw.
Test: Modify hal_client_domain macro to not associate client of X HAL
with hal_x attribute. Play Google Play Movies move -- no denials
and AV playback works.
Bug: 37160141
Change-Id: I7b88b222aba5361a6c7f0f6bb89705503255a4b1
This change associates all domains which are clients of Allocator HAL
with hal_allocator_client and the, required for all HAL client
domains, halclientdomain.
This enables this commit to remove the now unnecessary hwallocator_use
macro because its binder_call(..., hal_allocator_server) is covered by
binder_call(hal_allocator_client, hal_allocator_server) added in this
commit.
Unfortunately apps, except isolated app, are clients of Allocator HAL
as well. This makes it hard to use the hal_client_domain(...,
hal_allocator) macro because it translates into "typeattribute" which
currently does not support being provided with a set of types, such as
{ appdomain -isolated_app }. As a workaround, hopefully until
typeattribute is improved, this commit expresses the necessary
association operation in CIL. private/technical_debt.cil introduced by
this commit is appended into the platform policy CIL file, thus
ensuring that the hack has effect on the final monolithic policy.
P. S. This change also removes Allocator HAL access from isolated_app.
Isolated app shouldn't have access to this HAL anyway.
Test: Google Play Music plays back radios
Test: Google Camera records video with sound and that video is then
successfully played back with sound
Test: YouTube app plays back clips with sound
Test: YouTube in Chrome plays back clips with sound
Bug: 34170079
Change-Id: Id00bba6fde83e7cf04fb58bc1c353c2f66333f92
On PRODUCT_FULL_TREBLE devices, non-vendor domains (except vendor
apps) are not permitted to use Binder. This commit thus:
* groups non-vendor domains using the new "coredomain" attribute,
* adds neverallow rules restricting Binder use to coredomain and
appdomain only, and
* temporarily exempts the domains which are currently violating this
rule from this restriction. These domains are grouped using the new
"binder_in_vendor_violators" attribute. The attribute is needed
because the types corresponding to violators are not exposed to the
public policy where the neverallow rules are.
Test: mmm system/sepolicy
Test: Device boots, no new denials
Test: In Chrome, navigate to ip6.me, play a YouTube video
Test: YouTube: play a video
Test: Netflix: play a movie
Test: Google Camera: take a photo, take an HDR+ photo, record video with
sound, record slow motion video with sound. Confirm videos play
back fine and with sound.
Bug: 35870313
Change-Id: I0cd1a80b60bcbde358ce0f7a47b90f4435a45c95
This starts the switch for HAL policy to the approach where:
* domains which are clients of Foo HAL are associated with
hal_foo_client attribute,
* domains which offer the Foo HAL service over HwBinder are
associated with hal_foo_server attribute,
* policy needed by the implementation of Foo HAL service is written
against the hal_foo attribute. This policy is granted to domains
which offer the Foo HAL service over HwBinder and, if Foo HAL runs
in the so-called passthrough mode (inside the process of each
client), also granted to all domains which are clients of Foo HAL.
hal_foo is there to avoid duplicating the rules for hal_foo_client
and hal_foo_server to cover the passthrough/in-process Foo HAL and
binderized/out-of-process Foo HAL cases.
A benefit of associating all domains which are clients of Foo HAL with
hal_foo (when Foo HAL is in passthrough mode) is that this removes the
need for device-specific policy to be able to reference these domains
directly (in order to add device-specific allow rules). Instead,
device-specific policy only needs to reference hal_foo and should no
longer need to care which particular domains on the device are clients
of Foo HAL. This can be seen in simplification of the rules for
audioserver domain which is a client of Audio HAL whose policy is
being restructured in this commit.
This commit uses Audio HAL as an example to illustrate the approach.
Once this commit lands, other HALs will also be switched to this
approach.
Test: Google Play Music plays back radios
Test: Google Camera records video with sound and that video is then
successfully played back with sound
Test: YouTube app plays back clips with sound
Test: YouTube in Chrome plays back clips with sound
Bug: 34170079
Change-Id: I2597a046753edef06123f0476c2ee6889fc17f20
This leaves only the existence of audioserver domain as public API.
All other rules are implementation details of this domain's policy
and are thus now private.
Test: No change to policy according to sesearch, except for
disappearance of all allow rules to do with audioserver_current
except those created by other domains' allow rules referencing
audioserver domain from public and vendor policies.
Bug: 31364497
Change-Id: I6662394d8318781de6e3b0c125435b66581363af
Divide policy into public and private components. This is the first
step in splitting the policy creation for platform and non-platform
policies. The policy in the public directory will be exported for use
in non-platform policy creation. Backwards compatibility with it will
be achieved by converting the exported policy into attribute-based
policy when included as part of the non-platform policy and a mapping
file will be maintained to be included with the platform policy that
maps exported attributes of previous versions to the current platform
version.
Eventually we would like to create a clear interface between the
platform and non-platform device components so that the exported policy,
and the need for attributes is minimal. For now, almost all types and
avrules are left in public.
Test: Tested by building policy and running on device.
Change-Id: Idef796c9ec169259787c3f9d8f423edf4ce27f8c
