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
core/java/android/graphics doesn't exist, so neither
does core/android/graphics/OWNERS
Fix the include path to point to the graphics source of truth
as /graphics/java/android/graphics/OWNERS
Test: this
Change-Id: I5a1e6edbc82df5e3b2979753a6d7329707c55d88
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
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: 174932174
Test: I solemnly swear I tested this conflict resolution.
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I9262a08ffc1ccede8e519d0eed90ed2bfcf0232c
As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script that
identifies relevant "include" directives.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
Change-Id: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
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
