The android package is now a special case, not being added to the package list
when creating a multi-process component. There is no need, since this package
is actually the framework itself which must be loaded in every process.
Also cleaned up some of the procstats dump output to help see what is going
on here.
Change-Id: If65d35ecd562f3154bdebfded69c454af6ce8c96
Although the IME windows are now allowed to extend into
the nav bar, some IMEs were making assumptions about
computed insets based on the height of the content view.
So our navigation bar view (opaque view blocking the nav bar
area to avoid the island effect when transparent) needs to live
above the content view in the hierarchy, making the content view
the same height as it was before.
A surgical spot to put the guard view is up at the root view
(PhoneWindow.DecorView). fitSystemWindows is always called since
this view is not recreated, and the layout is stable: waiting until
the IME is attached to the window is too late to add a guard view.
This is above the screen_* layouts, so will work without having to
touch all of them. And it only affects windows of TYPE_INPUT_METHOD.
Bug:11237795
Change-Id: I6a93f30aec83f1cecfb854073046cbc87ab4aa66
While under heavy system load, keyguard was able to create widgets before
before ActivityManagerService was ready. The result was a race
between keyguard adding widgets and ActivityManagerService being
ready to send broadcasts.
This fix provides keyguard with an additional signal to know when
the system is booted and widgets are safe to load.
Fixes bug b/11217169
Change-Id: I7a714d65b068678f961e52bdde4e1c20f9c287f0
...bad cleanup of crashing processes
We now have a special path for crashing processes, to silently
clean up their state.
Also some tweaks to Log/Slog.wtf to get better stack crawl
summaries in APR.
Change-Id: Ieced26989907a6e7615b6fa033813fced78d7474
InputMethodService will recreate the entire layout on config changes.
Until the system insets change again, the new instance will not
hear about the insets.
This change ensures fitSystemWindows is called at least once for all
input method root views that are added to a window.
Bug:11174545
Change-Id: Id0f02f32c0d6e9c2d6b6aeef74a12a13acfbb9e6
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