Merge the configuration of scrambling status change and ip cid change
into one API - configureMonitorEvent
Previously we only report scrambling status change on configured status,
now we change it to report any status change along with the initial
status
Test: atest TunerTets
Bug: 153595125
Change-Id: Ie6e26774dd3f3ab5753746795188a258e1a55393
Restart event would be sent when a filter is reconfigured and
restarted.
After stopping to reconfigure the filter, all the filter events
should be discarded until restart and receive the start event
from the newly configured filter.
Test: atest android.media.tv.tuner.cts
Bug: 172593389
Change-Id: I1c7c4391d8477ae191e318b1830dd8afed86ed87
* changes:
Remove manual parceling from Interpolator and VolumeShaper
Add av-types-aidl to libandroid_runtime, libmedia_jni
Add dependencies to libandroid_runtime, libmedia_jni
Add dependency to libandroid_runtime
audioclient-types-aidlaudioflinger-aidl aidl_interface module has been
extracted from libaudioclient as part of an AIDL focused refactoring.
Clients need to depend on this module to compile.
Test: compiles
Change-Id: If1b773e7505f93c01027563dd3b1123577ebe495
DTMB is a new frontend type added in Tuner 1.1
Tuner java Framework and Tuner JNI are changed to
handle the new DTMB Settings and Capabilites
Test: atest android.media.tv.tuner.cts
Bug: 159064654
Change-Id: I25209eb4da4f6790765299c95442f6363ef4cf31
Tuner JNI would call tune_1_1 and scan_1_1 when:
1. IFrontend 1.1 implementation exists
and 2. Frontend Extended Settings are set from Tuner Java
Otherwise tune and scan in Tuner 1.0 would be called.
Test: atest android.media.tv.tuner.cts
Bug: 158818695
Change-Id: I477642c5623d8565fd05cbcb8789a2e09b074890
Width and height need to be even and > 0 for the calculated dataSize to
be valid.
Test: test app crashes with a meaningful error message instead of an
allocation failure.
Bug: 163175419
Change-Id: Ibcce3e62f89b7d19d64e8a5efe792b35af6ab401
In the MediaEvent of AV filters, the AV memory handle is mapped/unmapped on each event.
If the vendor allocates a persistent memory block, and use MediaEvent.offset to access the data,
the mapping change is unnecessary.
To improve this, a new API to get shared AV Memory is introduced in
Tuner HAL 1.1.
Tuner JNI queries the sharedAvMemory Handle when the media filter is
opened. It builds up linear block through either shared or independent
memory block by checking the memory handle fd number.
Test: make
Bug: 162013047
Bug: 157143515
Bug: 156664393
Change-Id: I5bfe3a8f4c26b5789212f56709b70c512ed15a0c
These APIs are only supported in Tuner 1.1 or higher
Test: atest android.media.tv.tuner.cts
Bug: 158818696
Change-Id: I1df5b8b908455d47dbe183070456b15116b75cb7
This can help Tuner java/cts get the information of the Tuner HAL
implementation version and notify the client on the availability of
the APIs in different versions or test with different expected result.
Users can all access getTunerVersion to get the information.
Test: atest android.media.tv.tuner.cts
Bug: 158816517
Bug: 164449999
Change-Id: I0b6e4c226e696ca7f94dff7d2c9a59f57af7e13a
Please see the Tuner HAL 1.1 design doc here:
go/android_tuner_hal_1.1
In this CL, the Tuner framework and JNI start to use the
@1.1::IFilter.getId64Bit() API and @1.1::IFilterCallback.
Currently the 1.1 IFilterCallback passes two new 1.1 record filter
events: DemuxFilterTsRecordEvent and DemuxFilterMmtpRecordEvent.
Tuner Framework exposes a new API: getId64Bit() which calls
the native getId64Bit. Also Filter java will be using long id
instead of the previous int id.
The FilterCallback interface remains unchanged but the TsRecordEvent
and the MmtpRecordEvent carry more variables to pass the extra info
in version 1.1.
When the HAL implementation is on version 1.0 and calls
onFilterEvent, it still uses the extended TsRecordEvent and
MmtpRecordEvent but the 1.1 field will be set to invalid.
Related HAL interface can be referred here:
hardware/interfaces/tv/tuner/1.1
Test: make -j44 dist, atest android.media.tv.tuner.cts
Bug: b/159058358
Bug: 158816517
Change-Id: I8d52c0b2031eed9c54909e5bf233137c56eeb78f
Allows MediaParser and MediaExtractor clients to know the
encrpytion pattern of the parsed/extracted media. Without
the getter, only MediaCodec can know the pattern, which
impossibilitates the use of app-bundled decoders.
Bug: 158743263
Test: atest CtsMediaTestCases:MediaCodecTest.testCryptoInfoPattern
Change-Id: Iaf77c8ecafad093cfa434a9ac31314895a44e78f
This applies to the following types:
- audio_gain_mode_t;
- audio_flags_mask_t;
- audio_channel_representation_t;
- audio_channel_mask_t;
- audio_devices_t.
Enum types are distinct thus proper overloading on the type
is possible in C++. Also, assignments to enum types are
less prone to errors.
Bug: 169889714
Test: basic audio functionality
Change-Id: I7f32a7c7741dea88fa2fd8a2e7fe50d0c31eb2e7
These projects triggers Clang crash for global ThinLTO build. Disable
ThinLTO for these projects for now.
This CL has no affect for normal builds.
Test: GLOBAL_THINLTO=true m
Bug: 169004486
Change-Id: Id0c7d243250b6dc7f1ec3099c77cebc179d2c3b3
The package name will be used when starting external vibration. The
package name will be sent to vibrator service to check if the
application has the permission to start vibration,
Bug: 165910728
Bug: 162343845
Test: atest AudioTrackTest MediaPlayerTest
Test: start audio-coupled-haptic playback
Change-Id: I04b4711d11ab5f0f0716ea4c5e1c0f754fe834bb
Merged-In: I04b4711d11ab5f0f0716ea4c5e1c0f754fe834bb
