setSampleRate, setChannelMask, setFormat
may not be implemented by the HAL, although this is not documented in
the HAL API.
Currently the VTS test requires their implementation if the respective
getSupported{SampleRate,ChannelMask,Format} are supported.
Relax this requirement as the framework never calls those setters.
Note that the optionality of those functions will be documented
in the next HAL API version.
Test: vts-tradefed run commandAndExit vts --module VtsHalAudioV2_0Target -t CheckConfig.audioPolicyConfigurationValidation
Bug: 69811500
Change-Id: I3a390ae925cabd99e7f1ed4a627e71ad87b1b437
Signed-off-by: Kevin Rocard <krocard@google.com>
getSupportedSampleRate should return the native sampling rates,
(IE. the sampling rates that can be played without resampling)
but other sampling rates can be supported by the HAL.
The test was too strict as it was failing if HALs were supporting more
sample rates than there native (optimized) ones.
For example, a HAL might have its best performance (no resampling)
on 48kHz but still support 16kHz through resampling.
Note: getSupportedSampleRate might be renamed to getNativeSampleRate in
the next major HAL revision to avoid ambiguity.
Test: vts-tradefed run commandAndExit vts --module VtsHalAudioV2_0Target -t CheckConfig.audioPolicyConfigurationValidation
Bug: 69811500
Change-Id: I1ec1ce422bc5039637463c6641060508f4ee892b
Signed-off-by: Kevin Rocard <krocard@google.com>
The new HAL is a cleanup of 1.x branch of the legacy burden:
* structure flattened (multi-level factory removed);
* only one hardware tuner per HAL instance, only one session;
* front-end app doesn't control region settings anymore;
* metadata limited to int and string values;
* removed deprecated methods;
* result codes redefined.
It also fixes minor mistakes made with HAL 1.1:
* ProgramSelector simplified;
* there is no need to control background scan.
There are three features missing compared to the HAL 1.1, as they
are in development with the new design (see design docs attached):
* Announcements - b/68045105
* Program list - b/69860743
* Region handling - b/69958423
Test: VTS
Bug: b/69958777
Change-Id: I0ad83f25630c1250d73dc3941144d345339fbde0
Replace hand-written types.hal with one autogenerated from the
metadata definitions, like the SDK, NDK, and camera_metadata C library
definitions are.
No changes to actual definitions; only formatting changes and basic
documentation of each entry are added.
Add the new hash of camera.metadata@3.2::types to current.txt.
Bug: 33262893
Test: Manual inspection of new vs. old types.hal, builds, hidl-doc output
is acceptable
Change-Id: Idd8c228359e45de3609bc16ac19e878b0ed0a557
This constraint was added due to an incorrect assumption
that device ports were identified by names whereas
they are by the (module,type,address) triplet.
Bug: 69442986
Test: xmllint validates an XML with two identically named devices in
different modules.
Test: vts-tradefed run commandAndExit vts --module VtsHalAudioV2_0Target -t CheckConfig.audioPolicyConfigurationValidation
Change-Id: I66d890d3c967bead4f2a287202c259009217996a
Signed-off-by: Kevin Rocard <krocard@google.com>
Device port are not identified by names but by their type and address
and the module they are in.
As a result, enforce this constraint in the XSD. Violating it results in
a policy parsing crash.
Bug: 69442986
Test: xmllint invalidates an XML with two devices of the same type
and address
Test: vts-tradefed run commandAndExit vts --module VtsHalAudioV2_0Target -t CheckConfig.audioPolicyConfigurationValidation
Change-Id: I84245f0fa80fef786a002c98073c166b6aaf2be4
Signed-off-by: Kevin Rocard <krocard@google.com>
Vendor are currently not allowed to extend the XML format.
As some enumeration are allowed to be extended, this mean that
the format must allow some extension mechanism.
This patch relaxes the definition of the module name field.
AOSP names are still allowed, but a vendor can add its own name
if prefixed with "vx_". Eg:
<module name="vx_google_vr" halVersion="3.0">
Test: xmllint --xinclude --noout --schema hardware/interfaces/audio/2.0/config/audio_policy_configuration.xsd audio_policy_configuration.xml
with audio_policy_configuration.xml containing a module named vx_google_vr
Test: vts-tradefed run commandAndExit vts --module VtsHalAudioV2_0Target -t CheckConfig.audioPolicyConfigurationValidation
on Pixel 2
Bug: 69442986
Signed-off-by: Kevin Rocard <krocard@google.com>
Change-Id: I4ead38535cce89bb8fe44cf23fa1146acd1271d6
Motivation:
1) Support running the test against each hal service instance for the
registered hal.
2) Support testability checker to determine whether we should run the
test on the taget device.
3) Help to determine the process we want to profile for coverage data
if running on coverage build.
Bug: 64203181
Test: make vts
vts-tradefed run vts -m VtsHalBootV1_0Target
vts-tradefed run vts -m VtsHalMemtrackV1_0Target
vts-tradefed run vts -m VtsHalPowerV1_0Target
vts-tradefed run vts -m VtsHalPowerV1_1Target
Change-Id: Ie0bbd9ef9d9fbe11de5aee70fad9028fa0ae897c
Use the top level clang-format setup by the HIDL team to format the
entire implementation.
clang-format -i --style file wifi/1.2/default/*
Bug: 32287573
Test: Compiles
Change-Id: I336c21fd9bfdc560117aa7212f92ab5f01df4b8e
Add support for concurrent interfaces in the WifiLegacyHal class:
a) Removed the hardcoded "wlan0" interface handle in WifiLegacyHal.
b) Modified all the interface specific functions to accept the |iface_name|
argument on which the operation needs to be performed.
Each IWifiIface object will hold the name of the underlying network
interface (wlan0, wlan1 or p2p0) which it is representing.
All IWifiChip operations which needs an iface name will continue to use
the default "wlan0".
Bug: 65671875
Test: Device boots up and connects to wifi networks.
Test: Will send for regression tests.
Change-Id: I9bd9c2a9ba33ac1ea5677fc5d7c261d8eac08e1d
Currently the HAL shim uses fake names to ensure that each type of
IWifiIface has a unique name. This is not a true reflection of the
network interfaces exposed by the wifi driver. So, change the HIDL shim
to use the corresponding interfaces names.
IWifiStaIface, IWifiApIface & IWifiNanIface all use the same "wlan0"
network interface.
IWifiP2pIface uses the "p2p0" network interface.
In the future, we'll be extending this to create a second IWifiStaIface
or IWifiApIface using "wlan1" network interface.
IWifiRttController does not need to be associated with an iface object.
So, it will just default to using "wlan0" always.
TODO(b/34702983): Need to deprecate the bound iface from the HIDL interface.
Bug: 65671875
Test: Device boots up and connects to wifi networks.
Test: Will send for regression tests.
Change-Id: I33fef1332f2fe2da3f48ee87ef06660844699253
