When I cleaned up how we maintained the lifecycle of the tracker with a
service, I broke most tracking of the service restart state. (Since at
that point the service is no longer associated with a process, so I
must clean up the tracker state). This change introduces a new special
case for interacting with a service tracker to explicitly tell it when
a service is being restarted. It also fixes how we update the process
state when services are attached to it, so it goes in and out of the
restarting state correctly.
In addition:
- Maybe fix issue #11224000 (APR: Dependent processes not getting added
to LRU list). We were not clearing ServiceRecord.app when bringing
down a service, so if for some reason there were still connections to
it at that point (which could happen for example for non-create bindings),
then we would so it when updating the LRU state of that client process.
- dumpsys procstats's package argument can now be a package or process
name, and we will dump all relevent information we can find about that
name.
- Generally improved the quality of the dumpsys procstats output with its
various options.
- Fixed a bug in ActivityManager.dumpPackageState() where it would hang if
the service was dumping too much, added meminfo to the set of things
dumped, and tweaked command line options to include more data.
- Added some more cleaning code to ActiveServices.killServices() to make
sure we clean out any restarting ServiceRecord entries when a process is
being force stopped.
- Re-arranged ActiveServices.killServices() to do the main killing of the
service first, to avoid some wtf() calls that could happen when removing
connections.
Bug: 11223338
Bug: 11224000
Change-Id: I5db28561c2c78aa43561e52256ff92c02311c56f
HSPA+ was being shown as connection type other in battery
statistics because it was not updated when TelephonyManager
was changed.
Bug: 11552902
Change-Id: I85ce7c393bf93010a4ac8437f14684015ad0391a
When opening a submenu from a popup in ActionMenuPresenter, delegate
the submenu callbacks to the presenter callback registered on the
ActionMenuPresenter. This allows menu visibility callbacks to
propagate properly so that apps that hide their action bars after a
timeout can detect open menus that are deeply nested.
Bug 11429613
Change-Id: I3332886f08d4f9010f0875057c457566301d12ec
Some stray code from a previous change caused an erroneous content
description to be set on the wrong view in the action bar. Correct
this and sync with the right behavior.
Bug 10969992
Change-Id: I4deaa3528b4bc222e25354679fa93f8316fa2d70
This prevents Keep from being selected automatically when shown in the Share dialog
if Keep was previously chosen by the user as Always use for a send action.
This was a regression introduced by the new intent disambig behavior.
Bug: 11294904
Change-Id: I6745060a8ee0a6d680e657b55ee46aaec27bbacb
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
