Using this flag when binding to a service will
allow the bound process to be held at a low
oom_adj of 250, so that it can be expunged to
reclaim memory if a more user-visible app needs
it.
Use for bindings such as job services and other
connections that the caller can easily recover
from and restart if necessary.
Adjust the lmk thresholds to use this oom_adj
as one of the levels, so they're killed before
perceptible apps (such as foreground services).
Bug: 135219821
Test: CtsAppTestCases
Manually check notification listener oom_adj
and dumpsys activity services output
Change-Id: I9f6d0891d842e4d12f7995b9b1a8f57b0903a16d
1. Lower job count limits to values that should be more reasonable. The
following defaults have changed:
-- MAX_JOB_COUNT_ACTIVE = 20/window = 120/hr = 1/session
(down from 200/window = 1200/hr = 10/session)
-- MAX_JOB_COUNT_WORKING = 120/window = 60/hr = 12/session
(down from 1200/window = 600/hr = 120/session)
-- MAX_JOB_COUNT_FREQUENT = 200/window = 25/hr = 25/session
(down from 1800/window = 225/hr = 225/session)
-- MAX_JOB_COUNT_RARE = 48/window = 2/hr = 16/session
(down from 2400/window = 100/hr = 800/session)
2. Increase timing session coalescing duration to enable coalescing.
-- TIMING_SESSION_COALESCING_DURATION_MS = 5 seconds (up from 0ms)
3. Separate allowed time flag from rate limiting period flag so they can
be changed independently.
4. Fix bug: If an app reached the job count quota limit for its bucket,
QuotaController would set an alarm only 10 minutes (allowed time) into
the future to determine if the app was back in quota. This would result
in unnecessary wakeup alarms. Now, QC will set an alarm for when the
app will be under quota.
5. Expand some comments, clarify some constants, and simplify some code.
Bug: 132227621
Test: atest com.android.server.job.controllers.QuotaControllerTest
Test: CtsJobSchedulerTestCases
Change-Id: I6f3f3a5eff7f64b429820d7370d82c1b4573f23b
A session is considered a period of time when jobs for an app ran.
Overlapping jobs are counted as part of the same session. This adds a
way to limit the number of job sessions an app can run. This includes a
mechanism to coalesce sessions -- if a second session started soon after
one just ended, they will only be counted as one session.
Bug: 132227621
Test: atest com.android.server.job.controllers.QuotaControllerTest
Test: atest CtsJobSchedulerTestCases
Change-Id: Id2ac4037731f57547d00985e8d549b9e990a5f3e
Up until now, QuotaController was only scheduling the quota check alarm
when an app ran out of quota while a job was running, the UID proc state
or standby bucket changed, the device was unplugged, the parole state
changed, or quota controller constants changed. However, if a job was
scheduled and already out of quota (which could be the case due to
job count throttling), an alarm wasn't scheduled. This meant that alarms
throttled due to high job counts probably wouldn't run until the device
was plugged in or the app changed its standby bucket or proc state. Now,
we schedule an alarm if a newly scheduled job is already out of quota so
that it will come back into quota at the proper time.
Bug: 131267600
Test: atest com.android.server.job.controllers.QuotaControllerTest
Test: atest CtsJobSchedulerTestCases
Change-Id: I802b0aa076690451d901521327c4ddab111c42f6
QuotaController was inadvertently updating all Timers for a particular
user whenever any process state crossed the FOREGROUND_SERVICE
threshold, instead of only updating the Timer for the specific UID.
Also adding more data to QuotaController's dump to make future debugging
easier.
Bug: 129117282
Test: atest com.android.server.job.controllers.QuotaControllerTest
Test: atest CtsJobSchedulerTestCases
Change-Id: Ic8d9e6478e61cc62318ae5651f0526e41a71de8d
With this, users with userdebug/eng builds will be able to initiate a
system heap dump from developer options.
Bug: 77490269
Test: manual
Change-Id: I0f4efec621e0d63b87c2d655a5f0434572cb92ac
Formalizing the states and transitions makes it easier to add new
functionality and guarantee correctness.
This also fixes the issue where automatically turning off sticky
accidentally turns off battery saver since the transition is only
done when in the correct state. The problem was that when the battery
level changed (above the sticky auto disable threshold),
doAutoBatterySaver would be called. stickyEnabled would be true,
and the level would be above the threshold, so it would disable sticky.
Then at the next level drop, doAutoBatterySaver would be called again,
but this time, sticky would be false, so it would go to automatic check
and see that the level is above the threshold and then turn off battery saver.
Bug: 127659938
Bug: 119764865
Bug: 112232746
Bug: 79580230
Test: atest com.android.server.power.batterysaver.BatterySaverStateMachineTest
Test: atest CtsBatterySavingTestCases
Change-Id: Ia311d8bdc593a1680eda82d4d06fee21ea45c0ba
Adaptive battery saver is a state that can be entered into dynamically
without the user turning on full EBS. With this, some features of
battery saver can be enabled to save power before the user needs to have
EBS turned on.
Bug: 119261320
Bug: 32423528
Test: atest android.provider.SettingsBackupTest
Test: atest com.android.server.power.PowerManagerServiceTest
Test: atest com.android.server.power.batterysaver.BatterySaverPolicyTest
Test: atest com.android.server.power.batterysaver.BatterySaverStateMachineTest
Test: atest com.android.server.power.batterysaver.BatterySavingStatsTest
Test: atest CtsBatterySavingTestCases
Change-Id: Ib11ea069828275d788e20cd2e858375eaaea888e
This introduces a setting that turns off sticky Battery Saver above a
certain threshold and disables Battery Saver if it was enabled due to
the sticky setting.
Bug: 112232746
Test: atest com.android.server.power.batterysaver.BatterySaverStateMachineTest
Test: atest android.provider.SettingsBackupTest
Change-Id: Ib9a9fd627a56529404b41fbabedf8bb4a372074e
Also address the left over comments from the previous change.
Test: atest MaxJobCountsTest
Test: manual test with "dumpsys jobscheduler"
Test: manual test with "incident_report jobscheduler"
Bug: 111360323
Change-Id: Ic99ba028aea168a18a78c986bba8a2e93459b40a
The main change is to have a limit for the past 10 minutes to avoid
short job bursts/spam. I've included bucket limits in case we want to
try them, but the limits are extremely high, so they should only affect
bad/pathological cases.
Bug: 117846754
Bug: 111423978
Test: atest com.android.server.job.controllers.QuotaControllerTest
Change-Id: I7bf7f1da64981187fa0295d0f6382779667e09dc
uidActive is true for bound foreground services. We would like to put a
quota on jobs for those processes as well, so switching to proc state
allows finer-grained control.
Bug: 117846754
Bug: 111423978
Test: atest com.android.server.job.controllers.QuotaControllerTest
Change-Id: I69b474b3dc0dda7a4d2234d75fd9023c3f041b67
singleTaskInstance displays will only contain on task. This is mostly
used by ActivityView for use cases like bubbles.
Bug: 121047677
Test: atest ActivityManagerMultiDisplayTests#testSingleTaskInstanceDisplay
Change-Id: I5166015d8ecfa2845b4ffaa6c16d21a30a56b8a8
If a job runs out of quota, the deadline alarm will not make it ready to
run. Similarly, there are two other implicit constraints (device not
dozing and not-restricted-in-background) that will stop a job from
running even if the deadline constraint has been satisfied. As such, it
doesn't make much sense to set an alarm to wake up the device when those
constraints aren't satisfied. When those constraints are updated,
TimeController is told to recheck its jobs, so this should have no
negative impact on jobs, but should reduce the number of wakeups the
device has from JobScheduler.
Bug: 117846754
Bug: 111423978
Test: atest com.android.server.job.controllers.TimeControllerTest
Change-Id: Ia0c09400079154287dff9ff2ac622d8870ef4110
Add an overall time limit for all apps, including ACTIVE apps. Right
now, the default is 4 hours per day, so apps can only have their jobs
running for a maximum of 4 hours in a rolling 24 hour window.
Also fix calculation bug where an app could be brought back into quota
despite having less than the quota buffer time available.
Bug: 117846754
Bug: 111423978
Test: atest com.android.server.job.controllers.QuotaControllerTest
Change-Id: Ia0773ef9fe26f0a502fe487f1e11c243eede30b3
1. Add UsageStats Event types:
ACTIVITY_RESUMED is synonym to existing MOVE_TO_FOREGROUND.
ACTIVITY_PAUSED is synonym to existing MOVE_TO_BACKGROUND.
ACTIVITY_STOPPED when an activity becomes invisible on the UI.
2. In UsageStats.java, add API getLastTimeVisible() to report last time the
app is visible (ACTIVITY_RESUMED or ACTIVITY_PAUSED), add API getTotalTimeVisible()
to report total time the app is visible.
The existing API getLastTimeUsed() can report last time the app is in
foreground (AKA have focus).
The existing API getTotalTimeInForeground() can report total time the
app is in foreground (AKA have focus).
3. UsageStats.getTotalTimeVisible() can report screen usage for
split-screen mode and picture-in-picture mode.
4. Because in the same package, activity can be instantiated multiple times,
In UsageEvents.Event class, add a member mInstaceId for activity's
instance ID, add interface getInstanceId() to retrieve the instance ID.
Bug: 112002260
Test: frameworks/base/services/tests/servicestests/src/com/android/server/usage/UsageStatsDatabaseTest.java
atest frameworks/base/core/tests/coretests/src/android/app/usage/UsageStatsTest.java
Change-Id: Ibcef2488e9620804c9f9220b027f976e8fa0c98b
We don't want to penalize apps for starting jobs while in the foreground
so QuotaController now only tracks jobs that started while the uid
wasn't active.
Bug: 117846754
Bug: 111423978
Test: atest com.android.server.job.controllers.QuotaControllerTest
Change-Id: Icc36a361a466571af75b74c0cd9c976c6c321b43
Everything needed to get the CTS tests to work.
Also:
- Change process names to be unique per isolated instance,
and no longer use isolated uid in proc stats, so we don't
have a crazy number of process entries there.
- Again move activity manager dumpsys output so we aren't
spewing less useful stuff at the end where it hides the
core state about processes.
- Fix protos so that we can read InstrumentationInfo from the
activity manager protos. (There was confusion about writing
protos for a PackageItemInfo vs. an ApplicationInfo.)
Test: atest CtsAppTestCases:ServiceTest\#testActivityServiceBindingLru
Bug: 111434506
Change-Id: I2c86bd1daa582a5c60950173ca12e8ec21b13ead
This is the base implementation for QuotaController that will allow apps
to run their jobs in a rolling window. The feature is off by default,
but if turned on in its current state, will allow jobs that don't require
connectivity to run and use up quota. Quota is currently only tracked
using job run times, but is set up to also use job run counts as well.
Support for network dependent jobs will be in a separate CL.
Bug: 117846754
Bug: 111423978
Test: atest com.android.server.job.controllers.QuotaControllerTest
Change-Id: I24caf8ff5f6339e296dd1feec2359679a728d33a
Start removing concept of "insetBounds".
This is an important step in moving policy into the hierarchy since it
represents a codepath that resolves configuration with more data than
what is in the hierarchy (passing in 2-3 sets of bounds instead of 1).
In theory, we shouldn't need this as the extra bounds are only used
during transitionary periods (animation/interactive dragging).
Previously, we set the whole hierarchy to have the "displayed" bounds
and then fed in "insetBounds" to be used for the actual configuration
update. This is a backwards abstraction and a little wasteful since what
we actually want to do is prevent the configuration from updating and
change only how/where the eventual window is displayed.
This CL is a first step which introduces mDisplayedBounds to represent
the Task's bounds during transient periods. This way we can leave the
hierarchy in a steady state and use the displayed bounds to move it
around on screen. These displayedBounds are then used to position the
surface and the computed frame so that we aren't recalculating the
hierarchy (and passing "inset" bounds around) for transient operations.
Bug: 113900640
Bug: 119687367
Test: go/wm-smoke and wmtests/servicestests
Change-Id: Ia70d3e260e9ed6e2c2c8c19920025fd10fab9e17
- Make a better distinction between surface bounds and buffer size by renaming setSize to
setBufferSize and removing setSize for all buffer-less surfaces.
- Adds an error check in SurfaceControl to ensure buffer size is only set for buffer-less surfaces.
- Updates color fade surface to use passed in transaction object.
Bug:114413815
Test: go/wm-smoke
Test: atest FrameworksServicesTests:DimmerTests
Test: atest FrameworksServicesTests:SurfaceAnimatorTest
Change-Id: I88bd1452d6b3b3009e73e26986027d6a5a9efebc
Let each display have one status bar and one navigation bar. This is
so on each display, status bar and navigation bar can be laid out with
apps and produce proper insets.
Bug: 117474929
Test: atest com.android.server.wm
Test: Watch YouTube video in fullscreen mode, and see if status bar
and navigation will be hidden as expected. Swipe on the edge
of screen and see if status bar and navigation bar are both
shown as expected.
Change-Id: I1550659b7cd1dd1676bf04483c5b68376ef42905
