| 43d2a1700b6eb1d804924c6a1e5e0161a13a5348 |
|
12-Jul-2017 |
Jeff Sharkey <jsharkey@android.com> |
Move "metered" persistence to WifiConfiguration.
For a long time we've had a nasty tangled dependency between Wi-Fi
and NPMS, since they both persisted different details for configured
networks. As part of preparing for new carrier data plan APIs, move
the tracking of meteredness over to WifiConfiguration.
This also cleans up how meteredness is communicated through
NetworkAgents to rely completely on NET_CAPABILITY_NOT_METERED by
removing the metered flag on NetworkInfo, which has caused confusion
and staleness.
Migrates any existing user-configured metered networks over to
WifiConfiguration once the device finishes booting.
Remove support for NetworkQuotaInfo, since this information can no
longer be made available to apps. Frustratingly, some apps are
using it, so keep the object around returning stub values, and shame
them in the logs.
Bug: 63391323
Test: builds, boots, Wi-Fi policy is upgraded
Exempt-From-Owner-Approval: Bug 63673347
Change-Id: I64f865ddeb65cfcd330f8d2a847368abdf960a07
/frameworks/base/services/core/java/com/android/server/job/controllers/ConnectivityController.java
|
| 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
|