Unfortunately there is no good way to deal with products in the link phase.
Products are like preprocessor defines in that they are processed early
and change the composition of the compiled unit.
Change-Id: I6d5e15ef60d29df8e83e059ba857c09333993779
An early refactor. Some ideas became clearer as
development continued. Now the various phases are much
clearer and more easily reusable.
Also added a ton of tests!
Change-Id: Ic8f0a70c8222370352e63533b329c40457c0903e
PathMeasure is needed to use the trimPath* properties in drawables.
These properties are used in the vector drawable for indeterminate
progress bars in Material so this is needed to be able to render them
correctly in the preview.
PathMeasure makes use of Path.approximate to calculate which segments to
paint.
Change-Id: Ic513f0a30a6aac0317f7c13cd75e9154c37405c8
A change was made back in ICS that prevents the view hierarchy from rendering
during window animations. Specifically, it allows the hierarchy to render once (to draw
the results of its first layout), but further drawing is suppressed at the
ViewRoot/performTraversals level until the window animation is complete.
This change was introduced to avoid jank problems that were resulting from
thrashing the GPU by issuing drawing commands from multiple processes simultaneously,
and limited the number of rendering processes to mainly the system server (and
possibly the System UI), which allowed window animations to be much smoother.
This fix contributed to another source of jank, however, in which applications
which attempt to animate when they first appear will not render any frames of
animations until the window animation is done, resulting is a snapping to the resulting
state once the window animations are complete.
Meanwhile, hardware has gotten faster and GPUs have gotten better, and it is time to
revisit this logic. This change disables the earlier fix and allows view hierarchies
to draw normally, regardless of whether window animations are taking place.
Issue #22232939 Remove flag that prevents drawing during window animations
Change-Id: I4c960180771ff09a7088abd77b437586e835a991
When the text properties of the Paint object are updated, or when .set()
is called, updateFontObject will be called. This method is currently at the
top of the methods for number of allocations.
This CL reduces the number of calls to updateFontObject by a 90%,
reducing the number of Font allocations.
Change-Id: I3e232f9e6e230da8ecdd19921faadf2d3f4ff763
Add a wrapper around the PullParser to support stripping out databinding
parts.
Bug: http://b.android.com/187428
Change-Id: I88080d8f4108cb5ae27a137ad20c5dd7d516f3ea
The only time AppWindowToken.willBeHidden is used is for determining
if the app should contribute to calculating orientation. In the same
check AppWindowToken.hiddenRequested will be or-ed with willBeHiden,
so it's enough that hiddenRequested to be set.
The only place where willBeHidden is set, is right before
WMS.setAppVisibility is called, which will set hiddenRequested.
Because of this willBeHidden is unnecessary.
Change-Id: Iea35f39f72e7f0dcd76205ef580f3a74cac72d08
Add methods installPackageAsUser and installExistingPackageAsUser
and deletePackageAsUser and getPackageInfoAsUser.
BUG:23516394
Change-Id: I15e30d2ec45ab18c7f8c0ac02cfc617c50fedb44
Usually scrollBy(0, 0) won't have any effect but when called on the
NumberPicker but, in some cases, it seems to cause an endless loop.
When called from layoutlib, this will hold the read lock causing all
operations trying to acquire the write lock to block forever.
Bug: http://b.android.com/182506
Change-Id: Ib25427d3f32d804d1c481d979795eee71fbdbc6d
We crop windows to their stack bounds when the docked stack
exists. We don't want to do this for the home activity since
the docked stack isn't visible when the home activity is visible.
Change-Id: Ibb3157dabbb6c979358ddc2098a01c6ddf6540e8
