...while setting up a new user from settings.
We can now delay broadcasts when there are enough background services
currently starting (still set to 1 for svelte devices, 3 for normal
devices).
Add new intent flag to not allow receivers to abort broadcasts, which
I use to fix an issue with the initial BOOT_COMPLETED broadcast not
actually requesting pss data at the right time -- it can now be sent
as an ordered broadcast without the ability for the receivers to cancel
it.
Change-Id: I51155bbbabe23e187003f3e2abd7b754e55d3c95
The variable ActivityRecord.mLaunchHomeTaskNext was used to indicate
that the home task should be launched when the activity completed.
This only mattered when it was at the end of a task. As the activity
launched other activities within the same task it needed to be
migrated from activity to activity and task to task. This became
too complicated and was at the wrong level to begin with.
By moving the flag to TaskRecord.mOnTopOfHome the logic is simpler
and the results more predictable.
Fixes bug 10602256.
Change-Id: If0b752522b77be9918f1dba221d0ff670fc01af8
PacManager previously would unbind service even when there was no
connection. This means that multiple set proxies of no PAC after a PAC was
present would cause the framework to crash.
Bug: 10801296
Change-Id: I4387b50b6510cea3ee73425c8a0a837f816b0ce1
This patch covers 2 cases. When an app is installed
and the resulting data directory is created for all
existing users. And when a new user is created and
all existing app data directories are created for
the new user.
Change-Id: Iaba7c40645bc7b6cc823d613da0c3782acf6ddd5
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
...caused runtime restart
There were some situations where the package list could be set
with process stats when it shouldn't. Not sure if this is causing
the problem, since there is no repro.
Also some improvements to debug output -- new commands to clear
all stats, print full details of stats, and print a one-day
summary (which should match what the UI shows).
Change-Id: I9581db4059d7bb094f79f2fe06c1ccff3e1a4e74
Add a test for emptiness before accessing either mTaskHistory[0] or
TaskRecord.mActivities[0]. This will keep us from hitting
IndexOutOfBoundsException.
Fixes bug 10789624.
Change-Id: If726df888a2c8b393788793b6220a6bffe2df883
The InputMethod window was being assigned to the bottommost
window as a fall-through situation when no window could receive
input. This fix changes that so that if the bottommost window
cannot receive IME input then the InputMethod will be unassigned.
In most ANRs associated with bug 10689184 mInputMethodTarget
was assigned to the Wallpaper window and the InputMethod was
placed directly above it. When the ANR occurred the window that
was awaiting focused was then always placed immediately above the
InputMethod. This fix will keep that situation from happening.
Change-Id: Ic247e8132a907f2712a9f8a89e43c099142ec851
NPE at com.android.server.am.ProcessRecord.resetPackageList(ProcessRecord.java:596)
Take care of some more cases now that baseProcessTracker can be null.
Change-Id: I394c0b7802788118c3ad6bcac5dfdd23eeda8d58
...while setting up a new user from settings.
The delayed service start stuff was too aggressive -- it would
allow a process to be killed between the an onReceive() that calls
startService() and that service being started. This means that
apps that set up global state that they expect to remain set up
during that time could be lost.
This is the first part of a fix, which tightens up when we allow
services to be delayed. Now we will immediately start the service
as long as it currently as a process running that is not in the
cached state. (Previously we would delay if the process was in
the receiver state.)
This unfortunately means that our service start delay is much
less effective. To address that, there will be a follow-on change
to tie broadcast delivery into this to see if we can delay the
finish of a broadcast as long as there are background services
starting in that process.
Change-Id: I2bba2295d10699ee3479375bbe87114b2cbb0826
We now expect that the transport service's host process will be
OOM-killed sometimes, but will come back automatically because we
still hold the binding. So, we no longer drop it as the
expected-to-be-current transport when that happens.
Bug 10728767
Change-Id: I5e756e8942e7c4c3567632f10460ee31b9618d75
