TunerHAL expects Hz
Fix stopRecordThread race
Push segment000000.ts to device
getFrontendIdByType() should return INVALID_ID when no FE found
Bug: 201556155
Test: VtsHalTvTunerV1_{0,1}TargetTest on BCM device
Change-Id: Idab6817e47f3e10f07a36a8b2fd805336b9f0e5d
Signed-off-by: Pierre Couillaud <pierre@broadcom.com>
This CL starts the refatoring of Tuner 1.0 vts configuration file
to replace the previous manual config with the current dynamic config
using xml/xsd.
Note that this CL only connects the frontend setting section with
the dynamic config. The CLs to connect other hardware configs will come as
child CLs.
This CL also has some default implementation/vts test impl changes to
sync the sc-dev vts 1.0 with the aosp.
Child CL will also replace the 1.1 manual config with the dynamic
config.
Test: atest VtsHalTvTunerV1_0TargetTest
Bug: 182519645
CTS-Coverage-Bug: 184077478
Change-Id: I13e6ea3d91e474c10e4f822a6ce59d99cc7c7d1d
This helps the CTS to cover more Frontend JNI/java/client codes
Test: atest android.media.tv.tuner.cts
Bug: 181088182
Change-Id: I6fe079f7691cddaca6262345b10abc2145a5a6f3
This CL added more extended frontend status caps into the
default implementation to test more code paths.
Note that this CL changes the 0 fe from dvbt to isdbs to cover more
status caps. fe 0 is used as the default testing fe in CTS
Test: atest android.media.tv.tuner.cts
Bug: 159067322
Change-Id: I7c15f5fe3cd133af4a191b80ce832a9affef9ee3
This CL enables the android.hardware.tv.tuner@1.1-service
with the default implementation of Tuner HAL 1.1
The 1.0 Tuner HAL interface implementation are identical to the 1.0
default implementation.
The 1.1 new API implementation are added with *_1_1 suffix.
Note that we cast all the uint32_t id in the 1.0 Hal implementation
into uint64_t even calling the old 1.0 APIs. This makes sure
the 1.1 default implementation internally only record 64-bit ids.
Test: atest VtsHalTvTunerV1_1TargetTest
Bug: b/159058358
Change-Id: Ic506376e520f03235010bc503e337c02d5735ec3
