The caller could use it to check whether frontend status is ready to
read or not.
Bug: 171540820
Fix: 171540820
Test: atest android.media.tv.tuner.cts on AIDL and HILD HALs
Change-Id: I55610e02412d6043e7fab91d1a2bf187a8e5e3ba
New public APIs
- Tuner.closeFrontend()
- Enables TIS app to continue using other resource while changing
frontend resource
- close & release Frontend resource when called on the owner, while
it unshares Frontend resource when called on the sharee.
- Lnb.addCallback(Callback, Executor) and Lnb.removeCallback(Callback)
- Enables TIS app to receive callback from the sharee
- Also helps with the ownership transfer
- Tuner.transferOwner(Tuner newOwner)
- Transfers the ownership of Frontend, CiCam, and Lnb resource
Additionally, added the following:
- Call nativeSetLnb() in requestFrontend() in case mLnb resource
is already held. (this use case becomes a possibility now that we
support Tuner.closeFrontend())
Bug: 192010866
Test: cts.TunerTest#testTransferOwner, testLnbAddAndRemoveSharee
Change-Id: I4c39c3726f0dd7bd1c153975ad01393ff2773005
The SharedFilter is used to share the Filter created by TIS to another
process. The TIS uses Filter.createSharedFilter() to create a token and
share it to another process. The new process will use
Tuner.openSharedFilter() to open that new token and create a
SharedFilter. The new process will be able to read the TIS owned
Filter's data with this new SharedFilter.
Bug: 196124225
Test: atest android.media.tv.tuner.cts on both AIDL and HIDL HAL.
Change-Id: Id93b30e4db242d35a3d1ae6023b967a90a78c448
This CL also cleans up the unused type casting after moving to AIDL HAL.
TODO: change frequency in java to long to cover frequency bigger than
INT32_MAX.
Bug: 195693712
Test: atest android.media.tv.tuner.cts
Change-Id: I9bc006882d29a27cddd0399a537154579eb0a0dc
After this change, tuner java and jni will not reply on HIDL anymore. It
also cleans up the the unused HIDL direct calls.
Bug: 191825295
Test: atest android.media.tv.tuner.cts
Change-Id: I0113565568119a79ed631b318cc8ccd32e0ae2ec
1. TunerJNI is setting Tuner 1.1 Frontend extended settings regardless of the tuner hal version
2. SectionSettings section bit copy issue
Test: make
Bug: 185627837
Change-Id: I7ab03e2c96b6abd1439f6a277450005e625c0015
This CL get the global strong reference from the weak reference before
calling methods on a weak java object reference in Tuner JNI.
The method call would use the strong ref instead of the weak ref after
making sure it's non-null because weak ref is not garanteed non-null
even after the null check
see https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#weak_global_references
for more details
Test: atest android.media.tv.tuner.cts
Bug: 176190716
Change-Id: I81215c18cda413c5ddee0e46480ce3783dfe4be9
Note: This was part of ag/13255478. Making it a separate CL can break
the dependency of the Tuner client changes on the frameworks/base
changes that require owner review from external teams.
Test: make
Bug: 174095851
Change-Id: Id40014b2ccd95b944e465b79571e113d8ed1a254
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
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
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
This can unblock tune/scan CTS test cases.
If a frontend resource is acquired in a test case and not released,
it cannot be used by another test case.
Bug: 150952758
Test: atest android.media.tv.tuner.cts.TunerTest
Change-Id: Ib9bab003fc81fe008091a9d1aaefc43e454c3230
