Bug: 142252770
Bug: 169137236
Bug: 169139756
Test: this
Features built into the PNG format slow down fuzzing (e.g. CRC, encoded
lengths) [1]. Use structure aware fuzzing for PNG to do a better search
through the input space. Add png_mutator.h (unchanged from [2] under the
Apache 2.0 license). Split imagedecoder_fuzzer into two targets: one for
PNGs (since the mutator converts all inputs into PNG), and one for the
other formats.
Move fuzz_imagedecoder.cpp and the corpus/ into the new fuzz/ directory,
to keep fuzzing separate from the libjnigraphics library. Remove
png_test.png from the corpus; structure aware fuzzing will do a better
job of fuzzing PNGs, and the generic one should focus on other formats.
[1] https://github.com/google/fuzzing/blob/master/docs/structure-aware-fuzzing.md
[2] 51356066dc/libpng-1.2.56/png_mutator.h (L1)
Change-Id: I8aebb0d0abfa18793334f2d217b28a51d096123a
Test: I138ec784a77253c7ae94765d0670e5947d97caf5
Recently (Ib93b0ced09fa3cca4a6681745406355c48158fae), handling exif
moved from SkAndroidCodec to hwui/ImageDecoder. This missed
getSampledDimensions, which reports the sampled dimensions without
taking exif into account. Fix this for both
android.graphics.ImageDecoder and AImageDecoder. Note that in the Java
case, the method is private, and although the method was returning
swapped dimensions in some cases, it gets corrected by
getTargetDimension, so there is no user visible change.
Change-Id: I918328c39d6230ae6ba4cab0733fff0732b39888
Bug: 142252770
Bug: 169137236
Bug: 169139756
Test: this
Image decoders may attempt to allocate a large amount of memory
(especially if the encoded image is large). This doesn't necessarily
mean there is a bug. Set allocator_may_return_null = 1 for hwasan so the
fuzzer can continue running.
Change-Id: Ib750a142e28d01144036409786e631dfb783283f
Bug: 142252770
Bug: 169137236
Bug: 169139756
Test: SANITIZE_HOST=address make imagedecoder_fuzzer
This will allow running the fuzzer much faster in order to find bugs. It
also allows running with ASAN to help find memory leaks.
Some symbols (e.g. ABitmap, AAssetStreamAdaptor) rely on
Android-specific features, so disable them when building on the host.
This still allows using the core features of AImageDecoder.
This requires a change in frameworks/native
(Iefdb4132d6f10f9164be85f4dc6e11883f6fd37e).
Disable detecting ODR violations when building with ASAN (which is how
host builds are built). Without this change, the host detects the
following:
=================================================================
==4072183==ERROR: AddressSanitizer: odr-violation (0x7fb7d52b4100):
[1] size=80 'vtable for android::VectorImpl' system/core/libutils/VectorImpl.cpp
[2] size=80 'vtable for android::VectorImpl' system/core/libutils/VectorImpl.cpp
These globals were registered at these points:
[1]:
#0 0x55fefda47e0d in __asan_register_globals /out/llvm-project/compiler-rt/lib/asan/asan_globals.cpp:360:3
#1 0x7fb7d43aa77b in asan.module_ctor (/usr/local/ssd/android/master/out/host/linux-x86/fuzz/x86_64/imagedecoder_fuzzer/../lib/libhw
ui.so+0x17c677b)
[2]:
#0 0x55fefda47e0d in __asan_register_globals /out/llvm-project/compiler-rt/lib/asan/asan_globals.cpp:360:3
#1 0x7fb7d52a0e6b in asan.module_ctor (/usr/local/ssd/android/master/out/host/linux-x86/fuzz/x86_64/imagedecoder_fuzzer/../lib/libutils.so+0x3de6b)
==4072183==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0
SUMMARY: AddressSanitizer: odr-violation: global 'vtable for android::VectorImpl' at system/core/libutils/VectorImpl.cpp
==4072183==ABORTING
Change-Id: I0ffc4e90b4083db79fbb12012e2e1284206b43e3
Bug: 169137236
Bug: 169139756
Test: this (fuzzer)
Extend the fuzzer to test animations.
Also test a lossless webp, left out of
Ib227639bf8da75f0e8e31e216bc6d1371e24cb75.
Change-Id: I81d35d6fa7d560b33b6a2b5d6c1992cbdd77bc87
Bug: 142252770
Bug: 169137236
Bug: 169139756
Test: This (fuzzer)
Attempt to cover the types supported by AImageDecoder:
- jpeg (progressive and baseline)
- png
- webp (animated and non-animated)
- should maybe include lossless, too?
- gif
- ico (embedded png and bmp)
- bmp
- wbmp
- heif
- various dng formats
These files are either already checked into CTS or Skia.
Change-Id: Ib227639bf8da75f0e8e31e216bc6d1371e24cb75
Bug: 142252770
Bug: 169137236
Bug: 169139756
Test: This (fuzzer)
Use the bytes to create an image file and decode it.
To run:
$ SANITIZE_TARGET=hwaddress make imagedecoder_fuzzer
$ adb root
$ adb sync data
$ adb shell /data/fuzz/arm64/imagedecoder_fuzzer/imagedecoder_fuzzer
Call startThreadPool() to support HEIF. Otherwise HEIF decodes may time
out on binder IPC calls. This is similar to a fix for skia_dm in
https://skia-review.googlesource.com/c/skia/+/108141.
Change-Id: I434730a74c5ff97437526065c41af3f54fae3335
Bug: 160984428
Test: I00682f201a52f894b0e1335c00c4368ce675a805
Also fix a bug caught by the new test. If the current frame is the first
in a series of one or more RestorePrevious frames, fPriorFrame should be
set to |currentFrame - 1|. Otherwise SkCodec will decode the required
frame. This is wasted work, since the prior frame should already be
prepared (either by AImageDecoder or by the client).
Change-Id: I1fb9f91dc66fd3121f187b9a91c15f625eb17f8d
Bug: 160984428
Test: If47d475233f6b9973abf68029b63a610ff47cdae
- AImageDecoder_getFrameInfo
- AImageDecoderFrameInfo_create
- AImageDecoderFrameInfo_delete
- AImageDecoderFrameInfo_getDuration
- AImageDecoderFrameInfo_getFrameRect
- AImageDecoderFrameInfo_getDisposeOp
- AImageDecoderFrameInfo_getBlendOp
- AImageDecoderFrameInfo_hasAlphaWithinBounds
These allow querying for information specific to a single frame in an
encoded image.
Change-Id: I6ce5665e9c25aed23f99ce88290e520d68fcb60e
Bug: 160984428
Test: Iae7d274b69999c471fd5610c6ef4d148cca81bec
Disallow AImageDecoder_set* methods after the first frame, since
changing the settings would interfere with blending and caching for
kRestorePrevious frames.
Add a cache (and a state machine) for handling kRestorePrevious frames.
Follow-on to Ib93b0ced09fa3cca4a6681745406355c48158fae - support using
a matrix for unpremul + orientation (the orientation was previously
handled by a matrix internally in SkAndroidCodec).
Change-Id: I7c32ede013fa83f1fe95c35778c33278ca6fe6a3
Bug: 160984428
Test: AImageDecoderTest#testRespectOrientation
ImageDecoderTest#testRespectOrientation
Ieda439910ae52e609f0710d424503616d99ae5c7
I23caef26b4c82173c758dd0ce7fb6f04e4154588
I345a13d20776a007052d32e74fa42865b42f726d
It is possible to create an animated image with an exif orientation.
Using kRespect, there is no clean way to handle the orientation plus
compositing frames. Switch ImageDecoder to use kIgnore (the default).
Depends on a change in Skia (https://review.skia.org/344762) to make
SkAnimatedImage handle the orientation even with kIgnore.
Change-Id: Ib93b0ced09fa3cca4a6681745406355c48158fae
Targets that will also be contained within the UI module
are allowed to access internal headers. All other targets
that depend on libhwui are restricted to using the APEX headers.
Bug: 137655431
Test: CtsUiRenderingTestCases
Change-Id: Id92e9874dafb98bd79839d45ab8f22ab999689de
Bug: 135133301
Test: AImageDecoderTest
AImageDecoderHeaderInfo_getWidth/Height return an int32_t. Ensure at
creation time that the actual image dimensions will fit in int32_t.
In today's code, this should almost never happen:
- PNGs have their dimensions limited to 1000000
- see PNG_USER_WIDTH_MAX and PNG_USER_HEIGHT_MAX in pnglibconf.h
- JPEGs are limited to 65500
- see JPEG_MAX_DIMENSION in jmorecfg.h
- WebPs' dimensions are encoded in 14 bits
- GIFs' dimensions are encoded in 16 bits
- SkBmpCodec and SkWbmpCodec require dimensions to fit in 16 bits
- SkIcoCodec uses SkBmpCodec or SkPngCodec, so their limits are
enforced
- libheif limits to a size smaller than int32_t
It might be possible for a DNG image to be larger, and some of the above
are configurable. Just in case, make AImageDecoder_create fail on such a
large image.
Change-Id: Id520dfbc0581f990c4f52cb6675e987bf71c558c
Bug: 135133301
Test: I5e8bdcdae6837db23c0f4ef08f931f3bebe0ce0d
Previously the default SkColorSpace for AImageDecoder was set to the
result of SkAndroidCodec::computeOutputColorSpace. If the image has a
profile that does not map to an SkColorSpace, it will return either
DISPLAY_P3 or SRGB. Using that at decode time will result in color
conversion.
Instead, default to a null SkColorSpace for such a profile, resulting in
no color conversion. If the image has no profile, default to SRGB, as
usual.
A client that wants SRGB can still request and get that, but this allows
getting the raw pixels for an advanced client that may want to do its
own conversion.
Change-Id: I489f31fef79dec11e97c8e8fb9207adb77a3d0c7
Bug: 135133301
Test: Ibf7c0e563feeb08ce6dbabb5e86ddb385c9dff54
Remove isAnimated and update parameters/returns to match
I93df851dd9fee2eb8d097e2158fb95003a0474db.
Change-Id: Ida2af1682b5f9b91e37079005391b1594239d345
Bug: 135133301
Test: No change in behavior, no new tests
Along with Id5d039761054cf8e7fb906624a277714c21156de, which does the
rename in the header, this does the rename in the impl.
Change-Id: I27244df241a8141b0fd39e02e778eef2975f4dc0
Bug: 147749998
Test: I902de3410c45a21cf27b48a02cdc5d514b7ada60
If the client uses a stride that is not pixel aligned, AImageDecoder
will crash internally trying to access the memory. Return a failure
instead of crashing. Rely on SkImageInfo to compute the minimum size
required, too.
Change-Id: Ia4d14d6209e6f4af74906ff43208fa83ac82cbcd
Bug: 135133301
Test: Iffe659e50078139188c3325545624640ae177cc2
Implement AImageDecoderHeaderInfo_getDataSpace, which reports the
default ADataSpace to decode to. It may report ADATASPACE_UNKNOWN, which
means that we've mostly left the colors in their original color profile.
This matches android.graphics.ImageDecoder/BitmapFactory, which would
use a ColorSpace named "Unknown". (It will standardize on DISPLAY_P3 for
some profiles, which again matches the Java classes.)
Implement AImageDecoder_setDataSpace, which allows specifying the
ADataSpace to decode to. It only supports explicit ADataSpaces.
Change-Id: Iba2f9e09531c23fae83ebe13cb9d18394ee3cd59
Bug: 135133301
Test: I32e9a257a63382629b25f64d1d0abe9682ddec70
Make sure the Bitmap is valid before trying to read its data space.
Change-Id: I0d075197ddc548143a4e4845cc5cc5d3b10d87c7
Bug: 135133301
Test: I2c1e58c41e49c72fb4bdbc64989da103885d34bf
_getInfo now sets a bit in AndroidBitmapInfo.flags to indicate whether
the Bitmap has Config.HARDWARE.
For a HARDWARE Bitmap, its AHardwareBuffer can now be retrieved with
AndroidBitmap_getHardwareBuffer. Call AHardwareBuffer_acquire on the
buffer so it will not be deleted while the client is using it.
Change-Id: I9240c1928c1478053ecf7c252443a33dbd6fd6db
Bug: 135133301
Test: Ifbcb41388a48afc64bb22623bb7e981b288b2457
Refactor the bulk of Bitmap_compress into hwui/Bitmap::compress, so that
it can be shared by the new API. Update its enum to match the proper
style. Also make the enum a class so it does not need to have a special
return value for a bad parameter, which is now handled by the caller.
Add ABitmap_compress, which implements the new API by calling
hwui/Bitmap::compress.
Change-Id: Ia8ba4c17b517a05b664c6e317e235836473fd7f6
Bug: 135133301
Test: I48e49ee08ab1954eddf62ecae87942aeb128c10d
As described in I3381582e27894e1072db9b8635f3762b801f5d69, this is a
more sensible API.
In addition, remove unused methods on ImageDecoder.
Lastly, update AImageDecoder methods in the map to document which API
level they were introduced in.
Change-Id: I1aff544e8d6932b9ed0931a00da66a0aba6cd536
Bug: 135133301
Test: I2ea58bede5cf49a7947c96e7e6e37f967632ad6b
BAD_PARAMETER is a more sensible value than -1. The other return will
not be reached, but the code is clearer.
Change-Id: I4bee8f238f61a6c6cd13b5458f201f34d34315d9
Originally reviewed in Ie05a45da32b2fd670abdae35626cd6548cfb102c
(and reverted in I0b06312f6583f766512cc771a35d3d735debcce1)
Bug: 135133301
Test: I7a5fcb726fba0c832bbb86a424d7534a7cfa35b6
This supplements AndroidBitmap_getInfo, allowing NDK clients to know how
to interpret the colors in an android.graphics.Bitmap.
Only build android_bitmap.cpp on Android so that it can rely on
libnativewindow (which is Android-only) for data_space.h
Change-Id: I4b23c68c7e62ed733e95af6f76c47fecbc2c5747
Bug: 135133301
Test: Ib84462ea5fa8a7779eaa44494775e182e52ecaca
Separate out the code for encodedFormatToString into a piece which
returns a const char* that can be used by AImageDecoder (with its own
header) and the part that the JNI code uses to convert that into a Java
String.
Change-Id: I4cf8bfb0aacfb8e22c3f9b1689bd614ed1253673
Bug: 135133301
Test: Ib84462ea5fa8a7779eaa44494775e182e52ecaca, once
I4cf8bfb0aacfb8e22c3f9b1689bd614ed1253673 lands
AAssetStreamAdaptor lives in libjnigraphics, for use by AImageDecoder.
Change-Id: I4e2559c3c21c866d61fb431a0a1368150c7d39cb
Bug: 135133301
Test: I7a5fcb726fba0c832bbb86a424d7534a7cfa35b6
This supplements AndroidBitmap_getInfo, allowing NDK clients to know how
to interpret the colors in an android.graphics.Bitmap.
Depends on I8e06071060ab19b103900ff04d60f1c3d3fccda9
Change-Id: Ie05a45da32b2fd670abdae35626cd6548cfb102c
the NDK APIs are implemented in terms of the APEX APIs to
reduce the number of different implementations serving the
same fundamental purpose.
Bug: 137655431
Test: CtsGraphicsTestCases
Change-Id: Idc7b85403a7e546843b9c1d822acc0a1e740059a
Hide unintentionally exported symbols, validate that symbols mentioned
in the map file actually exported by the library.
Bug: http://b/69603741
Test: make
Change-Id: I80ec35b715b28dea45ebfbd216130c2c946c6668
Global flag --pack-dyn-relocs=android is used with clang lld.
For b/24465209, we need to override that with pack_relocations:false.
Bug: 24465209
Bug: 80093890
Test: build with USE_CLANG_LLD=true and run dlext.compat_elf_hash_and_relocation_tables
Change-Id: I9364feb4070d4f75705d8651d535c792fe6ad6f7
