Since action bar transitions are turned off again for now, re-enabling
item view recycling fixes an unfortunate regression with submenus.
If a menu view is invalidated while a submenu is open we need to keep
its anchor consistent. With view recycling active we preserve status
quo and the previous anchor view instance for the popup window remains
in place.
In the future this will need to get more sophisticated;
ActionMenuPresenter will need to re-parent an open submenu against the
proper anchor view by menu item id. But that is a change for another
day.
Bug 11174504
Change-Id: I7e8a444f6996ec95417d20e87938f496e9c3a4dd
Instead of a custom onDraw in order to stay 100% in sync with abrupt
layout changes.
Also use the unrestricted layout bottom to avoid unnecessary
fitSystemWindows churn.
Bug:11162351
Change-Id: If9bb9a52d503e348d642bf1238f75c4a418ad805
Layout IMEs below the nav bar, offset by bottom padding and
associated guard rectangle with a black background to ensure
they do not appear as islands during transitions.
This makes it safe to remove the SystemUI forced opaque transition
when showing an IME, making the overall transition less expensive,
quicker and smoother overall.
Bug:11058746
Change-Id: I460912ee7c117480c57b947ed31eca330819f32c
Thanks to a measurement optimization in KK, the view recycling
behavior of ActionMenuPresenter could get into a state where the
resulting ActionMenuView had changed but no layout was
requested. Explicitly request a layout during menu update. Also fix an
ancient typo.
Bug 11047996
Change-Id: I6289fd2d142ac7d2101fbec6de19b7d3d7fbd6a2
On some display sizes, the wave animation was sometimes
running more than once, starting over in the center and animating
outward... partially.
The problem was that the calculations determining the alpha value
of the dots was returning bogus values when the display area was
large enough, which is why the bug is only on some devices.
This fix simplifies the math and ensures that the wave only animates
once, from start to finish.
Issue #11005936 regression on lockscreen animation for multi-wave widget
Change-Id: Id21a2e4d2271f01c82c4bc6e1f37d78e68b9b6e4
The main problem here was a mistake when turning a single process
structure to a multi-package-process structure with a common
process. When we cloned the original process state, if there were
any services already created for the process for that package, they
would be left with their process pointer still referencing the
original now common process instead of the package-specific process,
allowing the active counts to get bad. Now we switch any of those
processes over to the new package-specific process.
There was also another smaller issue with how ServiceRecord is
associated with a ServiceState -- we could be waiting for an
old ServiceRecord to be destroyed while at the same time creating
a new ServiceRecord for that same service class. These would share
the same ServiceState, so when the old record finally finished
destroying itself it would trample over whatever the new service
is doing.
This is fixed by changing the model to instead of using an "active"
reference count, we have an object identifying the current owner
of the ServiceState. Then when the old ServiceRecord is cleaning
up, we know if it is still the owner at that point.
Also some other small things along the way -- new Log.wtfStack()
method that is convenient, new suite of Slog.wtf methods, fixed
some services to use Slog.wtf when catching exceptions being
returned to the caller so that we actually know about them.
Change-Id: I75674ce38050b6423fd3c6f43d1be172b470741f
Not dealing with the case where there is a null list.
Also fixed some bugs I found while looking at this:
- When resetting the stats, we would use a newly computed time stamp
for the total durations rather than the one we used to reset the
proc/service entries. This would result in them being able to be
slightly > 100%.
- There was a bug in how we split a single process state into its
per-package representation, where we would but the cloned process
state into the new package's entry (instead of properly for its
own package entry), to be immediately overwritten by the new
process state we make for that package. This could result in
bad data for processes that have multiple packages.
- There was a bug in resetting service stats, where we wouldn't
update the overall run timestamp, allowing that time to sometimes
be > 100%.
- There was a bug in computing pss data for processes with multiple
packages, where the pss data was not distributed across all of the
activity per-package process states.
- There was a bug in computing the zram information that would cause
it to compute the wrong value, and then never be displayed.
Finally a little code refactoring so that ProcessState and ServiceState
can now share a common implementation for the table of duration values.
Change-Id: I5e0f4e9107829b81f395dad9419c33257b4f8902
Allow calling code to specify left/right/start/end gravity when
showing a popup attached to an anchor. This allows easy alignment of
either the right or left edges of the popup and anchor view.
Bug 10728401
Change-Id: Ie0844a04ea0576fa67b0972f5873aaa4c5b823f6
