We now have a fixed array of job service contexts, which doesn't
vary by build configuration. Instead, we keep track of the maximum
number of concurrent jobs we want to allow to run, and don't
make use of a context if it would put us over that limit.
The available contexts is now 8 (the largest used to be 6), although
the maximum we will normally schedule is still 6. We have the other
two around only for use by the current foreground app, to allow it
to schedule work while the user is in it, even if we have reached
our normal limit on the number of concurrent jobs.
The maximum number of concurrent jobs varies based on the memory
state of the device, from 6 (if memory is normal) down to 1
(if memory is critical). We aren't yet trying to stop all jobs
if memory gets lower than critical.
Instead of just keeping track of whether a uid is in the foreground,
we now track whether it is the top as well. Only the top uid
can schedule additional jobs above the current limit.
Also improved some of the dumpsys output.
Change-Id: Icc95e42231a806f0bfa3e2f99ccc2b85cefac320
The main goal of this CL was to change the test cases to send an
EXTRA_ID instead of EXTRA_PID, but in changing that it was revealed 2
minor bugs:
- When setting the name property, it was using id instead of pid (which
is what dumpstate expects).
- When the pid is replaced by the name in the screenshots, it would be
replaced twice if the pid was small enough (because the call to
String.replace() would also replace the counter).
This CL fixes these issues, and removes the temporary assignment of id =
pid when the former is missing.
BUG: 27076108
Change-Id: I70e7ce7d145019438272594686ac0d4d5dbe1723
The animation is not a canned animation anymore but base on
the finger movement of the user.
Bug: 19437552
Change-Id: I0f81ac2ff05a92673e3f3b9b72a5c2de238890d0
prepareAppDataAfterInstallInternal may call into ActivityManager which will
try to obtain a lock in a reversed order, which causes a deadlock.
Bug: 27336728
Change-Id: I91bb74cd06c6aa6cee057bab5972b0275d12125b
Initially a surface is hidden after creating, so reflect that fact
in mHiddenForOtherReasons, so it doesn't get shown before the correct
transformation is applied.
Bug: 27350530
Change-Id: Idfe8723195dd1488894da066fafee1f2c2afc12d
The main app window will never finish drawing at this point so there
is nothing to trigger the removal of the starting window.
Also, set ActivityRecord.mStartingWindowShown to true for some cases
where we were telling WM to show starting window but not setting the
flag that would later be used for clean-up.
Bug: 26659857
Change-Id: I7a8582521853f1f95b77d8b08f4dd0cf778f8cbf
Internally isReadyToBeExecutedLocked() needs to check if the target
service is actually present and runnable. For example, when an FBE
device is locked, we need to keep any encryption-unaware jobs
pending until the device is later unlocked.
Bug: 26279465
Change-Id: I53ff4a2243ebe8a199d0e8dcf87dc3f5b06a2686
Moves the protos and event log tags into a library,
so the build system doesn't think they're duplicates.
Bug: 27151225
Change-Id: Ic96b6b811d4813a4c48940081ea77b12fb23f0bc
- Start a drag when the user long-presses on an already-selected item.
- Start a drag when the user mouse-drags on an already-selected item.
- Add highlighting of drop targets.
BUG=20556237
Change-Id: I450fd6768eeb08906304227385476942d641fd11
Since which WebView implementation we use depends on whether the
different webview packages are enabled or disabled we should listen to
changes to the enabled-state of our webview packages (to keep the
webview implementation up to date).
Bug: 27340150
Change-Id: Ie384a48424c9138150ddcc9f7bfaf7b82a911f16
When a device is booting up in an encrypted state WebView won't find the
packages needed for loading WebView and might thus try to use incorrect
webview packages. This in itself might cause us to incorrectly change
the webview provider setting but also causes us to crash the system
server if we try to enabled/disable a package that cannot be seen by the
package manager.
Bug: 27353062
Change-Id: I9349778506e8bec1c56b9b786fe4ed15c7c3260d
Because there is a high risk of making the system instable.
Bug: 22776761
Bug: 26949256
Bug: 26949428
Bug: 26683041
Change-Id: I73b3f05c13b5023db5176e709320ca6e2e5f6354
