Bug: 139186570
Test: make docs
As part of enforcing Scoped Storage for the next Android release, we're
encouraging app developers to steer away from using raw file path access
and, instead, use FileDescriptor or Uri to access files.
Update createSource(File)'s docs to suggest why they might want to use a
different method.
Update the top level example to use createSource(ContentResolver, Uri)
instead of createSource(File).
Change-Id: Icbccdb5183edd0b6a052ec905f999f02ac4e61d3
(cherry picked from commit 4056974583)
Merged-In: Icbccdb5183edd0b6a052ec905f999f02ac4e61d3
Bug: 154954875
Bug: 143231863
Test: I93b01cb60a8c76110ea2ff4250d0048512629d8d
I9229039b752bafa9a9b85b914a62093dff1eec34 switched from "==" to
".equals", but it did not take into account that Uri#getScheme() can
return null. Switch around the .equals check so that it is called on
SCHEME_CONTENT, which will never be null.
Change-Id: I0df5d2407a32fad0e21e597697af293fbc2fb315
Merged-In: I0df5d2407a32fad0e21e597697af293fbc2fb315
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I8ffa1da1bcd43c25f4ff817575db77a33c0f3d31
Bug: 135133301
Test: Idf64474f28c0bf3f77616a31d843d84fbfd570ab
If the specified crop Rect is empty or unsorted, throw an
IllegalStateException, like we do if the Rect does not fit in the target
size.
This is a change in behavior to make it more consistent. Here are the
specific behavior changes:
- an empty crop rect was previously supported in all cases, but would
result in a zero width and/or height Bitmap/Drawable. If one
dimension is non-zero, it still affects layout, though nothing is
drawn. This is not useful, so the new Exception is more helpful. (It
is also more consistent with setTargetSize, which throws an
IllegalArgumentException for non-positive dimensions.)
- a negative width or height in decodeBitmap, or on a static image in
decodeDrawable, previously threw an IOException when trying to call
SkBitmap::setInfo with a negative width or height. Throwing an
IllegalStateException is more consistent with other invalid crop rects
- a negative width or height in decodeDrawable on an animated image
previously resulted in an AnimatedImageDrawable with a negative
intrinsic width and/or height. When passed to an ImageView, this
dimension ends up being 1. Again, this does not seem useful.
Change-Id: I15d2f77125799413eaf55d417e98ff34599e2eb4
Bug: 143231863
Test: Infeasible?
Previously we compared with "==", which requires that the two String
objects be the same to return true. We want to return true if the two
Strings are logically equal, even if they are different objects.
Prior to this commit, we may have accidentally called
openAssetFileDescriptor when we should have called
openTypedAssetFileDescriptor.
Change-Id: I9229039b752bafa9a9b85b914a62093dff1eec34
Bug: 140961740
Test: TODO
We already catch an FNF and attempt to open the file as an InputStream.
Do the same if null is returned.
I haven't figured out a way to make assetFd set to null and yet opening
an InputStream succeeds, so this is untested.
Change-Id: Iabd05db714bc693ead2dc8cc4c0b46fef9f33d5a
Bug: 140961740
Test: I41a93b47acde6a7985c53107f448a8b647d245d7
If ImageDecoder has a null AssetFileDescriptor, either from a Callable
or from a ContentResolver directly, throw a FileNotFoundException.
Previously, a NullPointerException was thrown attempting to dereference
it.
Change-Id: Ie738b9edc062e520835010befc001578fce09832
Pass down a flag to prefer animation over still images
when decodeDrawble is used. Pass the flag via source
to avoid adding this flag to all create/createFrom/
nCreate method variants. Check the flag only in
native_create when we actually create the decoder.
bug: 120414514
bug: 78868457
Change-Id: I84b4edd0225df9eaa59df8a787bd5902146ab500
This'll help developers decide if they can try decoding an image
file directly, or if they need to convert it to a more general
format first.
Bug: 126276695
Test: atest android.graphics.cts.ImageDecoderTest
Change-Id: I6a404e3be883ac14ac2e6376247d4209f8963908
Bug: 123301872
Bug: 117601185
Test: Manual (Ie18811ba29a1db163aca08472b04ae185e9344f0)
Test: CTS (Ie4b0a232effc67ab7a7fc6070302c722177cadfa)
Test: Infeasible (verify desired ColorSpace is used)
When calling setTargetColorSpace on an ImageDecoder for an animated
image, pass this to the AnimatedImageDrawable. Also respect an EXTENDED
ColorSpace as a cue to decode to RGBA_F16, as with Bitmaps.
Call ImageDecoder#checkState for AnimatedImageDrawables, as with
Bitmaps.
Change-Id: I5f6e11ee14ce4477bfedf2d1fdde8e15ed5f24d5
Bug: 117601185
Test: I5e5bc6b73d5d27ae30f00507d59896008d4cf364
ImageDecoder does not have a way to request decoding to F16 on 8 bit
images, but it does have a way to request an EXTENDED ColorSpace. Treat
that as a request to use a higher bit depth. This matches how we match
EXTENDED to F16 in other cases (createBitmap, Bitmap#copy, etc).
Change-Id: I3d31b13b56bb57a23b47ffcb2eaba11c53e0b8d9
Updated ImageDecoder InputStreamSource to always respect the given
inputDensity regardless if the provided resource class is null
or not.
Fixes: 115836404
Test: AI8dcdc764a963e95d6c0ad644a1e05f055c748c75 Added CTS test to
verify intrinsic bounds of resolved Drawable respects display density
Change-Id: I54e5835a8bceea9c991972ff7f106dbed29b6662
Bug: 123377741
Bug: 120870651
Bug: 121001670
Bug: 123374456
Bug: 124052364
Test: I90adb511c8fdefe016028da4fd53b079d8367bf6
RGBA_F16 is no longer restricted to particular ColorSpaces. (Previously,
it was LINEAR_EXTENDED_SRGB when decoded, and EXTENDED_SRGB when
created.) Instead, F16 is now EXTENDED if there is an EXTENDED variant,
but is otherwise not special. It defaults to SRGB (but EXTENDED), but
can be created or decoded to other ColorSpaces.
Likewise, smaller Configs use the non-EXTENDED variant, when the
EXTENDED variant was requested.
ALPHA_8 always has a null ColorSpace.
Add TransferParameters to EXTENDED_SRGB. This seems to be a relic from a
time before Skia treated SkColorSpaces as non-bounded. Make it have the
same parameters as SRGB, so that it can be used in native code. e.g. now
we can draw to/from it.
Fix a bug getting the ColorSpace for gray image. ImageDecoder's info
previously reported that a gray image's ColorSpace is null. (Though it
correctly decoded it with the proper ColorSpace.)
Allow setColorSpace to request SRGB on an EXTENDED_SRGB F16 Bitmap. (It
has no visible effect.)
Do *not* allow setting a ColorSpace on an ALPHA_8 Bitmap (throw an
Exception). Other attempts to create a Bitmap with ALPHA_8 and a
non-null ColorSpace silently use null, for backwards compatibility.
Copying *from* an ALPHA_8 to another Config returns a Bitmap with SRGB.
Change-Id: Ied0426f6deff354df5998691703a18ddd33ccd3d
Bug: 120904891
Bug: 122844033
Bug: 122514935
Test: CtsGraphicsTestCases
Create an SkColorSpace when creating an android.graphics.ColorSpace.Rgb.
This allows simplifying getNativeColorSpace, so that each time we need
it, we do not need to call back up into Java or reconstruct the
SkColorSpace.
Funnel all ColorSpace.Rgb constructors into one, so we can set a final
mNativePtr in the base constructor. Update TransferParameters to also be
final.
Use the same TransferParameters as SRGB in EXTENDED_SRGB and DISPLAY_P3.
When passing a BitmapFactory.Options to native, call getNativeInstance()
(which may throw an Exception) and pass the result to native.
Move native ColorSpace code into its own file.
Make Paint methods @CriticalNative again, now that they do not need the
JNIEnv.
Remove unused decodeBitmap.
Change-Id: I60adbb060b87ab6f92559f1217bfefc0b9ea72e1
Applications could be launched on a secondary display that
has lower density than default display. While some applications
may use 1x1 image resource as activity background, the scaled
width/height would be 0 if down scaling the 1x1 image with
scale ratio that is less than 1/2.
Making sure the scaled width/height won’t less than 1 to
prevent application crashed.
Bug: 117749148
Test: Launch app on secondary display
Change-Id: I73567dd237736466d0bc423485359d50073d86c1
ContentResolver.openTypedAssetFileDescriptor() has support for a
Bundle of options that can be used to communicate things like desired
thumbnail size, and also CancellationSignal to cancel large network
fetches when no longer needed.
Instead of adding all these to ImageDecoder, let developers provide
their own Callable<AssetFileDescriptor> so they can implement these
custom features.
Bug: 111268862
Test: atest cts/tests/tests/graphics/src/android/graphics/cts/ImageDecoderTest.java
Change-Id: I51c509962f50dd08be94507169355b5da54d6782
For packages:
android.graphics
android.graphics.drawable
android.graphics.drawable.shapes
android.graphics.fonts
android.graphics.pdf
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I7fc1162d2c63df8751a4660607e8ce72070efed8
Bug: 76448902
Bug: 70889348
Test: Manual + CtsThemeHostTestCases
(Ica5e7e81848c3880accee922ee6f1cc9e26262ca)
Scaling a nine-patch requires scaling its divs. When the scale factor is
not an integer, we have to round. This gets out of sync with the way the
decoder scaled the image, resulting in stretching or keeping fixed the
wrong portions of the image. Making this worse, when we scale down, we
end up with divs colliding with each other, and we have to arbitrarily
adjust them further so they do not collide.
NinePatchDrawable and the drawing code already know how to handle
drawing from the originally-sized image and do a better job stretching
appropriately, so allow them to do their job.
We already do something similar for Bitmaps created by ImageDecoder on
apps targeting P and above - instead of scaling them up, we allow the
BitmapDrawable's scaling code to handle density differences. We
preserved the old behavior (scale up) on apps targeting pre-P because
those apps may rely on the size of the Bitmap contained in a
BitmapDrawable without accounting for its density (see Bug: 74061412).
But that is not an issue for NinePatchDrawables, which do not allow
peeking at their internal Bitmaps.
Rewrite ImageDecoder.computeDensity. There is no need for it to be
static, since it takes an ImageDecoder as a parameter and reads its
fields, including the new field mIsNinePatch. Set mIsNinePatch in the
constructor to avoid another down call into native. Split up the
conditions that result in returning srcDensity without calling
setTargetSize for clarity.
Remove ImageDecoder constructor from the graylist. It was accidentally
added due to the fact that it is called transitively from public APIs.
Change-Id: I3c5ddd67f3352c991515f30ce1c477c9a608833f
Bug: 77507530
Test: No change in behavior, no new tests
Add @Px and @IntRange annotations, and be explicit that setTargetSize
refers to pixels. Add a comment to setTargetSampleSize that is like
calling setTargetSize with particular values, to try to make it clear
how the two are related.
Change-Id: Ie7e9429bc8c548f44d382358c161425f666ba82f
Bug: 76461699
Bug: 76448408
Test: No change in behavior, no new tests
Add class level docs for ImageDecoder, including sample code. Update
wording to be more clear and less wordy. Fix broken attempts at using
sample code.
Incorporate advice at go/android-api-guidelines and
https://developers.google.com/style/api-reference-comments
Change-Id: Iaf1334993f6cd2d3f6e53d3fb70ef9c7a95c9a76
Bug: 76448408
Bug: 76462125
Test: Iec21bad971dc9cffc807a412bb6329757c499baa
- Document DecodeException.getSource
- Add thread annotations
- slice() ByteBuffer inside createImageDecoder, so it can be reused
- Make ResourceSource thread safe by locking around mResDensity
- Specify that OnHeaderDecodedListener is necessary for changing default
settings
Change-Id: I3b55d3ba1b0a2276938cb521449bceb7aa9f96e2
Bug: 76448408
Test: Ib8782ff10072c81a5ed2a1031a70475fffee7ccf
- Use "is" prefix for booleans instead of "get"
- Reverse "require" and "unpremultiplied" for a more natural sound
- Add "Required" to "Mutable" methods
- Add "Enabled" to "DecodeAsAlphaMask" methods
Change-Id: I644ddccd37898d89609e4534ece4ea70f74587c4
Bug: 76448408
Test: I851173b771668f0e6712bebfe06bfb8559801199
Add ImageInfo.getColorSpace() for retrieving the default ColorSpace.
This matches BitmapFactory.Options.outColorSpace.
Add ImageDecoder.setTargetColorSpace() for choosing a new ColorSpace.
This matches BitmapFactory.Options.inPreferredColorSpace.
Rename setSampleSize to setTargetSampleSize to match setTargetSize and
setTargetColorSpace.
Change-Id: If2f4e755dfc163f754849f896de24659198973db
Bug: 76448408
Bug: 73537624
Test: Ib40d65c68a6c709b6456f2145ad8a5557a941494
setResize is two verbs, and "resize" implies we're changing the size of
an existing object. In truth, the method specifies the desired size. So
rename setResize(int, int) to setTargetSize, which clearly specifies the
behavior.
Rename setResize(int sampleSize) to setSampleSize.
Hide getSampledSize, which looks too similar to the newly named
setSampleSize. In addition, b/76448408 suggests hiding it. It isn't
really necessary anyway, since a client can just call setSampleSize - no
need to query and call setTargetSize manually.
Since there is no way for a client to know that a RAW image couldn't be
decoded to the desired size (could previously be done with
getSampledSize), make setSampleSize do the extra scaling. This is a
better API anyway.
Change-Id: I84c29fdc6bdfb999a7f712fdc069304ae9676ba6
Bug: 73788969
Test: I501e8b76aacd785cb994165ab01dc1b39fea3a1c
Move them into ImageDecoder.DecodeException, which is where they are
actually used. This also provides some more context, so that the prefix
"ERROR_" is no longer necessary, fixing the redundancy/awkwardness in
ERROR_SOURCE_ERROR. Further rename that to SOURCE_MALFORMED_DATA, which
is more descriptive, and does not imply a Java Error.
Change-Id: Ied17ad343650f9c33d9a35b0f9d00ccc22264bd6
Bug: 73788969
Test: If9e27a6ce2604128a619bc4843d62711f94b4d87
Add a new Exception subclass that contains information about the type of
error, and the original Exception, if any. Remove the old
IncompleteException class. If the decode creates a partial image, pass
the information up to Java, where we create the new Exception and pass
it to the callback and/or throw it. Rewrite nDecodeBitmap to always take
the ImageDecoder as a parameter for this callback, and simply use a
boolean to determine whether to call onPostProcess
Check for exceptions in some overlooked cases in native code, and
route to the new type.
Remove FIXME to avoid parsing the whole image. In my limited testing,
it didn't seem to speed anything up, and this should be called in a
background thread anyway. Parsing now also ensures that we've read the
stream when we can have a chance to handle the exception from the right
place.
Remove fixme for b/70626068, which has been marked as WontFix.
Add a TestApi for testing an Exception thrown by an InputStream.
Remove onPartialImage from hiddenapi-light-greylist.txt to fix the build
error this change introduces. onPartialImage was erroneously added to
the list.
Change-Id: I12f69857328e63c993bd669412b06addeb6a74f1
Bug: 74061412
Bug: 73893665
Test: Manual, I5669a97c70d726826c5c00bc1413c2f97d95d88c
ImageDecoder typically does not scale a Bitmap up to handle density.
This saves memory, and we already handle the density by scaling at
draw time. But some apps rely on the size of the Bitmap without taking
density into account. For backwards compatibility, on apps that are
built for a pre-P version of Android, scale up in ImageDecoder.
Change-Id: I9991d1286e386b47fc57bcfbf0c6652beb1a53ef
Bug: 74545298
Test: I6a633553bbb5ff26d84aaf5371b8b43a770afd4f
This allows using ImageDecoder to decode a file in the "assets"
directory of an app.
Change-Id: I2193f052cc2e16c55c7f68f7e51e07cd24ee4df9
Bug: 74545298
Test: Ibc283c2e8aee999e951de51f3a43b581a765aaf5
Although resources can already be accessed with ContentResolver + URI,
this allows a simple method to do the same.
Change-Id: I1bf698f36d5540f6de7cb9957e4223123d0f4331
Bug: 73788928
Test: I1606cbb4e71579160ffaef12c1ed738fad882cd1
This will allow Kotlin developers to treat the setters as properties.
Part of the motivation for the rename is that "getAsAlphaMask" sounds
like it returns an alpha mask itself. Rename both to
_etDecodeAsAlphaMask.
Change-Id: I8f9b04f8381840490b662c3bcd37a95442af8110
Bug: 73788928
Test: No change in behavior; no new tests.
There is already an overload for both decodeDrawable and decodeBitmap
that allows not using an OnHeaderDecodedListener, so require calls to
the method that includes a parameter for it to contain a non-null
version.
Throw an exception if OnHeaderDecodedListener is null. Move
implementation to Impl methods to share code without lint warnings.
Rename the non-static decodeBitmap to decodeBitmapInternal, to
distinguish it from the others.
Change-Id: I12c0a35786d8d1267044ac09b5c9203cdfb7175a
Bug: 73788928
Test: No change in behavior; no new tests
This will allow the generated JavaDocs to include these in setAllocator.
Change-Id: Icd109ddf45e8809da1a0980924a6f4feccefcac2
Bug: 73788928
Test: I7d5082ba7319c6c069dde5d0efb22af6e92dd243
This way the input's position is unaffected. Update the docs to reflect
the new behavior.
Change-Id: I7212948ee289ea8da1be9fe81d3f4bc9296e3e61
This reverts commit ac9c8f7c1e.
Bug: 73083791
Bug: 73364985
Don't scale NinePatchDrawable if bitmap has no density (including fix
for 73364985).
Fixed bugs around density and input streams.
Update PointerIcon to account for the fact that BitmapDrawable no longer
scales its Bitmap up at decode time. PointerIcon now handles the
scaling. This is necessary because PointerIcon never draws its Bitmap.
Instead, native code uses the Bitmap's internal SkBitmap without
accounting for density.
Test: Ran CTS:
- CtsUiRenderingTestCases
- CtsGraphicsTestCases
- I2d3976061d164ab4d58209db1320917f272a1958
- CtsViewTestCases
- ThemeHostTests
Change-Id: I3e0c11195622d65f084ce79dad887504630177ca
