6466c1cc5efc4ff05fabdd670cf78a6a7ca45afb |
|
13-Jun-2017 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #62390590: SecurityException in JobIntentService$... ...JobServiceEngineImpl$WrapperWorkItem.complete When a job is in the process of stopping a job, we should no longer allow new work to be dispatched for it. Also there was an issue with how we determine wether a caller is valid for the current job -- this was only based on the uid of the currently running job, but of course that context could be re-used for a new job of the same uid. Instead, we now create a different callback binder for each client, so we can identify the exact client each time it calls back. (This also allows us to hang information about why the job last stopped on that client state, so we can always report it.) Finally make a bunch of classes final that should have been. Test: bit CtsJobSchedulerTestCases:* Change-Id: I1b00dd2da710414dd2898c4d39a5c528d54b95ea
/frameworks/base/services/core/java/com/android/server/job/controllers/ConnectivityController.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/controllers/ConnectivityController.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/controllers/ConnectivityController.java
|
8bbe7042739e4e047dfc1a1f6d6b48e6694c1927 |
|
15-Mar-2017 |
Christopher Tate <ctate@google.com> |
Don't run jobs when connectivity is not validated Previously, the job scheduler would run jobs with connectivity constraints as soon as "raw" connectivity was achieved. This could cause problems, though, because the device might be behind a captive portal or similar, so apps expecting to contact the internet would still see connect() failures or other unexpected results. We now run such jobs only when connectivity has been validated, so jobs have a stronger expectation that their needed internet access will be possible. Bug 28346529 Bug 36137931 Test: manual; use tethered phone hotspot, both with and without SIM, and verify that the 'validation' trigger is correct. Change-Id: I79194467610ef9611d38f871d01f92044d0ee9de
/frameworks/base/services/core/java/com/android/server/job/controllers/ConnectivityController.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/controllers/ConnectivityController.java
|
0ecfcd1e3a158ab5ee54d822d1a1166b15ba7a3c |
|
06-Sep-2016 |
Felipe Leme <felipeal@google.com> |
Refactored INetworkPolicyListener callbacks. Methods onRestrictBackgroundWhitelistChanged() and onRestrictBackgroundBlacklistChanged() were replaced by a more generic onUidPoliciesChanged(). Test: m javac-check RUN_ERROR_PRONE=true Test: m -j32 FrameworksServicesTests && adb install -r -g ${ANDROID_PRODUCT_OUT}/data/app/FrameworksServicesTests/FrameworksServicesTests.apk && adb shell am instrument -e class "com.android.server.NetworkPolicyManagerServiceTest" -w "com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner" BUG: 28791717 Change-Id: I18b2ee4af06802e0d23822b153d1be9b429d5811
/frameworks/base/services/core/java/com/android/server/job/controllers/ConnectivityController.java
|
576430f36ac04843fed5697ecae1716489c164bb |
|
01-Jun-2016 |
Dianne Hackborn <hackbod@google.com> |
Merge "Work on issue #28942589: Tune job scheduler" into nyc-dev am: 438693dd6c * commit '438693dd6cc4e3fe2ffb336d551c0d69e9546102': Work on issue #28942589: Tune job scheduler Change-Id: I9e4ddcc64d84a8d943128d8bd8ebf158743c5549
|
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/controllers/ConnectivityController.java
|
f45186e311a72780284ba00e6a266b487c3599da |
|
17-May-2016 |
Felipe Leme <felipeal@google.com> |
Merge "Added a onRestrictBackgroundBlacklistChanged() callback." into nyc-dev am: 2c6a450fa2 * commit '2c6a450fa23b97e6082e2daa1aa9c7f07a4def8f': Added a onRestrictBackgroundBlacklistChanged() callback. Change-Id: I4e19dd2828b8b67fc7b2d2173d77a82d67d53d19
|
99d5d3d7759883119665d928d110edb14df44ecc |
|
16-May-2016 |
Felipe Leme <felipeal@google.com> |
Added a onRestrictBackgroundBlacklistChanged() callback. When an UID is added / removed to the Data Saver blacklist, it's necessary to notify internal components such as the Settings UI (which was erroneously listening to UID rules changes instead). BUG: 28743623 BUG: 28791717 Change-Id: I11c85e141dfe074ad390fd324309d2412bfbbd45
/frameworks/base/services/core/java/com/android/server/job/controllers/ConnectivityController.java
|
e90dee0077f1e756dacc406aa803a2cad11ebd92 |
|
13-May-2016 |
Felipe Leme <felipeal@google.com> |
Merge "Fixed connectivity state in some power saving scenarios." into nyc-dev am: 25018d41f4 * commit '25018d41f482fe21a45eb2e739f22dc7cc937428': Fixed connectivity state in some power saving scenarios. Change-Id: I7ebe3864657d2147034ffae400312e94deb5ef35
|
781ba14af2a8c8e85f684208055dba0ebfd5db30 |
|
10-May-2016 |
Felipe Leme <felipeal@google.com> |
Fixed connectivity state in some power saving scenarios. NetworkPolicyManagerService (NPMS) manages 4 type of network restriction when apps are running on background: - Data Saver Mode (data usage restriction on metered-networks) - Battery Saver Mode (power restriction on all networks) - Doze Mode (power restriction on all networks) - App Idle (power restriction on all networks) These restrictions affects 2 parts of the system: - Internal framework state on NPMS which is propagated to other internal classes. - External firewall rules (managed by netd). Although each of the power-related restrictions have their own external firewall rules, internally apps are whitelisted to them through the same whitelist, and the current code is only updating the internal state (and notifying the internal listeners) when Battery Saver Mode is on. As a consequence of this problem, there are scenarios where an app correctly does not have internet access (because the firewall rules are properly set), but the NetworkInfo state returns the wrong state (like CONNECTED / CONNECTED). This CL fixes this problem by splitting the power-related logic from updateRulesForRestrictBackgroundLocked() into its own method (updateRulesForPowerRestrictionsLocked()), and making sure such method is called whenever the firewall rules are updated. Externally to this change, the CTS tests were also improved to verify the apps get the proper connection state; it can be verified by running: cts-tradefed run commandAndExit cts -m CtsHostsideNetworkTests \ -t com.android.cts.net.HostsideRestrictBackgroundNetworkTests BUG: 28521946 Change-Id: Id5187eb7a59c549ef30e2b17627ae2d734afa789
/frameworks/base/services/core/java/com/android/server/job/controllers/ConnectivityController.java
|
9a48ee1b3e9f3fe619505d71e235c509b01bc94c |
|
07-May-2016 |
Felipe Leme <felipeal@google.com> |
Merge "Fixed connectivity state in some restricted network scenarios." into nyc-dev am: 638a6e8140 * commit '638a6e8140a22a0ddb5d5dacb02173795073bd1a': Fixed connectivity state in some restricted network scenarios. Change-Id: I0fd66b16c83680940f294ea8e117443ffd8a50cd
|
d31a97fd83468d27d0f4c6e1455c2f6f59d5a7c9 |
|
06-May-2016 |
Felipe Leme <felipeal@google.com> |
Fixed connectivity state in some restricted network scenarios. NetworkPolicyManagerService (NMPS) keeps an internal list of uid rules (mUidRules) for network restrictions, and when these rules changes it needs to notify external listeners (such as ConnectivityService / CS). Prior to Android N, both Data Saver mode (the feature previously known as "Restrict Baground Data") and Battery Save mode used the same set of firewall rules to implement their restrictions: when Battery Saver mode NPMS would mark all networks as metered and set the proper firewall rules externally. Recently, these 2 modes were split in 2 distinct firewall rules and NMPS.updateRuleForRestrictBackgroundLocked() was changed to update the mUidRules logic based on the Data Saver firewall (since the Battery Saver firewall changes are handled externally, on updateRuleForRestrictPowerLocked()). As such, CS was not notified when the power-related changes were made, which would cause apps to get a state of CONNECTED / CONNECTED when querying its active connection. Another scenario that is not properly handled is when a UID whitelisted for Data Saver is brought back to foreground: although the proper firewall rules are set, CS is not notified, and the apps state would be DISCONNECTED / BLOCKED. This CL introduces many changes that fix this issue: - Fixed updateRuleForRestrictBackgroundLocked() to invoke onUidRulesChanged() when the Battery Saver status changed. - Fixed updateRuleForRestrictBackgroundLocked() to invoke onUidRulesChanged() when an app whitelisted for Data Saver is brought back to the foreground. - Added a new API (onRestrictPowerChanged() and getRestrictPower()) to notify external services about Battery Saver mode changes. - Fixed CS logic to properly handle the Battery Saver changes. Externally to this change, the CTS tests were also improved to verify the apps get the proper connection state; they can be verified running: cts-tradefed run commandAndExit cts -m CtsHostsideNetworkTests \ -t com.android.cts.net.HostsideRestrictBackgroundNetworkTests BUG: 28521946 Change-Id: I8eaccd39968eb4b8c6b34f462fbc541e5daf55f1
/frameworks/base/services/core/java/com/android/server/job/controllers/ConnectivityController.java
|
68e9dba7194ba8e8aaea21656f112910b446f257 |
|
04-May-2016 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fix issue #28477006: Add small event log to job scheduler" into nyc-dev am: 27c279d5c8 * commit '27c279d5c8f0c237c4b95bffebbfe2ca4b5b8d75': Fix issue #28477006: Add small event log to job scheduler Change-Id: I90df8c300de1d20d5a7f8af4cf4800e28d235b79
|
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/controllers/ConnectivityController.java
|
478806946ff96b41545ecba704de56f0344f3795 |
|
30-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
Merge "Flag to mark foreground jobs, fix data saver." into nyc-dev am: 9a977b7d45 * commit '9a977b7d45df0d3d59c5eec7f9534c3bd5fcd91d': Flag to mark foreground jobs, fix data saver. Change-Id: I908d725a84e9590d0da38a586b066a63473d4f28
|
1b6519bd87a59a10e9928e5772a17976692611da |
|
28-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
Flag to mark foreground jobs, fix data saver. When a job will eventually run in the foreground, the internal scheduling needs to ignore any background network restrictions when satisfying constraints. This also means the job should ignore the current device doze state, since the requesting app could get the same behavior by starting their own foreground service. Always dispatch network policy changes to ConnectivityService first to ensure that it has up-to-date information. Fix bugs around data saver that were causing networks to not be marked as BLOCKED for background apps; before this fix apps would have been spinning in internal connectivity loops, thinking that the network was actually connected when the kernel was actually blocking their traffic. Offer new ConnectivityService method overloads to ignore the blocked state for a specific UID. Print unsatisfied job constraints to aid debugging. Bug: 26571724 Change-Id: Iaaa17933e6dc1bf6d3dff26d0bfc12222e51e241
/frameworks/base/services/core/java/com/android/server/job/controllers/ConnectivityController.java
|
5df7298c590e97bc73ebf0d3ceda9ab8f809a136 |
|
25-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
resolve merge conflicts of c79a568 to nyc-dev-plus-aosp Change-Id: I3ee02bc596f285fa41ffcafa882ae5997ef67d22
|
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/controllers/ConnectivityController.java
|
8604c9423b06a5b6faa0305651565313cde841e1 |
|
09-Apr-2016 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fix issue #26879170: Adjust doze maintenance windows..." into nyc-dev am: 80d48f1 * commit '80d48f108e0b39fca57ffb4b98a25786ed8438f5': Fix issue #26879170: Adjust doze maintenance windows... Change-Id: Ieff76cb42407baf91c8e2d75e08302b1990d2f17
|
88c4135d88eb59320fe93801088bcd6c47e50efb |
|
08-Apr-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #26879170: Adjust doze maintenance windows... ...based on network availability There is a new light maintenance state "waiting for network" that we go in to after idle if the network is not currently available. We will stay in this state the same duration as idle, so if we are continually without network access this effectively doubles the light doze idle durations. Get rid of some wrongly copy/pasted code to allow doze light to still work even if we don't have an SMD. It doesn't need one. Also a bunch of improvements to the shell commands to make it easier to test / debug. Change-Id: Iad024840661479dbfd54b5b3db6ab96fefe59bc0
/frameworks/base/services/core/java/com/android/server/job/controllers/ConnectivityController.java
|
cfb472112dfac835950b4c53fdf921c569388114 |
|
06-Apr-2016 |
Dianne Hackborn <hackbod@google.com> |
Merge "More work on issue #26390151: Add new JobScheduler API..." into nyc-dev am: d273f0d * commit 'd273f0d659b2850a2956d94229a48f17df77a740': More work on issue #26390151: Add new JobScheduler API... Change-Id: I8e01e1695c6860d04655b9be06d2f10afc72d3e9
|
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/controllers/ConnectivityController.java
|
f099a95a75ea9c59ea8fc220408f6e478bcaa067 |
|
21-Mar-2016 |
wangshujie <wangshujie@xiaomi.com> |
Merge "JobScheduler: handle connectivity action in bg looper" am: bdddbdf am: 4d60e94 * commit '4d60e9400f359f9d60dc673a22de4620d5590da4': JobScheduler: handle connectivity action in bg looper
|
b49420a7151a98b3afa711f73d8dcea41f2b5101 |
|
16-Mar-2016 |
wangshujie <wangshujie@xiaomi.com> |
JobScheduler: handle connectivity action in bg looper in rare cases InputDispatcher relies on the SystemServer to enqueue the input events and wake it up (eg. with some accessibility services enabled which have their own inputfilters).Receivers in the main thread may block events dispatching and then we will peceive jank in windows. issue: https://code.google.com/p/android/issues/detail?id=204067 Change-Id: I1f47cc5cb8fb2b2aa0cee7a8ed4bf50efb81e477 Signed-off-by: wangshujie <wangshujie@xiaomi.com>
/frameworks/base/services/core/java/com/android/server/job/controllers/ConnectivityController.java
|
0529dac587b1361eac359737a5f10972bce5fd0d |
|
15-Mar-2016 |
Shreyas Basarge <snb@google.com> |
Fix for JobScheduler jobs not running If the device is powered off when a job is supposed to run, its delay and deadline both are set to 0 on boot. If the deadlineExpired alarm runs first, the job is discarded from TimeController's tracked jobs list. The delay constraint is never set to true and the job would never be executed. This behavior is fixed here. Dump modified to print jobId and uId instead of hash to make it more meaningful. Bug: 27619643 Change-Id: If03e3d6f194f15fe43b697dcb4198137fa7ed646
/frameworks/base/services/core/java/com/android/server/job/controllers/ConnectivityController.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/controllers/ConnectivityController.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/controllers/ConnectivityController.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/controllers/ConnectivityController.java
|
6078b50b017fbcf8d6cbf9f83226ed5667d5729e |
|
12-Jun-2014 |
Robert Greenwalt <rgreenwalt@google.com> |
Apply API Council comments to ConnectivityManager rename isNetworkActive -> isDefaultNetworkActive rename registerNetworkActiveListener -> registerDefaultNetworkActiveListener make listenForNetwork/requestNetwork take a NetworkRequest rename NetworkCallbackListener -> NetworkCallback rename listenForNetwork -> registerNetworkCallback rename releaseNetworkRequest -> unregisterNetworkCallback remove NetworkRequest param from NetworkCallback functions rename onNetworkCapabilitiesChagned to onCapabilitiesChanged remove onReleased change time units in onLosing from Sec -> ms bug: 15142362 Change-Id: Ibc96e3f461706efe1eafa0d85605249cfd6e9fdd
/frameworks/base/services/core/java/com/android/server/job/controllers/ConnectivityController.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/controllers/ConnectivityController.java
|