NdkJavaVMHelper.h is not a valid NDK header. Replace this one with
NdkJavaVMHelperPriv.h in the cpp directory.
Bug: 149578834
Test: NativeDecoderTest
Change-Id: I07ddec4d31ae84bf4a739fcf512859f794cb1baa
The linker error previously seen no longer happens - it probably got
fixed by a non-toolchain-related change since clang-r349610 from Feb
2019 is able to build libmediandk with coverage in the Q branch.
Bug: http://b/124522995
Test: mmma NATIVE_COVERAGE=true frameworks/av/media/ndk and check that
built libmediandk.so has __gcov_flush symbol
Test: Presubmit target cf_x86_phone-userdebug_coverage
Change-Id: I24f0c3fbbea733a521ea97e4fe28c94c6f607119
The APIs that are tagged with # vndk are actually for LLNDK libraries.
Although LLNDK is part of VNDK, calling those APIs 'vndk' has given
users a wrong perception that the APIs don't need to be kept stable
because that's the norm for most of the VNDK libraries that are not
LLNDK.
In order to eliminate the misunderstanding, rename the tag to 'llndk' so
that people introducing new such API will realize what they are signing
themselves up for.
Exempt-From-Owner-Approval: cherry-pick from internal gerrit
Bug: 143765505
Test: m
Merged-In: I6b48cf2091def384780ca91c32a0ddb738e70455
(cherry picked from commit 2299310926)
Change-Id: I6b48cf2091def384780ca91c32a0ddb738e70455
The APIs that are tagged with # vndk are actually for LLNDK libraries.
Although LLNDK is part of VNDK, calling those APIs 'vndk' has given
users a wrong perception that the APIs don't need to be kept stable
because that's the norm for most of the VNDK libraries that are not
LLNDK.
In order to eliminate the misunderstanding, rename the tag to 'llndk' so
that people introducing new such API will realize what they are signing
themselves up for.
Bug: 143765505
Test: m
Change-Id: I6b48cf2091def384780ca91c32a0ddb738e70455
This is part of the effort to remove binder-related classes from libmediadrm.
This change replaces a generic listener for Parcel data with separate
listeners for each event type.
Bug: 134787536
Test: MediaDrmClearkeyTest
Test: NativeMediaDrmClearkeyTest
Test: MediaDrmMockTest
Change-Id: I90cbb75b21cc63737994a01a2171caee5cfb84ad
Added utilities to:
* Query config for IMediaDrmService usage
* Create remote vs local IDrm/ICrypto object based on aforementioned config
Bug: 134787536
Test: MediaDrmClearkeyTest#testClearKeyPlaybackCenc
Change-Id: I72df528c0bbd8a6dbd3c4962ac91eb89696bcaf7
* changes:
camera2ndk: ~ACameraCaptureSession shouldn't hold device lock in ACameraDevice_close().
AImage: don't allow ~AImageReader to run before AImages are deleted.
AImageReader: make sure ~AImageReader isn't called with FrameListener::mLock held.
AImageReaderVendorTest: Tolerate failures for ACameraDevice_isSessionConfigurationSupported.
This is preparation for having a subclass of DataSourceFactory which
is only used in mediaserver process with OMA (forward-lock) use case.
Test: build
Bug: 142567168
Change-Id: I2a1ab3d1ae89f657a84376d9a95d4e814b545b4f
into libdatasource, which contains:
DataSourceFactory
(Clear)FileSource
(Clear)MediaHTTP
DataURISource
HTTPBase
NuCachedSource2
This is needed to break a circular dependency in an upcoming CL.
Test: build, boot
Change-Id: I34d9937235c78f18f51b18945342a0743e209577
Merged-In: I34d9937235c78f18f51b18945342a0743e209577
We can never be sure whether ~AImageReader() has run to completion or
not in AImage::close(). So we move clean up to another AImageReader
method and make sure that's called when in AImageReader_delete. AImage
now contains an sp<> to AImageReader so we can be sure that its members
wouldn't have been destroyed by ~AImageReader and we can check whether
AImageReader_delete has been called on it.
This also prevents us from deadlocking since AImage_delete could also cause
~AImageReader to run with AImageReader::mLock held in AImage::close().
Bug: 137571625
Bug: 137694217
Test: enroll; auth
Test: cts native AImageReader, camera, graphics tests
Merged-In: If5803cb6fcb6f4800032069872daaeac1cd36ed2
Change-Id: If5803cb6fcb6f4800032069872daaeac1cd36ed2
(cherry picked from commit 9e0302fcc1)
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
The following sequence of events is possible:
t1: FrameListener::onFrameAvailable callback is called, mReader is
promoted from wp<> to sp<>, t1 holds mLock.
t2: AImageReader_delete is called, decStrong is called on AImageReader,
but since its refcount isn't 0, ~AImageReader isn't called
t1: onFrameAvailable completes, ~AImageReader is called with mLock
held, ~AImageReader->
setImageListenerLocked->FrameListener::setImageListener->tries
to lock mLock again, t1 deadlocks.
We move the locking mLock to after the promotion of mReader to sp<> so
that it gets destructed before ~AImageReader is called.
The same is done for BufferRemovedListener.
Bug: 136193631
Test: Auth; unlock
Merged-In: I8bb8c7d59f3711fd9fe434159095938eb5db9153
Change-Id: I8bb8c7d59f3711fd9fe434159095938eb5db9153
(cherry picked from commit ebca5b9862)
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>