| 729a328aca436d71b80f3d72f5d54e38d4d2c12e |
|
10-Jun-2017 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #62390590: SecurityException in JobIntentService$...
...JobServiceEngineImpl$WrapperWorkItem.complete
Add more useful information in the security exception message that
is shown -- the reason the last job that was running on the context
was stopped. This should tell you why when you are calling at that
point your job is no longer running.
Test: bit CtsJobSchedulerTestCases:*
Change-Id: Ia7155248b4b4f032cbf8e8754c5437f658ed192c
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| a61f09f6572e226de268807c32b228ec9ff0639e |
|
17-May-2017 |
Michael Wachenschwanz <mwachens@google.com> |
Merge "Purge Nonexistent User Jobs on Boot" into oc-dev
|
| 3f2b6552ec00a69d5a818e3eadc985c45a416c6b |
|
15-May-2017 |
Michael Wachenschwanz <mwachens@google.com> |
Purge Nonexistent User Jobs on Boot
In the case that a user has been removed but their jobs still exist on
disk, the JobSchedulerService will remove all jobs not associated with
current users on boot.
Exposed UserManagerService#getUserIds() via UserManagerInternal for
quick user id retrieval.
Fixes: 38261977
Test: manual
Change-Id: Id4b3c0a4142b4818fcd875eef18ea03f3c45ca40
Signed-off-by: Michael Wachenschwanz <mwachens@google.com>
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 6d06826b2424f5d937bf97576d3b51169c576fc5 |
|
16-May-2017 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #38244875: Bring back testChargingConstraintFails
- Add new "get-job-state" shell command that the tests can use
to find out what is going on with a job.
- Fix an issue in the battery controller where it would not
immediately stop with a "battery not low" constraint when
the battery becomes low.
- Also an optimization to rescheduling jobs, for every scheduled
job that is not ready don't look to see if it is active.
Instead, go through the active jobs and see if any are no
longer ready.
Test: bit -t CtsJobSchedulerTestCases:*
Change-Id: I5611886653258ca337eee97c5ee1b9b3dfdb6d85
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| bfc2331f2f0bee2c12fe8f9cc8a2f3cca05feb86 |
|
11-May-2017 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #38210653: Few more tweaks of job scheduler
- Now keep track of the time a job was enqueued, and order
the pending list by that.
- Added configuration constants for rescheduling: maximum
times to reschedule, minimum backoff times.
- Fixed printing of active jobs -- the method to get the current
JobStatus was old and didn't require the caller to hold a
lock, so made a copy, which didn't contain all the data we were
interested in. Now with our simple locking, we can just make
that require the caller hold a lock and return the real
JobStatus object.
- Include oom_adj and procstate when printing information about
processes being killed.
- Expanded documentation of BroadcastReceiver.goAsync().
Test: bit CtsJobSchedulerTestCases:*
Change-Id: I2e45f181e45be9836c74cbff1b844ffdf6e93019
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 83b40f69bef4ba17bb63ac30d52f661a12d5b4f4 |
|
26-Apr-2017 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #36891897: Need to ensure foreground services can't...
...hide themselves
The activity manager now keeps track of all apps that are running
foreground services and builds a notification showing them to the
user. We ensure they are shown to the user for at least 30 seconds
(configurable). If foreground services are executed while the
screen is off, their apps will be shown to the user for at least
30 seconds after the screen turns back on.
While doing this I am also adding a new process state to distinguish
between "important background" stuff that should bypass bg check vs.
ones that don't. By default, these now no longer bypass bg check,
which is really the expected (and documented) behavior. There is a
new bind flag to allow them to bypass bg check, which is currently
only used by the IME.
Also add some new job scheduler commands that will be used to
write new tests cases for jobs timing out.
Bug: 36891897
Test: manual
Change-Id: Ied3f7b56444254513fd776f06b88bc0e54704958
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 28d1b661347a6a7e05dc1004fd7e8436cace8953 |
|
21-Apr-2017 |
Dianne Hackborn <hackbod@google.com> |
Address various JobScheduler API feedback.
- New sample code.
- Fix/improve some docs.
- Hide JobWorkItem Parcl constructor.
Also:
- Add new JobWorkItem API to get the number of times it has been
delivered.
- Do a bit more optimization of checking if a job is ready.
Bug: 37534393 API Review: JobInfo.Builder
Bug: 37544057 API Review: JobServiceEngine
Bug: 37544153 API Review: JobWorkItem
Test: bit CtsJobSchedulerTestCases:*
Change-Id: I66891a038fba752f45dcaed43e615fa9209b71fc
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| f9bac16d61db0fceb15484587ecf876c2b802c37 |
|
21-Apr-2017 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #32180780: Sync adapters inappropriately being run...
...during full-data backup/restore
The activity manager now tells job scheduler service about the
current backup that is running (only if it is a full backup), it
there is a new condition where we won't consider jobs associated
with the current backup to be ready to run.
Also... just a little optimization here. :) The focus is on
scheduling jobs with a 0 deadline, meaning they should run right
away. Now the timing controller does a quick check for a new
job to see if its constraints are already satisifed, and doesn't
do anything further if that is the case (doesn't add to the list,
doesn't re-evaluate alarms, etc). And in the path to scheduling
a job, we do a check to see if the new job is already ready and if
so then just directly add it to the pending list and schedule it.
Doing this required removing what I think is the last bit of code
relying on handler serializing for thread safety, so now everything
in the job scheduler is protected by our global lock and we can
do whatever we want with the lock held and be assured the state
remains consistent.
Also did some small optimizations to many of the other controllers,
mostly switching from an ArrayList to an ArraySet for their tracked
jobs, since one of the things we do frequently is add/remove jobs.
Finally, added some nullability annotations to the JobScheduler
APIs.
Test: bit CtsJobSchedulerTestCases:*
Change-Id: I533fad94ba59468a52fe3d077a0ceab3427f0012
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 6e8f116647d0b6dcccdc25d00c0806e5c5f91318 |
|
18-Apr-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Finish impl of job queue: handle URI permissions." into oc-dev
|
| 342e6037109a53830277d8de6ecf0e39578c143c |
|
14-Apr-2017 |
Dianne Hackborn <hackbod@google.com> |
Finish impl of job queue: handle URI permissions.
The job queue now handles URI permissions associated with
the Intent of each job. Just (kind-of) like Service!
Also do the second pass of locking in job scheduler, getting
rid of all the async dispatching on a handler, and just executing
calls right in line with simple locking. This probably fixes
a few other race issues, and allows us to make sure that we
always finish a job correctly when dequeuing the last work (we
will always atomically dequeue and finish, so no new work can
slip in between).
And fix a little debug output in IntentFilter.
Test: ran CtsJobSchedulerTestCases, added new test for URI perms.
Change-Id: I52f700ef0cd5be3ff70050f9c0f5fe3e8a5ccac1
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| fd8807accf8ac811818e016fcd4c3dd6e165d379 |
|
17-Apr-2017 |
Dianne Hackborn <hackbod@google.com> |
More small fixes/adjustments to job scheduler.
- JobServiceEngine now takes a concrete Service instead of
generic Context in its constructor, since it really must be
associated with a real Service.
- Expand documentation of how dequeueWork() operates.
- Fix some job scheduler implementation to hopefully actually
match the docs: transfer remaining executing work to the new
job, and actually correctly transfer state from old and new
jobs if we are rescheduling due to a true return from onStopJob().
Test: bit CtsJobSchedulerTestCases:*
Change-Id: Ia66797049883eefb566264f930070afb69d469b1
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 60977f42dbbcf6edfd9b18fdd08af54006860d90 |
|
13-Apr-2017 |
Christopher Tate <ctate@google.com> |
Introduce NETWORK_TYPE_METERED job constraint
When your job wants non-WiFi connectivity.
Bug 37219369
Test: CTS
Change-Id: I0981938061b6b7f354e7236221552ef03976f470
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 7da13d7c3e5b48c0410ae869c5679652de97e5aa |
|
05-Apr-2017 |
Dianne Hackborn <hackbod@google.com> |
Add new "work queue" feature to JobScheduler.
This gives semantics similar to the start command
queue of services.
The implementation is currently lacking in URI permission
grant handling of the work intents; that will be coming
in a follow-up change.
This includes a first step of adjusting/fixing locking
within JobSchedulerService. The JobServiceContext class
has a bunch of stuff it does that assumes it doesn't need
locking because it schedules the work on a handler. However,
to be able to correctly implement the work finish flow (that
takes care of stopping the job when there is no more work),
we can't dispatch these asynchronously so need to get rid of
that and just do explicit locking.
The switch to explicit locking is half-way there (again the
remaining part will be a follow-on CL). Right now we have
the locking, but still also the handler. But it turns out
there were a number of things we were doing without a lock
held where we actually should have been holding a lock, so
this is better anyway.
Test: new tests added
Change-Id: Iebd098046209b28e60fd2f4d855d7f91cd3a8b03
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 7234fc6fef781e33842bc598a6e9e04bbff4f898 |
|
04-Apr-2017 |
Christopher Tate <ctate@google.com> |
Track pending job latency
Timestamp jobs being marked 'pending' and 'active,' so we can then report their
pending latency in dumpsys.
Bug 35385393
Test: N/A
Change-Id: I3d981fbc7fbe6abdf30da3f86d88d3733b797f51
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 6df866a8510af2776c48425a361f708ae7f5d7d6 |
|
31-Mar-2017 |
Jeff Sharkey <jsharkey@android.com> |
Enforce PACKAGE_USAGE_STATS for usage data.
Some system services are offering package usage data through both
public/system APIs and through dump() calls. In principle, usage
data hould always be protected with PACKAGE_USAGE_STATS, so start
enforcing that. (Otherwise if a user blocked PACKAGE_USAGE_STATS
access to an app, that app could still obtain the data via dump()
if they held the DUMP permission.)
Bottom line, let's respect the user's wishes.
Protecting the entire output like this is pretty blunt, but future
CLs can add more nuance to the output if desired.
Test: cts-tradefed run commandAndExit cts-dev -m CtsSecurityTestCases -t android.security.cts.ServicePermissionsTest
Bug: 32806790
Change-Id: I46173562713bea7d89e12a4313c78eb52ea8d77d
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| fe9a53bc45fd0124a876dc0a49680aaf86641d3e |
|
31-Mar-2017 |
Jeff Sharkey <jsharkey@android.com> |
Consistent dump() permission checking.
This change introduces new methods on DumpUtils that can check if the
caller has DUMP and/or PACKAGE_USAGE_STATS access. It then moves all
existing dump() methods to use these checks so that we emit
consistent error messages.
Test: cts-tradefed run commandAndExit cts-dev -m CtsSecurityTestCases -t android.security.cts.ServicePermissionsTest
Bug: 32806790
Change-Id: Iaff6b9506818ee082b1e169c89ebe1001b3bfeca
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| a47223f99b6b7ade4ae909c458d975eb487062b3 |
|
30-Mar-2017 |
Dianne Hackborn <hackbod@google.com> |
Implement issue #36590595: Add ability to associated a ClipData with JobInfo
Yum!
Also needed to have a Context.revokeUriPermission() variant that is sane,
so reasonable CTS tests can be written.
Test: new ClipDataJobTest added.
Change-Id: Ia3135ea788a6e32c971bae7dab3a844d0ef4139c
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 0aa4313ec4424af00f86293b5ca72115faa9dc15 |
|
22-Mar-2017 |
Dianne Hackborn <hackbod@google.com> |
A little cleanup of activity manager dumpsys output.
Test: manually ran dumpsys
Change-Id: I0c3a523c501576beba2bf85c61faa026eb2a0440
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 532ea26c7b66180b09524f96da8bca1110f41197 |
|
18-Mar-2017 |
Dianne Hackborn <hackbod@google.com> |
Add new "storage not low" job scheduler constraint.
This allows you to say that your job should run only when device
storage is not low.
Adds new command line interface to DeviceStorageMonitor to help
with driving the tests (modelled after BatteryService).
Test: new StorageConstraintTest suite.
Change-Id: I96bfb761cd8257b6f68dde43ce9cfb1a3b9d0acb
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| b1d6448ec4f9af79776cc2e9eb951b659212b0bb |
|
15-Mar-2017 |
Christopher Tate <ctate@google.com> |
Correctly check expired jobs against active ones
If a job was run before its deadline, and then the deadline landed
while the job was still running, b/c of the 'deadline trumps all'
it would be considered eligible to run again as soon as the previous
iteration completed.
Fix this by checking against the state of the active queue.
Bug 36253320
Test: CTS: job scheduler TimingConstraintsTest
Change-Id: I4f0c1012091bf88776cfe725d7b59f6dcf602c02
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 8025580449081ddd21f449f8719bc87d1cc9fc7b |
|
04-Mar-2017 |
Sudheer Shanka <sudheersai@google.com> |
Update IUidObserver.onUidStateChanged to include procStateSeq.
This procStateSeq is associated with the process state change of
an uid and will help in identifying if network policy rules have been
updated for a process state change.
Bug: 27803922
Test: runtest -c com.android.server.am.ActivityManagerServiceTest
frameworks-services
Change-Id: Iaab8d004f476b96f28d08c886c7b0a6b585b9fef
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| a06ec6a9435f9555142e700f54cf20278bc1982f |
|
13-Feb-2017 |
Dianne Hackborn <hackbod@google.com> |
Add new job scheduler constraints for "battery not low".
Clean up the implementation of boolean constraints so that
they are in a single flags value that gets propagated all of
the way from JobInfo.Builder in to the JobStatus. Much simpler
and easier to add new constraints!
Also introduce some shell commands to make it easier to write
tests against the job scheduler (and other things tied to power).
One of the big things here is that there is a new sequence number
that propagates with battery updates, which we can look for in
the job scheduler to determine when a change the test has made
to battery state has actually gotten applied, to allow it to
safely and minimally wait until executing the condition being
tested.
Test: New BatteryConstraintTest suite added.
Change-Id: I11076d90b80ec25ee604c29b6a6dc2337fd867ce
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| c3af19a87dc70c321ffcc1e90453bb6f0545aef2 |
|
21-Jan-2017 |
Dianne Hackborn <hackbod@google.com> |
Optimize bg check flow.
No longer need to look up the application info, target SDK is
explicitly passed in to the check. For the external method, we
change this to just checked to see if background is completely
disabled, which doesn't need a target SDK check (and is the only
thing any of the current clients care about).
Now allow SystemUI to put targets of notification pending intents
on the temporary whitelist when they fire, so developers can avoid
dealing with background restrictions in this case (if the user
interacts with their notification, they will temporarily be
considered in the foreground).
Remove any thoughts of enforing restrictions on registerReceiver(),
so we don't need to deal with target SDK versions there (which can't
be done all that efficiently).
Also bring back the old "allow starts coming from foreground apps"
only for the MODE_IGNORE app op, since it should provide some
better compatibility.
Test: ran them.
Change-Id: Id4ea7f992d12ce4bd8e54f1dbaeb4a460a3dee59
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 0d1fd8d09163566d2c7eb72037f63b6404ada642 |
|
12-Oct-2016 |
Amith Yamasani <yamasani@google.com> |
Secure MATCH_UNINSTALLED_PACKAGES across users
Introduce a new internal flag MATCH_ANY_USER for genuine uses
of searching through all apps on the device.
Some temporary accommodations for Launchers that reach across
to the work profile until we have a new LauncherApps API to do
that officially.
Bug: 31000380
Test: CTS tests added
Change-Id: I2e43dc49d6c2e11814a8f8d1eb07ef557f31af34
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| dc589ac82b5fe2063f4cfd94c8ae26d43d5420a0 |
|
11-Nov-2016 |
Sudheer Shanka <sudheersai@google.com> |
Update usage of ActivityManagerNative.
- Remove references to ActivityManagerProxy.
- Add isSystemReady to ActivityManager.
Bug: 30977067
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test android.server.cts
adb shell am instrument -e class com.android.server.am.ActivityManagerTest,com.android.server.am.TaskStackChangedListenerTest \
-w com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I07390b6124fb1515821f5c0b37baf6ae74adc8fa
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| e07641d4fbdd0528c18305213e861a6e1aff4a3b |
|
10-Nov-2016 |
Dianne Hackborn <hackbod@google.com> |
Start implementing background restrictions for eph apps.
This implements the additional intended path for checking
allowed background operations, APP_START_MODE_DISABLED, which
doesn't allow an app to launch in the background at all.
Also change the semantics of delivering broadcasts to manifest
receivers to always restrict those, not changing based on
whether the app is currently idle. This is the desired intended
behavior for apps as they explicitly update to work with
bg check.
And now that we have ephemerality associated with the uid state
in the activity manager, we can propagate this through the
relevant callbacks in IUidObserver so things watching these
changes can immediately determine whether they should do their
more aggressive shut down work for the uid rather than having
to walk through all their state looking for package associated
with that uid and whether they should be shut down.
Also remove the "lenient" bg check mode, since that was
just an early experiment that we won't actually use.
Add a new "make-idle" activity manager command to immediately
put a uid into the idle state (if possible) to make it easier
to test.
Test: manually against an eph app
Change-Id: I43a138ff281f69a9251d3f29ab6e13f48cff8ad6
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 5614bf5a1ae4522dfc1a041f003cebc9b25c8b93 |
|
08-Nov-2016 |
Dianne Hackborn <hackbod@google.com> |
Move code for handling uid obs "cutoff" to activity manager
To do this, I had to fix the PROCESS_STATE_NONEXISTENT constant
to be the last value (instead of the special magical -1 value)
so it semantically matches the public importance constants. I
think this is better anyway.
Also this fixes a big problem in the implementation, where we
weren't keeping track of the last proc state per uid...! Duh.
Test: manually ran testUidImportanceListener
Change-Id: Ie3008f824446089840f896885e6033472abb065e
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 058f1e4468bd54d0ac39fdf81b4df7221b28721a |
|
03-Nov-2016 |
Dianne Hackborn <hackbod@google.com> |
Implement system API for monitoring uid importance changes.
Changed the permission for registerUidObserver to be
PACKAGE_USAGE_STATS, which better matches the semantics of this
API and is accessible to system apps.
Test: Added testUidImportanceListener()
Change-Id: Ib47d02bd654fbe399a9c92550c89ecbd38f928dc
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| ab058ab2bd34c4841d27a80cda8ec7cc8bd1689e |
|
08-Oct-2016 |
Christopher Tate <ctate@google.com> |
Fix job scheduler crash due to uninstall race am: 652c5ad516 am: 1131f280ae
am: fe83435089
Change-Id: I1701b56c57ac5ac120ab15d7afd70726b783fa53
|
| 0467fec23c65041d7d8b3b963603b3237c1143bf |
|
08-Oct-2016 |
Nancy Zheng <nzheng@google.com> |
Change DEFAULT_BG_LOW_JOB_COUNT to 1 in JobSchedulerService. am: e39a8a46d9 am: ef866c3d0f
am: 1076354748
Change-Id: Ieb1d31126e2a51912c820d15fff013ece021673d
|
| 7a70c1af231f6a0ca9d2d7ed932406ace0d52454 |
|
08-Oct-2016 |
Christopher Tate <ctate@google.com> |
Eliminate unnecessary object churn in job scheduler updating am: eafb535072 am: 84e9961a7c
am: 893930630f
Change-Id: I8a34923996d5dd76519b881c62077419f12fd2fc
|
| 1131f280ae1cf1a3c3b748176e1cbe12bf807acb |
|
06-Oct-2016 |
Christopher Tate <ctate@google.com> |
Fix job scheduler crash due to uninstall race
am: 652c5ad516
Change-Id: Ied6a4348eb3a9293ff496f3bd56af4729126c5cf
|
| e39a8a46d92ead0bdc8a2ceabe510cf6e89b8fbc |
|
06-Oct-2016 |
Nancy Zheng <nzheng@google.com> |
Change DEFAULT_BG_LOW_JOB_COUNT to 1 in JobSchedulerService.
Bug: 31601136
Change-Id: I595f192698b97dc6472a67dc1a1eebd60533efa7
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 652c5ad5167b36735bd04b38b9b904d7bdf8033e |
|
05-Oct-2016 |
Christopher Tate <ctate@google.com> |
Fix job scheduler crash due to uninstall race
It's possible to get a PACKAGE_CHANGED broadcast well after the
package has actually been uninstalled outright because of broadcast
delivery latencies. Understand the exception that might be thrown
when asking for package info in such cases, so we don't crash the
Android runtime.
Bug 31865735
Change-Id: I69b2678f0f724fc731aa48fed7af58ce60d3c21c
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| eafb535072698b0559d8919db4b18618359c11b9 |
|
05-Oct-2016 |
Christopher Tate <ctate@google.com> |
Eliminate unnecessary object churn in job scheduler updating
The arbitrary-caller "what job is currently running?" state inspector
returns a clone of the JobStatus record for it, not a live reference
to the scheduler's active state. That's appropriate for most cases
but when doing its own internal bookkeeping, the object churn in cloning
(especially, an unneeded clone just for purposes of comparing to some
other job!) is merely a huge waste of CPU and GC load.
So now we don't do that unnecessarily, and everything is much leaner.
Bug 31751985
Change-Id: Idacb52e9e5ca17b9e12b7ccd2fc2e1ec8b3547f6
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 354736e196ff79962b3ddb52619a674044d773e2 |
|
23-Aug-2016 |
Dianne Hackborn <hackbod@google.com> |
New infrastructure to switch remaining commands to "cmd" calls.
This introduces a new feature of the IBinder command protocol
to allow the shell command implementation to call back into
its caller to ask it to open files in the calling context. This
is needed so that commands that have arguments specifying files
can open those files as the calling shell, not the system (or
whatever) process.
To test this all out, move the "am start" implementation over
to ActivityManagerShellCommand, in particular along with its
option to specify a file in which to write profiling data.
Test: Manual
Change-Id: I0c1e3857defefbd19a2ac29413aafbb34b1e48a3
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| ee7805be22756970568334961daa23d0b5856846 |
|
16-Jul-2016 |
Christopher Tate <ctate@google.com> |
Remove scheduled jobs when an app is force-stopped
Bug 30100499
Change-Id: Id98a2fe68c07aa9e4557685d3653954d02b71d0a
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 785f494e8752ca3bcffe1d648ecf05b0734df31c |
|
14-Jul-2016 |
Jeff Sharkey <jsharkey@android.com> |
Require permission for FLAG_WILL_BE_FOREGROUND.
We caught scheduleAsPackage(), but not schedule(), oops.
Bug: 28998999
Change-Id: I0642c2265ff61eead8747cc6b4d0f852f1ca3ef2
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 7ab4025474d3ce80b00fbc96962a585f918a0be1 |
|
16-Jun-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #29371078: Foreground jobs should not count...
...as active for idle maintenance
Nor jobs of whitelisted apps.
Now they don't.
Also remove the no longer used "active download" tracking code.
Change-Id: I553197801f6eabaf15716f3201dd65257a0d4e94
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 34618b586996dfbfd87a3b7f0d18f26d4d1ebb51 |
|
01-Jun-2016 |
Jeff Sharkey <jsharkey@android.com> |
Skip cancelling jobs with FLAG_WILL_BE_FOREGROUND.
When FLAG_WILL_BE_FOREGROUND is set on a job (such as a download), we
need to treat the job as if it had a foreground service running so
it can continue making forward progress. We already ignore the device
idle state when offering to start the job, so this just avoids the
hiccup of stopping the job only to restart it a minute later.
Bug: 26571724
Change-Id: I348903dd3a7dd7104b0c1bf4310e2a48655d2588
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 970e3f412d34cbeae3706de5cb1de0b3ca741f87 |
|
01-Jun-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #29069028 NYC: device boot failure: NPE in AppIdleController
Make sure the core parts of JobSchedulerService are initialized
before we start creating the controllers.
Change-Id: I497df12f7e6fbd93581291ec691c4b45104d67d0
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| e9a988caca733d2f292991a52a0047685a69812f |
|
28-May-2016 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #28942589: Tune job scheduler
We now have a new settings key that provides all of the existing
tuning parameters, plus some newly redone ones for dealing with
different memory levels.
Changed the minimum batching for overall jobs from 2 to 1, so
we will never get in the way of immediately scheduling jobs
when the developer asks for this. We should now be able to rely
on the doze modes to do better batching of jobs for us when it
is really important.
Also work on issue #28981330: Excessive JobScheduler wakeup alarms.
Use a work source with scheduled alarms to blame them on the app
whose job they are being scheduled for, and add a check for whether
a job's timing constraint has been satisfied before considering it
a possible candidate for the next alarm. (If it is satisified,
the time is in the past, so we should not schedule an alarm for it.)
Finally clean up a bunch of the dumpsys output to make it easier
to understand.
Change-Id: I06cf2c1310448f47cf386f393e9b267335fabaeb
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| b5c0788d3686351cfe594c6b680d2857f89e4a63 |
|
27-May-2016 |
Christopher Tate <ctate@google.com> |
Purge an app's scheduled jobs when the whole package is disabled
Bug 28979894
Change-Id: If8a99489eaaa219274289fdf2e90be8bdecb3bfa
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 564915c58e30a1849386f1a77559a461b9f681f4 |
|
04-May-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Check permission for FLAG_WILL_BE_FOREGROUND." into nyc-dev
|
| 4f10040f6b37f4d3c11487d452d3eb86c858a756 |
|
04-May-2016 |
Jeff Sharkey <jsharkey@android.com> |
Check permission for FLAG_WILL_BE_FOREGROUND.
This flag is only designed to be used by platform internals, such as
DownloadManager, so require that callers hold a nice strong
permission.
Bug: 26571724
Change-Id: Ie5ec55399e2e3a64b2837ef2c0a7a8a79bd1e49f
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| ef3aa6ee53c5e4f1c50dd5a9b5821c54e449d4b3 |
|
30-Apr-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #28477006: Add small event log to job scheduler
Added. Also fixed dumpsys output when filtering, to apply the
filter to (almost) all of the output.
Change-Id: Iafb446599ad8fddbe8a766784deff618a6cfdbb7
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| f07c7b9fd0a640bff4bf7690373613da217fe69b |
|
22-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
API changes for DownloadManager and JobScheduler.
To support moving DownloadManager, add new JobScheduler network type
constraint that matches "any network except roaming." Also add an
API to get a specific JobInfo by ID.
Since the default network can be different on a per-app basis, and
individual apps may be blocked due to app standby, evaluate job
connectivity constraints on a per-UID basis. To implement this
cleanly, add NetworkInfo.isMetered() to match the isRoaming() API.
Add new DownloadManager APIs to support charging and device idle
constraints, which are plumbed through to JobScheduler under the
hood when scheduled.
Add filtering to JobScheduler dumpsys to omit noisy details for
packages the caller isn't interested in.
Bug: 28098882, 26571724, 19821935
Change-Id: I09ca7184ef7ce6adba399f579d415a5fb2ea6110
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 8db0fc15b85c6501a0418b17edee2d9c447b408a |
|
12-Apr-2016 |
Dianne Hackborn <hackbod@google.com> |
More work on issue #26390151: Add new JobScheduler API...
...for monitoring content providers
We now have some delays before reporting URI changes, to allow
them to batch together.
Also clean up debug output, and fix some issues with how we
were managing the content observer state.
And while I am here, fix the device idle and app idle controllers
to no longer maintain their own list of jobs, but just directly
iterate over the JobStore.
Change-Id: If3fdff23c00c2f1b99901a9be096d851562d3439
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 807de78c072c5a40be7b12c656d641d9e73741d2 |
|
08-Apr-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #28035090: Disallow abuse of JobScheduler
We now keep track of how long each app has been running a job
for, in 30 minute batches. If it is running jobs frequently,
we will bump down the priority its jobs run at to allow other
jobs to run before it.
Currently we count both pending and active as the job running,
which means that an app that has jobs waiting in the pending
queue will count against its abuse prevention. This could
allow starvation -- if we bump down the priority of an app's
jobs and the system is so busy continually that they sit
in the pending queue a lot -- it could never recover. But I
think that is okay... if we are really in a state where we
are continually running as many jobs as possible, we probably
have other larger issues.
Change-Id: I838aa4b5840e91df49a1e17b53188d6e4a66a6d1
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 141f11c82a2dbf042833f75aeae6f028e8ae2084 |
|
06-Apr-2016 |
Dianne Hackborn <hackbod@google.com> |
More work on issue #26390151: Add new JobScheduler API...
...for monitoring content providers
- Improve media provider change reporting so that observers can
avoid spurious reports of the top-level content directory changing.
- Fix a bug where collected content changes while a job was running
were not being properly propagated to the next job.
Change-Id: I29e3c2960e6fec75b16ee3ee6588d47342bf8c75
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 4eb64fdbcf899a81d0a6a04dc3658d03d9df8247 |
|
21-Mar-2016 |
Joe Onorato <joeo@google.com> |
Refactor ProcessStats.
- Pull most of the inner classes out into their own files.
- Move everything to a new android.app.procstats package.
- Move all of the code that was manipulating the big list
of longs to use the new SparseMappingTable class rather
than doing everything by hand. The logic is unchanged.
- Add a sequence number check to SparseMappingTable so
when the big list of longs and the individual tables are
reset, which happens somewhat independently, we can
assert when one of them doesn't get reset.
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| cb926fcec46b111d69059874d63c4cbebb5903c4 |
|
15-Mar-2016 |
Amith Yamasani <yamasani@google.com> |
Move device idle logic into a job StateController
Move most of device idle (doze) logic from JobSchedulerService
to DeviceIdleJobsController.
Allow whitelisted apps to run during device idle by adding
a new constraint DEVICE_NOT_DOZING. Using the word DOZE to
disambiguate from IDLE because the latter is used to mean
that the job wants to run in idle-maintenance period.
Bug: 26851107
Change-Id: I97f5286bd4d5ca18fbc46c2037c310fd369e18bf
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 2fefbcf0d1b91f37684387971721c90112a9ac89 |
|
18-Mar-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #27653326: Sync doesn't work in doze maintenance
Add a (configurable) delay between when we start a maintenance
window until the minimum time we will end it.
Also switch to using the alarm manager callback API. (Yay!)
Also fix a little printing problem in the alarm manager dump
so we put the package name and not some class hash in the
summary string of an alarm entry.
Change-Id: I4281e5c80bc8b26ebc1fb6f603ec33ec0e379daa
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| a0a58a2fd5cbc1bb8056227bb04f276b364c6e96 |
|
17-Mar-2016 |
Jeff Sharkey <jsharkey@google.com> |
Merge "Refactoring FBE APIs based on council feedback." into nyc-dev
|
| 8a372a0a280127743ce9a7ce4b6198c7a02d2a4f |
|
16-Mar-2016 |
Jeff Sharkey <jsharkey@android.com> |
Refactoring FBE APIs based on council feedback.
Mostly consists of removing the word "encryption" from most APIs,
since we can't actually make promises about the data being encrypted.
Bug: 27531029
Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| b1c1f9a7a9808c21c3354a8a9df6c4426634d0ff |
|
17-Mar-2016 |
Christopher Tate <ctate@google.com> |
Fix job duplication bug
Lookup of an existing obsoleted job was not done within the same
lock lifetime as scheduling its replacement, which means that callers
could race scheduling "the same" job and wind up creating duplicates.
Bug 27589164
Change-Id: I572b01092964b82316961de601bb7f1afedf18de
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| cbf5ae92e70ed49f18b9e7454dc28d489b3d33a4 |
|
08-Mar-2016 |
Shreyas Basarge <snb@google.com> |
Remove SyncManager's local job cache
SyncManager maintains a local copy of all
scheduled syncs. This was done so that we
don't have to query JobScheduler every time
we need to go through the syncs to reschedule
them, etc. Keeping JobScheduler's job list and
the SyncManager's copy in sync is messy. Not
keeping a copy with SyncManager would also
allow JobScheduler to drop jobs based on an
app being uninstalled or other external events.
Here, a function to query all pending jobs
scheduled by the system process is exposed
from JobScheduler and SyncManager uses it
instead of maintaining a copy of its own.
Change-Id: I723dbb3835a0f9c7e8844483004e7b0f7f340daf
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 5d346051bd6da471203fed94357f58491822a4eb |
|
08-Mar-2016 |
Christopher Tate <ctate@google.com> |
Add 'shell cmd jobscheduler run ....' to run a job immediately
During development one needs to be able to test changes conveniently,
and when the jobs would normally have hard-to-simulate constraints
like idle-time or long minimum latencies, testing becomes difficult.
This CL introduces the ability to run a specific job immediately
from the adb shell.
Without the "-f"/"--force" flag, the job still won't run if it has
unmet "functional" requirements such as being connected via an
unmetered network. With that flag, the job will be run immediately
regardless of its declared constraints (so it may not work properly
due to lack of network connectivity or similar).
Bug 27501783
Change-Id: Icc046f53f8846690c8234e60066e85c283d325ce
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 0213ace0140376b90d6824caad3f4035ee25651e |
|
24-Feb-2016 |
Christopher Tate <ctate@google.com> |
Reintroduce per-app scheduled job limits
There was a period of interim deployments during which sync-manager jobs
were not properly attributed to the package whose sync operations were
being driven. This situation is now corrected when it is encountered.
Bug 27335118
Change-Id: Iafc40c80093499447b2e62a4888e3ece0371bfcb
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 77ca74d941eb4addd7051c747362bace0746b7a7 |
|
26-Feb-2016 |
Dianne Hackborn <hackbod@google.com> |
Merge "Work on issue #26390161: Throttle syncs/jobs when system is low on RAM" into nyc-dev
|
| 12c0da418958c4d8267aa1a5d265d464f78d5465 |
|
26-Feb-2016 |
Jeff Sharkey <jsharkey@android.com> |
Accept non-EA jobs while user is locked.
We'll keep them around in the pending queue until the user is
unlocked, at which point we'll consider running them.
Bug: 27358148
Change-Id: I2eb538a89206d4caac620b3b4e989b011b309201
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 970510b9c5299d480b3ec7f8403afd8265456f87 |
|
25-Feb-2016 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #26390161: Throttle syncs/jobs when system is low on RAM
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
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 019f6d9caa7de3c3ebd42ca7fd1a229d74c86e7e |
|
25-Feb-2016 |
Jeff Sharkey <jsharkey@google.com> |
Merge "Fix JobSchedulerService FBE regression." into nyc-dev
|
| 822cbd130fb6c5016c328a9e85b27eb024aef229 |
|
25-Feb-2016 |
Jeff Sharkey <jsharkey@android.com> |
Fix JobSchedulerService FBE regression.
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
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| dabdf6f1bd99529e7b00ad888d2ef5012936f6bf |
|
24-Feb-2016 |
Christopher Tate <ctate@google.com> |
Disable per-app scheduled job limits
Bug 27335118
Change-Id: I6ec92498c1e90e63a650db2a676cfd75dd91aced
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 1085ff6ee531931ef7f55cbadbc83616f619b292 |
|
24-Feb-2016 |
Dianne Hackborn <hackbod@google.com> |
Work towards issue #26390161: Throttle syncs/jobs when system is low on RAM
First, we need to make the job scheduler prioritize jobs for
foreground apps over background apps (so we will degrade well
when we are limiting the number of concurrent jobs).
So now the job scheduler keeps track of the process state of
each uid, and uses that to bump up the priority of jobs
associated with foreground uids. Added constants for priorities
since we have different places specifying priorities.
Also cleaned up a bit of the reporting of "wrapped" jobs from
the sync manager -- there is a new tag argument that can be supplied,
to have the name and tag used in various places be based on that
instead of the useless internal class name.
Change-Id: I8781750ddfac1472a98e1873fc38c014425db3d6
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 2f36fd6fc94b62b8ccd03cdcea89826d05414f93 |
|
19-Feb-2016 |
Christopher Tate <ctate@google.com> |
Limit scheduled jobs to 100 per app
Packages that are entitled to schedule jobs on behalf of other uids
are not subject to the limit. Also break the JobStore's monolithic
set of jobs into per-uid slices for efficiency and orthogonality.
Bug 27150350
Change-Id: I8f5f718bf200d55f9977a6fc53b7f617e7652ad9
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| b0001f6fb1383d9824c2733896b0b348e7f77240 |
|
16-Feb-2016 |
Dianne Hackborn <hackbod@google.com> |
Remove internal locking from JobStatus.
Now all state of JobStatus is implicitly protected by the lock
of whoever is using it -- in this case the global lock for the
JobSchedulerService. This allows us to remove all of the atomic
variables and just replace those with a simple bit field.
The required constraints for a job are now statically defined
once a JobStatus is created, and don't change. (They wouldn't
change before, but now this is absolutely specified to be the
case.) This required tweaking the constructors a bit so that
the earliest and latest run times are computed as part of the
core class initialization.
Also clarified methods on StateController that are called with
the lock held, and took advantage of that in the various
controllers to not now redundantly re-acquire the lock.
Change-Id: I595c5e7d1bff1bd2ff906d612581af82878a25ee
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 33d31c5b70c7d056e799e34bb6eccbe6939714ea |
|
16-Feb-2016 |
Dianne Hackborn <hackbod@google.com> |
Simplify job scheduler service locking.
Unify all locks to just one lock protecting the entire service.
There is really no need for more complicated locking -- there is
nothing in the code that can take a long time to complete. And
having a single lock will allow various parts of the code to be
much simpler and easier to maintain.
This is just the first step of the change, switching all of the
locking to use one lock. With this done, we can now start
simplifying the code. For example, JobStatus no longer needs
to do any locking (or have atomic variables and such), it can
just rely on its callers holding the global service lock.
Change-Id: I502916ed7f2994b601750c67a59a96b1a4e95c6d
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 8e64e2e6a4d2964b6a4147f5cccd03de934c86cd |
|
12-Feb-2016 |
Shreyas Basarge <snb@google.com> |
Fixes JobScheduler not persisting flex and sourcePackage
There was a bug with persisteing and restoring flex and
sourcePackage. Fixed it and added tests.
Change-Id: Ie8e4714b4727ecef4254773fd4339b28f4a47c01
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 73f1025f2d01490ca580312cae28279cf614c85e |
|
11-Feb-2016 |
Shreyas Basarge <snb@google.com> |
Fix for JobScheduler dropping periodic jobs
Skip writing to disk when a periodic job is
removed from jobStore after it completes
execution.
Change-Id: Ib4f2cf18554bf9c87138c1984c96cc62f8dbf7e2
Bug: 27147454
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| c7bacab20fa8a0e603726f4f8ebafd3a96babeb1 |
|
09-Feb-2016 |
Jeff Sharkey <jsharkey@android.com> |
More encryption-aware triaging.
Most of these callers are okay having results omitted when a package
is uninstalled or encryption unaware. For example, jobs and
notifications can only be enqueued by already running apps.
When clearing zen rules, keep around rules inserted by apps on
ejected external storage devices.
Make ServiceWatcher stricter by requiring that the matching package
be in the system image.
Bug: 26471205, 27105254
Change-Id: Ie41ea8042ac1a54e9cbe0c35cec89e70521e9bed
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 8c834c07675052c984728cbf79f7c2e0d8246e43 |
|
07-Jan-2016 |
Shreyas Basarge <snb@google.com> |
SyncManager on JobScheduler
SyncManager now uses JobScheduler for scheduling
and persistence purposes.
Change-Id: I38c92aedbf4d891ca297644d0b706835aaedfcd6
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 1a30bd9b13fd127d9bbfdc5fd4cb2f80ab7ece21 |
|
11-Jan-2016 |
Dianne Hackborn <hackbod@google.com> |
Add and implement JobScheduler content observer APIs.
Allows one to schedule jobs to run when content URIs
change, and find out what changed when the job executes.
This required adding a new API to StateController to
tell it when we are about to start executing a job, so
we can transfer the currently collected changes out of
its internal state to fill it in to the JobParameters.
Also some additional dumpsys debug output to help
understand what is going on in the job scheduler.
Change-Id: I91f51b226ff4add7a271a8333beffa5e86c7bf18
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 3dbb412c94b91a2f8f130c32417621d138c3f7ec |
|
19-Jan-2016 |
Shreyas Basarge <snb@google.com> |
Merge "Fix for possible NPE in JobScheduler"
|
| 968ac75c2048214a28e9eac3d0e2e0d23776f887 |
|
12-Jan-2016 |
Shreyas Basarge <snb@google.com> |
Adds sourcePackageName field to JobStatus
Platform apps can schedule a job on behalf of
some other package. Battery stats and appIdleState
will be computed using sourcePackageName.
Change-Id: If52f6e1db3a563ef0854d1f59fbc6088a0c29ad1
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 347c2780aab9dbacb7e0336d3585890647187bf4 |
|
15-Jan-2016 |
Shreyas Basarge <snb@google.com> |
Fix for possible NPE in JobScheduler
Fixes a possible NPE in JobScheduler
Change-Id: I4faa414ea92ab65326001f83de4624834b5ed955
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 17971e383f97db0d398b86ae537448605f70894e |
|
15-Jan-2016 |
Shreyas Basarge <snb@google.com> |
Merge "Added priority to JobScheduler scheduling"
|
| 5db09084c8e4efc6311754243c39962fc8e7a766 |
|
07-Jan-2016 |
Shreyas Basarge <snb@google.com> |
Added priority to JobScheduler scheduling
Priority can be assigned to jobs. Higher priority
jobs can preempt lower priority ones. Reason for
calling onStopJob (timeout, preempt, etc.) is set
on the JobParameters object.
Reference:
https://docs.google.com/document/d/1fuVO5rBCkODx8wjk6uulFCP1Uzfx7IVsw2EyKKrGqVA
Change-Id: Ic36016514cec076984d44086316d8d00d896b3aa
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 89ee618280ea05e193afab38f9d2bf99b8274a92 |
|
17-Dec-2015 |
Shreyas Basarge <snb@google.com> |
Flex time for periodic jobs in JobScheduler
A periodic job will start only within time
satisfying period - flex < time % period < period.
Bug: 26254850
Change-Id: I97a840446e5592e5151d784800855d909f1790b8
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 2f3e35376ada0327b34a71d7c45ac6e6d955d7dc |
|
21-Dec-2015 |
Jeff Sharkey <jsharkey@android.com> |
More work towards triaging missing app behavior.
Many places across the platform query package details without
gracefully handling packages or components that go missing for
various reasons. This can cause annoying user data loss, such as
resetting back to built-in apps or dropping of accounts, etc.
This change verifies that system callers have thought about these
edge cases by logging if they use default matching behaviors without
explicitly marking themselves as being "triaged." (The logging is
currently disabled by default.)
Also creates explicit definitions of supported flags for various
incoming PackageManager calls, and defines a clear distinction
between flag types:
-- GET-style flags are used to request additional data that may have
been elided to save wire space.
-- MATCH-style flags are used to include components or packages that
would have otherwise been omitted from a result set by current system
state.
There are a handful of existing GET flags that better fit under the
MATCH definition, so this change clones them to new constants and
marks the old ones as deprecated.
Fixes bug in JobSchedulerService to consider jobs from apps on
external storage. Revert some dialer behavior back to being
untriaged.
Change-Id: I9b6ab0968241e3479bddbd78de0c51e3b9917318
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 5217cacbd9f382068bb9e176cd5a0b15388a335c |
|
20-Dec-2015 |
Jeff Sharkey <jsharkey@android.com> |
Make JobSchedulerService encryption aware.
When a user is started, but a persisted job component doesn't appear
in the normal resolution list, we avoid enqueuing the job. Later
when the user is unlocked, we take another pass over the pending
jobs to see if they became available.
Load keyboard layouts from XML metadata regardless of crypto status,
since we don't need to spin up any remote code.
Add MATCH_SYSTEM_ONLY to make system logic easier to write when
looking for trusted components.
Sprinkle more annotations on ArrayUtils methods.
Bug: 26279465
Change-Id: Iec28e0bb46862b07d740b12a79f6360de68dab0f
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 4cff8ac60ddc6f3838e51c61ee13e67d5aacdf7a |
|
10-Dec-2015 |
Shreyas Basarge <snb@google.com> |
Scheduling fix for JobScheduler
All ready jobs are now queued for execution when
a job completes execution or when a job becomes ready
and some other job is being executed.
Also fixes reporting of idle state.
Bug: 26131545
Change-Id: Ibadd95a31869e610c63fc147f9b10866a7439ac6
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| bef28feba57be7fd6a4d14a85a8229154338b2ed |
|
30-Oct-2015 |
Dianne Hackborn <hackbod@google.com> |
Initial stab at background check.
Actually, this implementation is more what we want for ephemeral
apps. I am realizing the two are not really the same thing. :(
For this implementation, we now keep track of how long a uid has
been in the background, and after a certain amount of time
(currently 1 minute) we mark it as "idle". Any packages associated
with that uid are then no longer allowed to run in the background.
This means, until the app next goes in the foreground:
- No manifest broadcast receivers in the app will execute.
- No services can be started (binding services is still okay,
as this is outside dependencies on the app that should still
be represented).
- All alarms for the app are cancelled and no more can be set.
- All jobs for the app are cancelled and no more can be scheduled.
- All syncs for the app are cancelled and no more can be requested.
Change-Id: If53714ca4beed35faf2e89f916ce9eaaabd9290d
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 627dfa1ddafc96b912ae938677a48a16f7ab255c |
|
12-Nov-2015 |
Dianne Hackborn <hackbod@google.com> |
Be smarter about determining when we can stop idle maintenance.
The device idle service now knows when the system is actively
doing significant things (syncs, jobs, alarms, downloads). It
uses this, when in an idle maintenance window, to determine when
it can end that window early -- when such work is no longer
happening.
For now this just allows us to shorten the windows. In the future
we should use this to allow us to expand the windows to a longer
potential time, adjusting future windows to shorter durations if
earlier ones use more time. This will allow us to batch occasional
long operations (such as downloads) into one window, making up
for that with much shorter later windows.
Change-Id: Ie482abd50bc43be9a8917a769a5175851eee4ec4
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| ccbf4e421189f60f94edbc6957a3ef125fb5e0b4 |
|
20-Oct-2015 |
Dianne Hackborn <hackbod@google.com> |
Merge "Initial implementation of light-weight idle mode."
|
| 08c47a5dece977a55d250d98bda9e2a8df8b6ed0 |
|
15-Oct-2015 |
Dianne Hackborn <hackbod@google.com> |
Initial implementation of light-weight idle mode.
This mode turns on after the screen has been off for 15 minutes,
and then cycles through 15 minutes of idle and 1 minute of
maintenance, ragardless of whether the device is moving around.
It currently only impacts network access and sync/job scheduling.
It does not remove access to wake locks or alarms for any apps.
It also doesn't report in the public API that the device is in
idle mode (since it isn't modifying the behavior of the power
manager) -- this is probably what we desire, since we don't want
stuff like GCM to be reporting these frequent changes.
We'll probably at least want to have the alarm manager do some
kind of more aggressive batching of alarms in this most (not allowing
more than one wakeup every minute?). That's for the future.
Also updated batterystats to include this new information, which
means the format of some of the data has changed -- device_idle
is no longer a flag, but an enum of (off, light, full), and there
is no information about time spent in light modes.
Also added new data about the maximum duration spent in both light
and full idle modes, to get a better understanding of how those
are behaving.
And did a little cleanup of DeviceIdleController, removing the
sensing alarm which was redundant with the regular alarm.
Change-Id: Ibeea6659577dc02deff58f048f97fcd9b0223307
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| aa9843198dec910a581bdc509d3937a9ea6ceca9 |
|
16-Oct-2015 |
Matthew Williams <mjwilliams@google.com> |
Change scheduling logic to run network jobs sooner
BUG: 24385082
BUG: 23144425
BUG: 18117279
Run jobs with connectivity constraints as soon as the developer-allotted
delay has expired, rather than waiting for the override deadline. This
is more in tune with what developers expect, although it reduces the
amount of batching the scheduler can theoretically do.
This will also have the side effect of fixing several failing cts
tests that started breaking b/c the signal to 'run connectivity
jobs early' was removed in M and nothing was put in to replace it.
Change-Id: I7e63c2b62f2882ee906f748445bbf10c32e19c5f
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 1bde39ad1424008917e1191565f81e0b4617f2fa |
|
07-Oct-2015 |
Matthew Williams <mjwilliams@google.com> |
Correctly reschedule failed periodic
BUG: 24341715
Failed jobs are rescheduled with no override deadline to avoid
running a failed job with unsatisfied constraints.
A periodic job always has an override deadline and the periodic
rescheduling code assumes this.
Hence a periodic that failed until eventual success would be
rescheduled in a bad state.
Change-Id: Id110b3522df2003506a9efdde4e719e1b9932106
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| b0ff32245cb6b51e43dd3ee40b86d683c62de2b9 |
|
04-Mar-2015 |
Amith Yamasani <yamasani@google.com> |
Throttle jobs for idle apps
First pass at delaying jobs from apps that are idle.
TODO: Throttle syncs
TODO: Provide a periodic point at which apps are checked for idleness.
Apps that switch to foreground process state are tracked by UsageStats
as an INTERACTION event that affects the last-used timestamp.
JobScheduler's logic for when an app is ready is trumped by the idleness
of the app, and only if the battery is not charging. When charging state
changes, we update the idle state of all the tracked jobs.
android package is whitelisted.
Bug: 20066058
Change-Id: I0a0acb517b100a5c7b11e3f435f4141375f3451f
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 2bf51f47d9e1b8563b58ce5ebde2f609d728fbf3 |
|
24-Mar-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix loop index.
Change-Id: Ib6827d58b3fec59f757f1051fb9a353da0c90c30
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 88e98dfa59e68a860d8c3b462ec03bc0b06d6b5c |
|
23-Mar-2015 |
Dianne Hackborn <hackbod@google.com> |
More work on device idle mode.
- There is now an API for people to find out about
its state.
- Moved DeviceIdleController to be closer to the
power manager implementation, since they are
closely related.
- Job scheduler now knows about idle state and doesn't
run jobs while the device is idle.
- Battery stats now keeps track of "idling" vs "idle mode".
Idling is when we consider the device to be idle,
independent of whether we are actually in deep idle mode.
This allows us to keep track of longer-term changes
independently of cycling in and out of idle mode.
- Battery stats also now keeps track of package changes in
its daily stats.
- Small optimization to network policy manager service to
not touch uids that do not have the NETWORK permission.
Change-Id: I0b3304fb3722c78cdfdd0c1eada7369ece7cbcf9
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 8ad2af7e5b28f71e7bdfc1bb097937c6c1d22b18 |
|
18-Mar-2015 |
Dianne Hackborn <hackbod@google.com> |
First stab at device idle mode.
Introduce a new device idle controller service that
monitor's the device state and determines when to go
in to idle mode. When in idle mode, all we do right
now is turn off network access the same as we do for
power save mode. Many more things should come in the
future -- stopping the alarm manager from scheduling
(most) alarms, telling GmsCore for it to stop doing
stuff, etc.
Battery stats now has state tracking for devie idle
mode, as well as events for the reasons we can come
out of idle mode (significant motion or the device
becoming active). Also added new events noting when
packages are installed.
Renamed the "low power" event in battery stats to
"power save" because the former was just way too
confusing.
Finally, fix buffer size reading kernel wake locks.
(Stupidly, just increasing the buffer size. Ideally
we should try to be smarter and grow our buffer to
fit the data available, but I'll leave that for
another time.)
Change-Id: I0be2062466c83ee9d890c6cf5a228d9cc4090eca
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| aad67a3e48ad1dc9a917e036f98021c6e4d1f748 |
|
21-Oct-2014 |
Christopher Tate <ctate@google.com> |
Don't cancel scheduled jobs when packages are updated
Only cancel the app's jobs when it is fully uninstalled, not when
it's being updated to a newer version.
Bug 18059252
Change-Id: I6cf617013ec8e9e9abd90e366d7a6ab0711790de
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 326f230ceba67a9b72d2606f7c503bef6f938ddd |
|
08-Oct-2014 |
Georgi Nikolov <geonik@google.com> |
BUG 17887323: Need to turn off DEBUG log spam in Job Scheduler
Change-Id: Ida7af915c5b616216692493434b63c521398dfb0
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 48a30db75dd0eedf8e065c89825b2af86a381b62 |
|
23-Sep-2014 |
Matthew Williams <mjwilliams@google.com> |
Fix lock ordering in JobScheduler
BUG: 17625667
Two part clean-up.
1) Don't try to lock in onControllerStateChanged. Do it in the handleMessage
instead where the rest of the locking is. This is sufficient to fix this bug.
2) The other side of the deadlock came b/c we lock when cancelling and calling
stopTrackingJob. Controllers handle their own locking so this isn't
necessary. B/c of a potential race from the controller side, added an explicit
check for the JSS to only run an expired job if it still exists.
Change-Id: Iaeebbc19437eb5b73e3ced3168f1fc13e564a4be
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 75fc5258b73b4b9b079a9383420a1d6b88575d72 |
|
03-Sep-2014 |
Matthew Williams <mjwilliams@google.com> |
Add timeout when waiting to bind to JobService
BUG: 17322886
bindService() to an invalid service might never actually result in
onServiceConnected being called , for e.g. if the client service doesn't
actually implement JobService. This wastes an execution slot as we end
up waiting forever.
Also made the javadocs clearer for the JobScheduler class.
Change-Id: Ie15ebbe18c0b7579f2ab77dd46428d354ef632c3
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| f973a7b17135535528ae6e792d38d4bf081b44c4 |
|
29-Aug-2014 |
Christopher Tate <ctate@google.com> |
Expand job scheduler dumpsys a bit
Now it actually says what jobs are active.
Bug 17322886
Change-Id: I1a0fe0bf8d4cb2988cc89a11793981037157ee07
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| d1c06753d045ad10e00e7aba53ee2adba0712ccc |
|
22-Aug-2014 |
Matthew Williams <mjwilliams@google.com> |
Implement API review feedback for JobScheduler
BUG: 17005336
Took the opportunity to clean up some back-off logic
Change-Id: Ibc8ae34d1d44dd064ba071e4cbad17872f7e38cf
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 9ae3dbeefcd6bc139c74bfe3d51de823e3be4b4b |
|
21-Aug-2014 |
Matthew Williams <mjwilliams@google.com> |
JobScheduler only run jobs for started users.
BUG: 12876556
Minor changes to test app to make persisting an option.
Change-Id: I1b40347878ec5ca44cd717ebfeb544f6c58473b5
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| bafeeb98135a7580cbcdd657818cd78f7bda35d8 |
|
08-Aug-2014 |
Matthew Williams <mjwilliams@google.com> |
JobScheduler needs to flush queue on charging
Also make it illegal to schedule a job with no constraints.
BUG: 16877705
Change-Id: Iae57286bc4f73163a7e3c9d2d531623fd50f1f72
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| be0c4175398ff5d7e13209e833b3037cdd0207d7 |
|
07-Aug-2014 |
Matthew Williams <mjwilliams@google.com> |
JobScheduler idle mode not being properly triggered
Issue with how the pending intent was being created -
the component name being explicitly set on the intent somehow
caused the intent to not be delivered.
Fix: no longer set the component name on the intent.
BUG: 16798118
Change-Id: I86b08b2a47067dc9b8da8b85450bc338e0826aca
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| ee410da42b6b8352213f03f7725fd041f703b035 |
|
25-Jul-2014 |
Matthew Williams <mjwilliams@google.com> |
remove possible JobScheduler race in cancel()
Client can jobFinished() before getting a cancel msg.
1) Do better clean up of JobServiceContext after client jobFinished()
to remove superfluous MSG_CANCELs
2) When processing MSG_CANCEL check whether the context is still active
3) Do JobServiceContext cleanup before calling back to JobSchedulerService
Client can get a cancel msg even after calling jobFinished() (opposite to above)
1) explicitly check whether there are any MSG_CALLBACKs in the queue before
processing a MSG_CANCEL. If there are we can throw away the cancel.
Bug: 16547638
Change-Id: I90644586c7895a9ce97de752a5d657faf7f74b78
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 01ac45b6ff2334925c8d24b5278b44e5e30f5622 |
|
23-Jul-2014 |
Matthew Williams <mjwilliams@google.com> |
Fix JobScheduler race condition
The loading of jobs from disk is now done sychronously.
Bug: 16372824
Change-Id: Ica0592d6de51e89662c9e49ed1eb59209b64356c
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 4a79daeaf72fe0c47f9d0605d6efe0c61885fe94 |
|
19-Jul-2014 |
Christopher Tate <ctate@google.com> |
Fix which index goes where
Change-Id: If4cf7efd4d7962eb5c10b487482653d86d92d2c6
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| fdb1956ff71ff57fcdaafaaeb7f42c19de3d7c2f |
|
12-Jul-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #15681802: Missing RESET:TIME in complete battery histories
But wait, there's more!
- Keep track of sync durations in the aggregated stats.
- Add events for users that are running and in the foreground.
- Rework the activity manager's tracking of stuff using
battery in the background to be based on proc stats, which
allows it to be better about determing when it should reset
its tracking of background work.
- Also add tracking of scheduled job execution, like we are
doing for syncs.
- And once I started hooking battery stats in to
JobSchedulerService, I found a few things I couldn't stop myself
from changing: (1) make it very explicit that it doesn't start
scheduling jobs until we have reached the point in system boot
where third party apps are allowed to run, and (2) adjust
the various for loops to not use iterators.
Change-Id: I69d812e27bcfee9e58a614f0f6b1c7545d7530b1
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 900c67fc51fc2672458dd1c9641250f2ecc01a31 |
|
09-Jul-2014 |
Matthew Williams <mjwilliams@google.com> |
Add job persistance as a setter in the API
Bug: 15936795
Change-Id: I11e5a722bab5838dc151670256ed09dfaa7fdaa7
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 5568f54e14e213ac100cacbbf57689faa6dd3d59 |
|
18-Jun-2014 |
Christopher Tate <ctate@google.com> |
Fix job service validation in secondary users
Bug 15714663
Change-Id: I101bcc979f30062bec36f462522227b857b58054
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 7060b04f6d92351b67222e636ab378a0273bf3e7 |
|
10-Jun-2014 |
Christopher Tate <ctate@google.com> |
Out with the old; in with the new
Switch to the official "JobScheduler" etc naming.
Bug 14997851
Change-Id: I73a61aaa9af0740c114d08188bd97c52f3ac86b7
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|