When a blacklist is set, we must not use driver package for those applications
on the blacklist.
BUG: 120869311
Test: Build, flash, boot. Verify with command line.
Change-Id: I1c9f10a3086007038c328a20346ffadeff1861ae
Merged-In: I1c9f10a3086007038c328a20346ffadeff1861ae
This is to avoid framework crash when application used
the recycled bitmap memory in createBitmap.
Bug:123656975
Change-Id: I98f93ce48c7bc91913d0b31bca1dc0a10eb319d7
Members modified herein are suspected to be false positives: i.e. things
that were added to the greylist in P, but subsequent data analysis
suggests that they are not, in fact, used after all.
Add a maxTargetSdk=P to these APIs. This is lower-risk that simply
removing these things from the greylist, as none of out data sources are
perfect nor complete.
For APIs that are not supported yet by annotations, move them to
hiddenapi-greylist-max-p.txt instead which has the same effect.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: Ia937d8c41512e7f1b6e7f67b9104c1878b5cc3a0
Merged-In: I020a9c09672ebcae64c5357abc4993e07e744687
Based on some analysis, these fields/methods are likely false positives.
Set maxTargetSdk=P so that any apps using them are required to migrate off
them in future. See the bug for more details.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Merged-In: I719b5c94e5b1f4fa562dd5d655953422958ad37e
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
(cherry picked from commit 8c854f86a477fbbee38092f449333e1425e5cd7e)
The transfer function of Display P3 should be sRGB transfer function,
previously we defined f as 0.039, however, the sRGB transfer function defines f
as 0.04045. This patch fixes it.
BUG: 116726537
Test: Build, flash and boot
Change-Id: I247092d8ce939aa743f23a1f8688cbaf0874fb99
Merged-In: I247092d8ce939aa743f23a1f8688cbaf0874fb99
For all remaining unannotated code.
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: I32861fa341a08f11a9c50c07a1ef7404dadf6bb6
Merged-In: I67c8b71ea535ebffb10bf577948bd4ccb8ca069d
Bug: None
Test: I solemnly swear I tested this conflict resolution.
Change-Id: Id12be0fe86a73fcf39cc2c82a1f681df910fc03f
Merged-In: I7fc1162d2c63df8751a4660607e8ce72070efed8
Bug: None
Test: I solemnly swear I tested this conflict resolution.
Merged-In: I7fc1162d2c63df8751a4660607e8ce72070efed8
Change-Id: I0e5a5d8fda273644e8c592ce7d059e508870085e
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
Merged-In: I7fc1162d2c63df8751a4660607e8ce72070efed8
Change-Id: I5d7739d2d1fc7bb12ee059bcc2a9ac9017ca35fb
Picture#draw() will silently due an #endRecording() if it
wasn't called. Bitmap.createBitmap doesn't do this until
after it's too late.
So do an up-front #endRecording() to ensure state is
good to go
Bug: 80539264
Test: HardwareBitmapTests#testReadbackThroughPictureNoEndRecording
Change-Id: Ic66c41462e88880b73c5093d7541c4ce3d71adeb
Bug: 78866720
Test: Manual + systrace; existing CTS
Previously, we set hasAnimations to true when the AnimatedImageDrawable,
so that we would get a call to redraw. But if the image does not need to
show its next frame yet, the redraw was unnecessary.
Instead, add a new field to TreeInfo::Out, representing the delay time
until the image will need to be redrawn - i.e. when the duration of the
current frame has passed. Each call to prepareTree will post at most one
message to redraw, in time for the earliest animated image to be
redrawn. Post the message for one rendered frame ahead of time, so that
when it is time to show the next frame, the image has already gotten the
message to update.
On a screen with a single animated image, this drops the number of calls
to dispatchFrameCallbacks to as infrequent as possible. It is called
only when we need to draw a new frame of the image. On a screen with
multiple animated images, the calls may be redundant, but they will not
be more frequent than they would be without this change.
Switch to nsecs_t and systemTime internally, matching the rest of HWUI.
Remove mDidDraw and related. Its purpose was to prevent advancing the
animation while the image is not being drawn. But it isn't really
necessary. If it's not drawn, onDraw is not called, which is where we
trigger decoding. And onDraw already has a defense against getting too
far ahead - if its timer indicates that it should skip a frame or show
it very briefly, it will back up its timer. More importantly, mDidDraw
caused a bug, when combined with less frequent redraws. If the display
list containing the drawable doesn't need to be redrawn for other
reasons, the drawable's timer never advanced, so its animation stopped.
Fix software drawing. Compute the milliseconds in the future to draw the
next frame, and add that to SystemClock.uptimeMillis() to compute the
time to pass to scheduleSelf.
Change-Id: I13aab49922fa300f73b327be25561d7120c09ec4
Works around a source of jank when drag resizing in split
screen mode: instead of immediately resizing the (potentially
numerous) invisible secondary stacks, we defer that until
the user lets go of the handle.
Change-Id: I3b9faa83005fa86185d4e51b2849e3a826b7f6a9
Fixes: 78214347
Test: Open a gazillion (resizeable) tasks. Enter split screen. Drag handle, verify there is no jank
Test: atest RectTest
StackView currently expands the clip of the view which is a prohibited
operation in API Level 28. This CL currently allows this specialized
use case to work in this situation until we can update StackView
to not clip to its bounds and then just intersect with this clip
provided by its parent.
Test: CtsWidgetTestCases
Bug: 77642155
Change-Id: Icc003ad3946bb226368ec2030d4707753f4f55e9
Bug: 73088142
Test: Test app at https://buganizer.corp.google.com/issues/73088142#comment6
Test: GridWidgetTest.testItemDecorationAndMarginsAndOpticalBounds
In computeBitmapSize, treat padding as a size in scaleFromDensity. This
results in rounding instead of truncating. This matches the way optical
insets are handled. It also matches the padding we would have gotten if
we had scaled at decode time.
Change-Id: I7d3a83ba824b8dc81187ce9b2d9889d4a87f88ac
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
The saveLayer APIs are restored from @removed but will treat input
as ALL_SAVE_FLAGS and generate exceptions on newer API levels.
We internally used these calls in one situation that now use a
different @hide API to support the previous behavior until we
refactor that code.
Partial revert of "Remove deprecated android.graphics.Canvas APIs"
This reverts commit 7b837616ae88cbdaf12600cee23b5188e5531937.
Bug: 77276963
Bug: 73777445
Test: CtsGraphicsTestCases
Change-Id: I7acd4ffd5ac41a58d2be8b48cf50119c2b896708
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
