This hopefully handles the remaining finalizers in frameworks/base
that didn't guard against calls from other finalizers after being
finalized.
The goal here is to reduce the possible corruption causes we have
to think about by a few.
If any of theses are either very frequently used, or use large
Java (as opposed to native) objects, we should probably convert them
to NativeAllocationRegistry instead. But that's more work.
Bug: 18178237
Change-Id: I79bc0e8fa20af8f340418a6226022e0294d77f02
The body of {@code} must not be HTML escaped. This is one of
several changes that fix the source in conjunction with a
doclava fix.
Bug: 25757239
(cherry-picked from commit 71fbb81b14958b80fe55738607740c6630e4e9da)
Change-Id: I19dafddc6501be6fee362c396ac5bbdc934ae39d
The goal for this change is to get the timing for animation update. Since
AnimatorSet does not support update listeners, we have to go with the a different
approach, which sets up a value animator that runs between the start and end of
the AnimatorSet. We can then get the animation update timing from the ValueAnimator.
Bug: 26329675
Change-Id: Ibe7fce81eb6da5e05c87a732c1d3bc904b4e5e6f
(cherry picked from commit I378a0964da8f7090f65f6b56275a302e30668835)
Many classes in graphics/java and elsewhere deallocate native memory
in a finalizer on the assumption that instance methods can no longer
be called once the finalizer has been called. This is incorrect if
the object can be used, possibly indirectly, from another finalizer,
possibly one in the application.
This is the initial installment of a patch to cause such post-finalization
uses to at least see a null pointer rather than causing memory corruption
by accessing deallocated native memory. This should make it possible to
identify and fix such finalization ordering issues.
There are more graphics classes that need this treatment, and probably
many more in other subsystems.
This solution is < 100% effective if finalizers can be invoked
concurrently. We currently promise that they aren't.
(In my opinion, the real cause here is a language spec bug. But that ship
has sailed.)
Bug: 18178237
Change-Id: I844cf1e0fbb190407389c4f8e8f072752cca6198
When a GradientDrawable is loaded from scratch, initializeWithState()
is called with mColors == null. This sets mFillPaint's color to
0x00000000 -- transparent. mColors is then properly set in inflate(),
but mFillPaint is not updated there. It will be updated eventually
through a mutate() or ensureValidRect() call, but that's sometimes too
late.
In our case, a wrapping StateListDrawable called getOpacity(), and
since it caches the result, it never got updated.
This doesn't cause any problems on preloaded GradientDrawables, since
the new GradientDrawable created when fetching a preload will call
initializeWithState() in its constructor, fixing the GradientState.
Change-Id: Ic8caa7c6a7c1d4dae5ff31ae943831bd2e014f79
Bug: 22214367
Previous releases would let the getters on a recycle()'d bitmap to still
work despite being firmly in undefined behavior per the documentation
on Bitmap#recycle().
As there are apps relying on this, yell very loudly about this behavior
in the log and give them a bit of time to fix it
Change-Id: I857be7e74cb217877973d9c6f03eb761d12fd056
Before, the VectorDrawable is behaving like BitmapDrawable inside a ImageView,
and it can be blurry due to scaling.
Now apply the scaling information to the cached bitmap, then the size of bitmap
will match the ImageView's screen size. Therefore, no blurry any more.
b/18185626
Change-Id: I979cef3b5178a9bd37ee6cc776df3361ca47c803
Bug: 22289362
It's pretty common for ImageView#setBitmap to be called
repeatedly. Avoid re-creating the BitmapDrawable in this scenario
as that has high object churn of semi-expensive objects like
Paint.
Change-Id: Ib77719cd0366d02c1a42f774850bf3b9caa9c288
Also clears DrawableContainer's futures list when it's no longer needed,
correctly sets deep copy of state set in StateListDrawable, makes some
private methods into package-protected to avoid thunk, and propagates
state to StateListDrawable's super class so that getState() has correct
information.
Bug: 21840003
Change-Id: I0d4232807f280d663c03b4a80e4aab8626806440
Avoids many copies during IPC and duplicate Java heap consumption in
system_server, SystemUI, etc.
Bug: 18386420
Change-Id: Id5ac9406062d472f7848009d65f12131f5f4dac9
Notifications in which the icon resource ID is changed after
Builder.build() is called (even, and particularly, as the
last step in the current implementation of
setLatestEventInfo()) were not having their icons properly
parceled. In these cases we now attempt to catch this at
parcel time and construct the necessary Icon object.
But wait! Parceling does not require a Context. So we don't
actually know which package to load the resource from.
Therefore we now allow an Icon to be constructed with an
empty ("") package name, which allows us to complete this
parceling task despite the fact that a Notification does not
know its own package name. (In case you attempt to load a
drawable for such an Icon, loadDrawable will spot the ""
package and instead substitute the Context from its
parameters to try to load the resource.)
As it happens, even though the Notification does not know
its own package name, BaseStatusBar does, because it was
provided at NM.notify() time and is therefore included in
the StatusBarNotification structure. So we can actually
patch up the Icon (if it is TYPE_RESOURCE) and be sure to
get the icon loaded out of the correct package.
While we've got the hood open, this change fixes a couple of
related problems:
• Foreground service notifications synthetically
constructed for naughty icon==0 notifications (which we
are still allowing...FOR NOW) were losing the
FLAG_FOREGROUND_SERVICE flag (because we're
re-build()-ing them from scratch rather than rewriting
the provided Notification object). Now we set the flag
and hang onto the new notification for next time
setForeground() is called.
• We now allow media notifications to avoid getting bumped
to the top of the notification list if they're
PRIORITY_MIN. You might want to do that, I guess?
Bug: 21333763
Change-Id: Ia5d1f1acb594c7677bcc75ee3d624da4ffca671f
Remove unnecessary lines setting target density on bitmap and nine patch,
since we'll do this later in inflate().
Bug: 21774853
Change-Id: I5ea316bee81f82192ce20f2f1bee0e62c6ec8ccb
Docs for translucent-vs-transparent-vs-opaque were confusing, especially since
the definition for those constants in PixelFormat are not the same as how they're
actually used in Drawable. This fix simply adds clarifying text to the method
comment for getOpacity().
Issue #21158891 Better document Drawable#getOpacity
Change-Id: I94725592f85e5d7874e3a3ac1c5bab969163fbf0
