This CL fixes a null pointer exception by adding a null check.
Bug: 170357507
Test: run android.media.cts.ThumbnailUtilsTest and no crash
Change-Id: I60645e4382700993ff7e1bc992b970d89b5b600e
(cherry picked from commit fc24bd264ef1f599efa834fc120bc6d1ed304af3)
Reflects refactoring of JNI helper code that depends on private
methods within libnativehelper.
Bug: 151443957
Test: Treehugger
Change-Id: I7af128f42ae89a77a8e3fb113ea533331153c535
When the genre tag is numeric, return a human readable string instead
of the raw numeric tag.
Bug: 141520122
Test: CTS
Change-Id: Ida0d48171e1400b87940e4e38aa07d2fdd5a77ed
This is part of the effort to stabilize the ABI of the android
graphics package so that it can be contained within an APEX module.
Test: CtsMediaTestCases
Bug: 137655431
Change-Id: Ifdd6083ad18a73df819fadc36823ddc3027b7049
Add versions of these two methods that accepts BitmapParams.
Does not change spec or behavior of existing getFrameAtTime/
getScaledFrameAtTime.
bug: 135718180
bug: 138114267
test: CTS MediaMetadataRetrieverTest; manual testing with
thumbnails saved to storage and examine the outputs.
Change-Id: I75e96dde072c94ac950f0be637cdd096e7543f10
This change renames the IMemory raw pointer accessors to
unsecure*() to make it apparent to coders and code reviewers
that the returned buffer may potentially be shared with
untrusted processes, who may, after the fact, attempt to
read and/or modify the contents. This may lead to hard to
find security bugs and hopefully the rename makes it harder
to forget.
The change also attempts to fix all the callsites to make
everything build correctly, but in the processes, wherever the
callsite code was not obviously secure, I added a TODO requesting
the owners to either document why it's secure or to change the
code. Apologies in advance to the owners if there are some false
positives here - I don't have enough context to reason about all
the different callsites.
Test: Completely syntactic change. Made sure code still builds.
Change-Id: I4c555ef8c8c47cf28b42b17ad8b4021a783548cd
Use getFrameAtIndex sequentially and retrieve one frame at a time,
MediaMetadataRetriever internally will reuse the decoder and frame
memory in this case. This is as efficient and holds up less shared
memory (as we only need one temp frame).
bug: 120414514
Change-Id: I58ddc5df63edaf480875ce2651bf18a037793aad
This is a part of job to cut dependency from libmediandk
to libandroid_runtime. As a LL-NDK, libmediandk desn't have
to depend on libandroid_runtime.
dependency: libmediandk -> libmedia_jni -> libandroid_runtime
Libmediandk calls three utility functions defined in
android_media_Utils.cpp. But these functions are independent
from libandroid_runtime.
By extracting those utility functions into its own shared library
(libmedia_jni_utils), the dependency from libmediandk to
libmedia_jni is cut down.
However, some classes and other functions in android_media_Utils.cpp
are moved into new file, android_media_Streams.cpp since they
depend on libandroid_runtime.
Bug: 124268753
Test: m -j
Change-Id: I1e1ea4bc1ff7022d8d9c42785c8c00e3ca153a50
Use the heif embedded thumbnail as long as it's not
too small to avoid decoding the full image and downscale.
bug: 74395267
Test: CTS MediaMetadataRetriever test; manual test of thumbnail
extraction by browsing new folders containing heif files in
Downloads app.
Change-Id: I5b2be0521452376153a773cb7671fefe7f9bc439
- renaming of MediaFormat keys related to grid config
- add methods to MediaMetadataRetriever to get image/frame
with default bitmap config
- fix java doc
bug: 74831433
Change-Id: Iec607e615d34bea0620070592e4adcfc04cbccae
Add an option similar to BitmapFactory.Options to the bitmap
extraction APIs added in P to allow the app to specify bitmap's
pixel format. MediaMetadataRetriever's old getFrameAtTime()
only allows extraction in RGB565, for image use case the bitdepth
could be too low.
Also change return type of getFramesAtIndex to List as
Lint is complaining about returning raw arrays.
bug: 63633199
bug: 73886998
Change-Id: I40f0a421c767483e32c7744180dc5a187681e066
MediaMetaRetriever derives from RefBase, so we should treat it as such.
Bug: 30816425
Test: build, boot, CTS
Change-Id: Ifa089636c5d997cd9e17bf23b9e5f49a7ee2cbed
- Add a few methods to MediaMetadataRetriever to get still
images and frames by index.
- Declare keys in MediaFormat related to heif still images.
bug: 63633199
test:
cts-tradefed run cts-dev --module CtsMediaTestCases --compatibility:module-arg CtsMediaTestCases:include-annotation:android.platform.test.annotations.RequiresDevice
Change-Id: I9556b27f7395a163aadd01e979930061878994d0
libnativehelper exports headers under nativehelper. These were
available before incorrectly as global headers in order to give
access to jni.h.
Test: modules using frameworks/base find headers
Bug: 63762847
Change-Id: I0f9f231acdebe460f279135462f43d3e32eff64d
Stop assuming that a Java Bitmap has a SkBitmap* that
has some externally managed lifecycle, and instead switch
a bunch of users to accessing the bitmap by providing
their own SkBitmap* on which to set the (ref counted!)
SkPixelRef* instead
Attempt #2 to land this, original issue was in getSkBitmap
and should be fixed
Change-Id: I0fd9e193968b41e5597784140d56b4885906864a
This allows apps to implement MediaDataSource, which is modeled on
stagefright's DataSource, to supply media data to the framework. This
was already implemented for MediaExtractor, but it was renamed from
DataSource.
MediaExtractor, MediaPlayer and MediaMetadataRetriever each have a new
overload: #setDataSource(android.media.MediaDataSource)
Only NuPlayer supports this new data source.
The change introduces:
* IDataSource: The binder interface for DataSource.
* JMediaDataSource: The native counterpart to the java interface. It
implements IDataSource.
* CallbackDataSource: A stagefright DataSource that wraps an IDataSource.
Change-Id: I6d9c1167b4a7384c469b1e928f31791a7ebed716
Stop assuming that a Java Bitmap has a SkBitmap* that
has some externally managed lifecycle, and instead switch
a bunch of users to accessing the bitmap by providing
their own SkBitmap* on which to set the (ref counted!)
SkPixelRef* instead
Change-Id: I0fd9e193968b41e5597784140d56b4885906864a
Fix a bunch of places where mNativeBitmap was being
poked at directly, switch them either to the NDK API
or to GraphicsJNI where it made sense
Change-Id: I6b3df3712d6497cba828c2d3012e725cb4ebb64d
Adjust format strings to not produce Clang warnings in both 32-bit and
64-bit builds
Change-Id: I76c29d8d5d0fb4b5e9d9518077652370ffe9e871
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
When the app's vm-heap is not enough, memory allocation for big
object like bitmap may failed.
This patch add protection for bitmap creating to avoid segment
fault error in the following GetIntField function.
Change-Id: I63977dc602f4ed395afd11004a0ed027173fb685
Signed-off-by: wang, biao <biao.wang@intel.com>
Signed-off-by: TingX Li <tingx.li@intel.com>
Signed-off-by: Wang LiangX <liangx.wang@intel.com>
The local variables width, height, displayWidth and
displayHeight are set to the corresponding members
of VideoFrame class. As the members of VideoFrame are
uint32_t, the local variables have been changed to
uint32_t.
As these local variables are passed to a java method,
the change of size_t to uint32_t ensures that the size
of the actual parameter (i.e uint32_t) is now same as
the size of the formal parameter (i.e. jint) for all
platforms.
Change-Id: Icd14de0142bfd4e6ba52a3e6aff3d80b323a0de4
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Changes in this patch include
[x] Long is used to store native pointers as they can
be 64-bit.
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.
Change-Id: I940433f601c6db998c1a8ffff338f5361200d5ed
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
This a merger of two commits submitted to AOSP by
the following authors:
ashok.bhat@arm.com, david.butcher@arm.comacraig.barber@arm.com, kevin.petit@arm.com and
marcus.oakland@arm.com
Due to the very large number of internal conflicts, I
have chosen to cherry-pick this change instead
of letting it merge through AOSP because the merge
conflict resolution would be very hard to review.
Commit messages below:
================================================
AArch64: Make graphics classes 64-bit compatible
Changes in this patch include
[x] Long is used to store native pointers as they can
be 64-bit.
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
==================================================================
AArch64: Use long for pointers in graphics/Camera
For storing pointers, long is used in
android/graphics/Camera class, as native
pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use of
jint instead of int in JNI function prototypes)
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
===================================================================
Change-Id: Id5793fa0ebc17ee8b1eecf4b3f327977fdccff71
This a merger of two commits submitted to AOSP by
the following authors:
ashok.bhat@arm.com, david.butcher@arm.comacraig.barber@arm.com, kevin.petit@arm.com and
marcus.oakland@arm.com
Due to the very large number of internal conflicts, I
have chosen to cherry-pick this change instead
of letting it merge through AOSP because the merge
conflict resolution would be very hard to review.
Commit messages below:
================================================
AArch64: Make graphics classes 64-bit compatible
Changes in this patch include
[x] Long is used to store native pointers as they can
be 64-bit.
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
==================================================================
AArch64: Use long for pointers in graphics/Camera
For storing pointers, long is used in
android/graphics/Camera class, as native
pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use of
jint instead of int in JNI function prototypes)
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
===================================================================
Change-Id: Ib3eab85ed97ea3e3c227617c20f8d213f17d4ba0
For storing pointers, long is used in media classes,
as native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: Idc4ca0124d03df7f9cef412488abafd020e5e774
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
o Change the impl of MediaMetadataRetriever.setDataSource(String).
It opens and passes an fd to the media framework
rather than pass the file path directly to the media server. The change is needed since media
server does not have read permission to sdcard
o Remove the unnecessary jni method
Change-Id: I5a2f47dde804523d264b588f855ba2575a99c179
