Got a little too aggressive about cleaning up service state; need to
avoid removing services from an app until we are in the second loop
doing the final cleanup, otherwise we can leave services around with
restarting their process.
Also fix crash:
W/BinderNative( 667): Uncaught exception from death notification
W/BinderNative( 667): java.lang.ArrayIndexOutOfBoundsException: length=0; index=0
W/BinderNative( 667): at android.util.ArraySet.valueAt(ArraySet.java:301)
W/BinderNative( 667): at com.android.server.am.ActiveServices.killServicesLocked(ActiveServices.java:2069)
W/BinderNative( 667): at com.android.server.am.ActivityManagerService.cleanUpApplicationRecordLocked(ActivityManagerService.java:12412)
W/BinderNative( 667): at com.android.server.am.ActivityManagerService.handleAppDiedLocked(ActivityManagerService.java:3596)
W/BinderNative( 667): at com.android.server.am.ActivityManagerService.appDiedLocked(ActivityManagerService.java:3744)
W/BinderNative( 667): at com.android.server.am.ActivityManagerService$AppDeathRecipient.binderDied(ActivityManagerService.java:1024)
W/BinderNative( 667): at android.os.BinderProxy.sendDeathNotice(Binder.java:493)
W/BinderNative( 667): at dalvik.system.NativeStart.run(Native Method)
Issue detail:
Assume X, Y are non-fullscreen activities.
a.Home starts an activity X in task A in application stack.
b.X starts an activity Y in <task A> or <new task B>
c.Activity X will be invisible.
How to fix:
Because the function "isActivityOverHome" means an activity is able to see home.
But there may have many non-fullscreen activities between the top non-fullscreen activity and home.
If flag "behindFullscreen" is set, those middle activities will be invisible.
So it should only take care from who is adjacent to home.
Then check two flags frontOfTask(task root) and mOnTopOfHome for constraining the condition.
Change-Id: I60bcea304976414e44835a0a38675aae365e9e19
Code that expected a single top level element in an XML file
was doing something like :
while (type != START_TAG) { next(); }
This would loop forever when the XML being parsed was empty,
where each call to XmlPullParser.next() would return END_DOCUMENT.
bug: https://code.google.com/p/android/issues/detail?id=64173
Change-Id: I7543203e976a8999ae471a6c2d629249a87011bb
If there is input to be handled during finish activity we can get a
keydispatching timeout ANR. The reason is that finish activity is some
times not possible, and the activity is instead put on a finish queue.
The activity will then be finished sometime in the future. When we add
the activity to the finish queue, key dispatching is paused, and there
is an ANR timer waiting for it to be resumed again. Since it can take a
long time before the activity is actually finished, we need to resume
the key dispatching to avoid the ANR.
Change-Id: Icea4ab3b5ad05c8bfbadf8f5cece1a59ec621469
In ActivityTask.moveTaskToBackLocked NullPointerException may occur
when moving back with only current Activity in stack. This due to a
condition that may trigger despite a TaskRecord being null and then
attempt accessing the TaskRecord.mOnTopOfHome variable.
TaskRecord task may be set to null when no resumed activity remain.
Resolved by assuring that flag mOnTopOfHome is instead set to false
for current TaskRecord in case where there are no remaining activities
above home.
The above bug has already been corrected in the following commit,
ada62fca51, but it does not set the
cottect value to mTopOfHome for the current taks, see below.
Variable mOnTopOfHome will not be set to false in situations where
stack is of size 1 or less and task is null, perhaps from already
having finished current activity.
To avoid current TaskRecord maintaining value mOnTopOfHome to true
after launching Home this variable is set to false.
Impact should not be major due to correction earlier that makes sure
that there is always a TaskRecord.mOnTopOfHome set to true above Home
activity but if not correctly set for current task still gives a
possibility of bad behavior.
Change-Id: Ie86ad99c188aaa05b0de9d58eaa16c42b6fc4341
Whoops persistent processes are, well, persistent. Don't remove
services from them. We'll be keeping that process record around.
Change-Id: I29e9fb6f704efdf0caad5e0307a7adbb416eed3b
BatteryStatsImpl can reset its collected data, including
removing a BatteryStatsImpl$Uid$Proc object. If a ProcessRecord
has a direct reference, then the battery stats for a process
will be recorded in an old Proc object and prevent GC, causing
a memory leak.
bug:11087238
Change-Id: I19a9cd9d8361c10446a8ebdd5c0860b56c442209
It looks like we could add services to the restart list because
they end up left in the process's list of running services after
they have been removed from the main activity list, and we can
trip up on them there when the app is being force stopped.
Change-Id: I79805b67fcf5b593430dc5c856c97927e1a54a57
User removal or eviction inherently races with broadcast delivery. This
patch introduces a latest-possible recheck of the availbility of the
target application before attempting to send it a broadcast.
Once the process has actually been spun up the system is essentially
committed to presenting it as a running application, and there is no
later check of the availability of the app: the failure mode for
continuing to attempt delivery is a crash *in the app process*,
and is user-visible.
We now check the app+userid existence of the intended recipient
just prior to committing to launch its process for receipt, and
if it is no longer available we simply skip that receiver and
continue normally.
Bug 11652784
Bug 11272019
Bug 8263020
Change-Id: Ib19ba2af493250890db7371c1a9f853772db1af0
If a window claims to handle its own configuration change then we
won't destroy and recreate its window on a configuration change.
Normally that recreation triggers the first layout following
orientation change because mHaveFrame is false. Windows that handle
their own configuration changes never got a relayout pass following a
change in orientation.
This change passes the configuration changes that an application
handles into the AppWindowToken. If the app says it handles
orientation or screen size changes then a relayout will occur when the
configuration has changed.
Fixes bug 11647107.
Change-Id: Ie8d49fd050442ebbdcf0b805087894e3a2fc4be9
Tighten up some flows to try to avoid any chance of leaving
a restarting service on the list, add a log to the only remaining
place I could find that we could get in to trouble for some
reason.
Change-Id: Iffb9be9d97deefc6cf0c5790eedfeb6e4e8a36bc
This happened:
android.util.Log$TerribleFailure: Adding dependent process ProcessRecord{43c7a120 0:com.google.android.gms/u0a7} not on LRU list: service connection ConnectionRecord{437c16e0 u0 CR ACT com.google.android.gms/.icing.impl.IndexService:@436ba7f8} from ProcessRecord{43c64208 4908:com.google.android.googlequicksearchbox:search/u0a19}
at android.util.Log.wtf(Log.java:290)
at android.util.Slog.wtf(Slog.java:82)
at com.android.server.am.ActivityManagerService.updateLruProcessInternalLocked(ActivityManagerService.java:2290)
at com.android.server.am.ActivityManagerService.updateLruProcessLocked(ActivityManagerService.java:2508)
at com.android.server.am.ActiveServices.updateServiceClientActivitiesLocked(ActiveServices.java:636)
at com.android.server.am.ActiveServices.removeConnectionLocked(ActiveServices.java:1656)
at com.android.server.am.ActiveServices.unbindServiceLocked(ActiveServices.java:860)
at com.android.server.am.ActivityManagerService.unbindService(ActivityManagerService.java:12773)
at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:869)
at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:2071)
at android.os.Binder.execTransact(Binder.java:404)
at dalvik.system.NativeStart.run(Native Method)
Because of this earlier:
11-09 18:02:19.126 W/ActivityManager( 809): Exception when starting service com.google.android.gms/.icing.impl.IndexService
11-09 18:02:19.126 W/ActivityManager( 809): android.os.DeadObjectException
11-09 18:02:19.126 W/ActivityManager( 809): at android.os.BinderProxy.transact(Native Method)
11-09 18:02:19.126 W/ActivityManager( 809): at android.app.ApplicationThreadProxy.scheduleCreateService(ApplicationThreadNative.java:850)
11-09 18:02:19.126 W/ActivityManager( 809): at com.android.server.am.ActiveServices.realStartServiceLocked(ActiveServices.java:1384)
11-09 18:02:19.126 W/ActivityManager( 809): at com.android.server.am.ActiveServices.bringUpServiceLocked(ActiveServices.java:1294)
11-09 18:02:19.126 W/ActivityManager( 809): at com.android.server.am.ActiveServices.bindServiceLocked(ActiveServices.java:755)
11-09 18:02:19.126 W/ActivityManager( 809): at com.android.server.am.ActivityManagerService.bindService(ActivityManagerService.java:12766)
11-09 18:02:19.126 W/ActivityManager( 809): at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:859)
11-09 18:02:19.126 W/ActivityManager( 809): at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:2071)
11-09 18:02:19.126 W/ActivityManager( 809): at android.os.Binder.execTransact(Binder.java:404)
11-09 18:02:19.126 W/ActivityManager( 809): at dalvik.system.NativeStart.run(Native Method)
Not clearing the service's app pointer.
Also fix this wtf where we were not clearing the started state of
a ServiceTracker when its process goes away. (This was like this
because we used to want to leave the started state so that we can
know the process is trying to restart. But now that have a new
explicit restarting strate, there is no need to leave it.)
android.util.Log$TerribleFailure: Service owner ServiceRecord{436f5168 u0 com.dirtywaterlabs.uberhype/com.dirtywaterlabs.musichype.MDService} cleared while started: pkg=com.dirtywaterlabs.uberhype service=com.dirtywaterlabs.musichype.MDService proc=ProcessState{42bf4bb8 com.dirtywaterlabs.uberhype:remote/10115 pkg=com.dirtywaterlabs.uberhype}
at android.util.Log.wtf(Log.java:290)
at android.util.Slog.wtfStack(Slog.java:86)
at com.android.internal.app.ProcessStats$ServiceState.clearCurrentOwner(ProcessStats.java:2989)
at com.android.server.am.ActiveServices.serviceDoneExecutingLocked(ActiveServices.java:1821)
at com.android.server.am.ActiveServices.serviceProcessGoneLocked(ActiveServices.java:1779)
at com.android.server.am.ActiveServices.removeConnectionLocked(ActiveServices.java:1693)
at com.android.server.am.ActiveServices.killServicesLocked(ActiveServices.java:2028)
at com.android.server.am.ActivityManagerService.cleanUpApplicationRecordLocked(ActivityManagerService.java:12424)
at com.android.server.am.ActivityManagerService.handleAppDiedLocked(ActivityManagerService.java:3605)
at com.android.server.am.ActivityManagerService.appDiedLocked(ActivityManagerService.java:3750)
at com.android.server.am.ActivityManagerService$AppDeathRecipient.binderDied(ActivityManagerService.java:1026)
at android.os.BinderProxy.sendDeathNotice(Binder.java:493)
at dalvik.system.NativeStart.run(Native Method)
Change-Id: I25a3fb678b5365254490cd5509b558348655b589
When a new task is being created solely to protect the system from an
old task going away, save the info from the old task and use it when
creating a new task.
Fixes bug 11615548.
Change-Id: Ibc3fd15ec4b0d76bce30381fbd83b6899f6a9023
When the home activity launches a non-fullscreen activity as part of
its own task then ensureActivitiesVisibleLocked() must continue past
the launched activity when determining activities to show and hide.
Stopping at the non-fullscreen activity leaves the fullscreen home
activity hidden.
Fixes bug 11555762.
Change-Id: I9058d8cde3a41cb7f9b1f97e5c0cb32e9b0f5af7
The method ActivityRecord.setTask() removes the ActivityRecord from
its old task's mActivities ArrayList. In jb-mr2 it did not have this
side effect (there was no mActivities) so calling it twice was not a
problem. This fix causes setTask to only be called once for the target
activity.
Fixes bug 11557835.
Change-Id: If2b6d4b297e86130009713efe6891a24fad3dd15
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
