| Age | Commit message (Collapse) | Author |
|---|
|
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
|
|
- Introduce concept of ActivityStacks residing on Displays and able
to be decoupled and moved around.
- Add a new interface, IActivityContainer for clients to handle
ActivityStacks.
- Abandon ordering of stacks based on mStackState and instead use
ActivityDisplayInfo.stacks<ActivityStack> ordering.
Progress towards closing bug 12078972.
Change-Id: I7785b61c26dc17f432a4803eebee07c7415fcc1f
|
|
StackBox is too constraining. Adding size and position to TaskStacks
directly makes stack positioning and management more flexible and
prepares for ActivityView.
Change-Id: I33c6b4e1c23a5a8069fd507c160bcb34e4d287b2
|
|
Change-Id: I829fe48e6ebcb819e260646bb19ac6ddfcf07f83
|
|
into klp-dev
* commit '1abead425c0e862e316e17521833a33d22e7a850':
Do not hold direct ref BatteryStatsImpl$Uid$Proc
|
|
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
|
|
started state while restarting" into klp-dev
* commit 'fbf4888d19b0c68d8004f9ad2423a583dc01178e':
Fix issue #11223338: Not retaining service started state while restarting
|
|
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
|
|
crashes when opened during..." into klp-dev
* commit '6d61faad436f3bae41c6008ffe3e03a19eb4c277':
Help out with issue #11497149: Clock app crashes when opened during...
|
|
...the repeated hour in DST transition
Record the last crash info that caused an app to be marked as a bad app.
Also for the battery work, add a system property tuning parameter to be
able to control the background service start delay, so we can easily
run experiments with it turned off if we want.
Change-Id: Ic33dc464d8011c918a39b912da09ea4f0fb28874
|
|
renderers seems..." into klp-dev
* commit 'de2d961ff83fbca65bebb9696551cbbc14cad6a5':
Fix issue #11168649: LRU logic for Chrome renderers seems...
|
|
klp-dev
|
|
...not to work on KitKat (was: Janky exit animation)
Reworking the LRU list (splitting it into an activity vs. empty
section) accidentally broken the old behavior of "client activity"
processes being prioritized with activity processes. In fact, we
were no longer marking "client activity" processes at all.
In this change, we rework how we manage "client activity" processes
by putting them on the main activity LRU section. This is generally
simple -- ActiveServices now keeps track of whether a process is
a "client activity" process based on its bindings, and updateLruProcess
treats these as regular activity processes. However, we don't want
to allow processes doing this to spam our LRU list so that we lose
everything else, so there is some additional complexity in managing
that list where we spread client activity processes across is so
that the intermingle with other activity processes.
The rest of the change is fairly simple -- the old client activity
process management is gone, but that doesn't matter because it wasn't
actually running any more. There is a new argument to updateLruProcess
to indicate a client process it comes from (since we now need to update
this based on bindings) which is just used to limit how high in the
LRU list we can move things. The ProcessRecord.hasActivities field is
simply removied, because ProcessRecord.activities.size() > 0 means the
same thing, and that is actually what all of the key mechanisms are using
at this point.
Finally, note there is some commented out code of a new way to manage
the LRU movement. This isn't in use, but something I would like to
move to in the next release so it is staying there for now for further
development.
Change-Id: Id8a21b4e32bb5aa9c8e7d443de4b658487cfbe18
|
|
(from 128KB)" into klp-dev
* commit '73a523d9bfe28ca0b1b5d5875176290b00865d14':
am: Increase dropbox buffer size to 256KB (from 128KB)
|
|
|
|
to be used with native processes" into klp-dev
* commit '1c18c5d40ce7004d28aaa8f6c6713efcc72e6706':
Fix issue #11391003: Allow dumpsys meminfo to be used with native processes
|
|
Change-Id: I005e4dc763deafac95dc3aa6261c06d1808fdaff
|
|
startservice not working any more" into klp-dev
* commit '0b1ec0165a5dc98bc82670288894af446ff5bcaa':
Fix issue #11374840: adb shell am startservice not working any more
|
|
The startService() and stopServie() calls had a redundant check for
the incoming user ID being valid, but with its own custom implementation
that doesn't match the normal handleIncomingUser flow. In fact, for
both of these we are going to do handleIncomingUser anyway when we get
to retrieveServiceLocked(), so there was just no need for this.
Change-Id: I14409a03781a14a5f1a786aceb31dcc77efb062c
|
|
Minor changes for dumping stack traces:
- Print the native traces right after foreground/persistent apps
- Also include mediaserver, sdcard, and surfaceflinger in traces
Bug: 11321322
Change-Id: Ic09b7da316a5f197dda0ac3bde06f75574cc2166
|
|
incorrectly marked as running in app processes" into klp-dev
* commit 'e6a8ccb3d11a3af2a2d9f0077965d05754abcff3':
Fix issue #11323037: Android apk incorrectly marked as running in app processes
|
|
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
|
|
adding new user profile from settings." into klp-dev
* commit '519d8895a29dd78f5250ee2ececac4e03a6f5b70':
Fix issue #11217255: Setup Wizard ANR when adding new user profile from settings.
|
|
settings.
Two problems addressed here:
- If a call to startActivity() comes in on an activity that is finishing, we can
end up putting the new activity in a stack that isn't actually in use any more
(if the finishing activity is the last one on that stack). This is a bad case,
anyway, so if this happen the treat it as not being called on an existing
activity and switch to NEW_TASK to find a task for it.
- There was a bug in handling PACKAGE_CHANGE broadcasts that would result in the
app's processes being killed, even though the cleanup through the activities
was done. This could leave the activity stack in a bad state. Fix this to
correctly provide an app id for the changing package so that its processes are
killed.
Change-Id: Iece04e0cf95025c3d30353d68bf3d14fd39d44c3
|
|
* commit '504b60453f30b78da3a13e022a1d8a7badf26ae1':
Remove debug logging.
|
|
Change-Id: I5d7c11e8b8525bfc8eb87bb0fff4f71337b4a39d
|
|
permission." into klp-dev
* commit '94758633943e77c820fd77f96329848cc7f31230':
Throw when taking non-existant Uri permission.
|
|
|
|
Bug: 11080911
Change-Id: Ib73a20f497b447aebe69c88266369605e69a7812
|
|
home on top." into klp-dev
* commit '6b5fc882d1823c8922860ef284442442b635111b':
When removing a task that was on home, put home on top.
|
|
Killing an app that was launched from home was not relaunching home.
Previous situations relaunched the next app (i.e. home) based on the
task flag. However, when an app dies the relaunch is deferred until
the TaskRecord has long been forgotten. This fix rearranges the stacks
immediately upon the TaskRecord being removed from the stack. Then the
next resumeTopActivities() call will start the home task.
Fixes bug 11189555.
Change-Id: I0e09350a7db55ea8b38cce7bf4b69923a6b99494
|
|
optimization." into klp-dev
* commit '4732660a50f3373812e8ae55cbda264d469bfded':
Make an exception for screenshot optimization.
|
|
Screenshots were not being made for tasks with the flag
FLAG_EXCLUDE_FROM_RECENTS set. But if the task is in the foreground
the shot should be taken even with the flag set. This fix adds a test
for tasks being in the foreground.
Fixes bug 11170567.
Change-Id: If42db7f43ed1dd8d2b16b68824adc813b31c94f0
|
|
apps are binding to long-running services" into klp-dev
* commit '17c21a3007a2321ae8805a397c3566411a60cba0':
Fix issue #11157301: Bad process stats when apps are binding to long-running services
|
|
long-running services" into klp-dev
|
|
services
We now treat PROCESS_STATE_TOP more specially. When a process has another
client bound to it that is TOP, it will only allow itself to go in the TOP
state if it is not already running for another significant reason.
Change-Id: Ia3856406bd481bf6e98d55100a5513ccf4060e0d
|
|
process." into klp-dev
* commit '6743c1712e1051ae99639a7d90912c54a0be8b24':
Guard against NPE when using existing process.
|
|
Bug: 11167561
Change-Id: I51ca7daa71504119fb64bc7bc2b7da4e03b13861
|
|
into klp-dev
* commit '11591b738d51e0d8e87e8825dc2fc7eaa517daa3':
Surface outgoing Uri permission grants.
|
|
|
|
This enables apps to discover and clean up persisted Uri grants when
the underlying Uri becomes invalid, such as when an account is
removed.
Bug: 11142566
Change-Id: Ieeb36cb1155acf226327ebe91cdd30b822d69d1b
|
|
started." into klp-dev
* commit 'd92dd8ffcf3e7bce7d331e7ae9101ccba02baa67':
Install providers enabled after app started.
|
|
klp-dev
* commit '92fba41f3c64407f6827399bfa40bbcf6eac9212':
Allow killed task to remove itself
|
|
|
|
When an app has already been started, and a ContentProvider component
is enabled with DONT_KILL_APP, use the existing ProcessRecord to
install the provider.
Bug: 11118692
Change-Id: I990f18b337eb19768ee1db895f1e2eb982046cce
|
|
When killing a task from the recents UI, the activities in
the task would be scheduled for destruction, and the task would
be forcefully removed from the ActivityStack, destroying the
ActivityStack in the process if this was the last task. Since the
ActivityStack was removed, any activities calling back to report
their onDestroy was called (or any timeouts that trigger if
activities fail to do this) would be dropped and certain cleanup
routines would not be called.
Tasks and their ActivityStacks are removed automatically when the
activities within them are removed, so this manual removal was
preventing the cleanup routines from running.
bug:10920157
Change-Id: Ied9d4f8fea761a373a9a80a0dfe810590ab411d8
|
|
* commit '972a985590266e457d4a13400dfb5797d7b85908':
Yet more debugging for 10858941.
|
|
Change-Id: I258957044cb1a8331124f6abbe53428429c33355
|
|
into klp-dev
* commit '846a482a0d891a799bfd6e9b00ed5b401a791b30':
Revert to jb-mr2 handling of app died.
|
|
ActivityStack" into klp-dev
* commit '7ac5a9acb8c110620eac04db1eabecbbf64c0744':
Fix issue #11050678: Large memory leak in ActivityStack
|
