When disconnecting from a default network X and falling back on another
connected network Y as the new default, ConnectivityService was
attempting to record this event as a X -> Y "atomic" transition.
In practice the default network connectivity is actually lost and
recovering default network takes some non-zero time.
This patch changes the event recording to always record disconnection as
X -> 0 events. At the same time, if there is a fallback network that is
elected as the new default ConnectivityService will also record a 0 -> Y
event.
This patch also improves pretty-printing of DefaultNetworkEvent.
Extract from $ adb shell dumpsys connectivity_metrics_logger --events
17:51:00.086: DefaultNetworkEvent(0 -> 100:CELLULAR)
17:51:25.232: DefaultNetworkEvent(100:IPv4 -> 101:WIFI) # wifi goes on
17:51:44.064: DefaultNetworkEvent(101:DUAL -> 0) # wifi goes off
17:51:44.187: DefaultNetworkEvent(0 -> 100:CELLULAR)
Bug: 28204408
Change-Id: I63252633235bf6ba833b9ac431a80dda75a93e67
am: b5987d7993
* commit 'b5987d79937b2f1b0ec68c84371aea36f7e2b8a1':
Fixed enforceMeteredApnPolicy when Data Saver is on.
Change-Id: If9e525f86b29960ed4dfdd6ca27bc5d0077454ae
am: efd3a1749f
* commit 'efd3a1749f2737199643cc29bea6132a9786223b':
Fixed enforceMeteredApnPolicy when Data Saver is on.
Change-Id: I87b596346c058c7ac8efbebb67b43664f1be0fed
When enforceMeteredApnPolicy() is called when Data Saver mode is on and
the caller's UID is not whitelisted, it should add a
NET_CAPABILITY_NOT_METERED to the capabilities.
Change-Id: Ieed4f4a7634ee023ec58c91859263655e0ba62d4
Fixes: 28608499 (and https://code.google.com/p/android/issues/detail?id=208478)
am: d198b4d891
* commit 'd198b4d891b704965bfc569da00c6206ece87177':
Lock down networking when waiting for always-on
Change-Id: I50583a9738ac51378e5f5dcbbaa396f1aa30f97c
am: 1540a79a8b
* commit '1540a79a8b65e1f2652f4882784d6386f9661cae':
Lock down networking when waiting for always-on
Change-Id: I7be0a85597936421750d1da0fde3d55d7d4fabc5
am: 1cd027befe
* commit '1cd027befe8206fe4c33b1efff2bebb0584c138c':
Make some of the UID-based VPN code reusable
Change-Id: I75d9871f8039d14f8d83be4696c3c4d4e864f9c0
am: b0f3016b64
* commit 'b0f3016b64552674681dbc742667203d36c4c86d':
Make some of the UID-based VPN code reusable
Change-Id: I3f1b1a08059aa58cb76db6cdd070b103024b9bf3
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
am: 3d079f210c
* commit '3d079f210cce78d6d87220b289a68de97ae263b4':
Fixed connectivity state in some power saving scenarios.
Change-Id: Idd27e581b208a0d80d8fa6a4d7cf75eac82a32fd
am: cc02a95cbd
* commit 'cc02a95cbd694927cd70d7b0d7921d3f10300b38':
Fixed connectivity state in some power saving scenarios.
Change-Id: I9ce60e8520c041e1345960a51394f8477c4ac49e
am: 942ee1159f
* commit '942ee1159f45c13029c28dc7846d6773571f6cda':
Fixed connectivity state in some power saving scenarios.
Change-Id: I7ebe3864657d2147034ffae400312e94deb5ef35
By changing some member refs into arguments and having one of the
functions create the UID range instead of adding to mVpnUsers.
This will be useful for other layers of UID filtering like having
UIDs explicitly blocked from the VPN.
Deleted one broken line of code that cleared the status intent when
a restricted profile is removed. Other than that, this commit shouldn't
change any behaviour. If it does, that's a bug.
Bug: 26694104
Change-Id: Ieb656835d3282a8ba63cc3f12a80bfae166bcf44
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
am: 1f186ce13b
* commit '1f186ce13bf383be39bd4b610bcb3e69f2882899':
Addressing API council comments on NetworkStatsManager.
Change-Id: Ie6455799758f0bdb67440f72c266effaf412e22f
am: dc5f558640
* commit 'dc5f558640da8785fabc274167ec37a0fda30cd6':
Addressing API council comments on NetworkStatsManager.
Change-Id: I952e69e7cfbd8cebcbac7c3b19ede300e26777e8
Callbacks
- DataUsageCallback renamed to UsageCallback
- DataUsagePolicy removed; passing in params directly to register method
- making it an abstract class
- passing in (networkType, subscriberId) that reached its threshold
- renaming onLimitReached to onThresholdReached to match existing naming
- only monitor single network,subscriberId
- no monitoring of specific uids; using device or user wide instead
Tags
- only owner uid can read its tags
- exposing only TAG_NONE to match service side
BUG: 27530098
Change-Id: I2b2664da71806868a1e937d2bf4d1f234637509b
am: d9c0f5c6a1
* commit 'd9c0f5c6a1e2c16b61ed0d87b5533aed295273c9':
Fixed connectivity state in some restricted network scenarios.
Change-Id: I1bc51c4a06dad9245ce0ed884707855b2c04edf1
am: 87d20317bf
* commit '87d20317bf26e87ef58798d3c5aafb81aa163788':
Fixed connectivity state in some restricted network scenarios.
Change-Id: Ifeb332fbf00c554b78d0ad724b34e3a8ebfc9894
am: 638a6e8140
* commit '638a6e8140a22a0ddb5d5dacb02173795073bd1a':
Fixed connectivity state in some restricted network scenarios.
Change-Id: I0fd66b16c83680940f294ea8e117443ffd8a50cd
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
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.
This change refactores the mUidRules to use bitmasks, in preparation for
another change that will fix the issue.
It also fixes a minor bug that was preventing removed packages to be
removed from the whitelist.
BUG: 28521946
Change-Id: I9f0e1509a6192cad403f740c1cd76a6b7dab7d26
am: fbde3272fd
* commit 'fbde3272fd4e49ab269920339793bc40d0cb9628':
Start VPN as early as possible during startup
Split network agent created state from connected state
Change-Id: I6e1d6a1977db342f45a1a9114a56c181540e12bf
am: 31b3676cce
* commit '31b3676ccec847b1e86c23b2f5073dc1cc83abf4':
Start VPN as early as possible during startup
Split network agent created state from connected state
Change-Id: I6bb605a83b96a3efab36ab6a7bdb5859e1eafea8
am: 9677633814
* commit '9677633814868394f11097c549cea65155f80c29':
Start VPN as early as possible during startup
Split network agent created state from connected state
Change-Id: I55167ad8f3cde11407a2d35b0f859c263c0fbbec
- Switch from USER_STARTING to USER_STARTED which is the foreground
version of the broadcast
- Set the new VPN network as CONNECTING initially to avoid spamming
apps with useless notifications ahead of the network being fully
available
Bug: 26694104
Fix: 28335277
Change-Id: I31d5260dda62ff440c31c44eb0aa5c891e2717e5
Network creation setup sometimes involves extra steps after actually
calling into netd to create the underlying network, rules & routes &
to begin allowing sockets bound to it.
For example, VPN networks can set a UID whitelist or blacklist. This
should happen:
- AFTER there is a netID & network created in netd as
network-specific rules will need to be tied to / point at it. Those
rules are tied to the lifecycle of netd's network which is tracked
by `NetworkAgentInfo.created` on the frameworks side.
- BEFORE the CONNECTED broadcast and network callbacks have been sent
out so that we don't create a race condition between clients that
want to use the network and the server actually having the network
ready
The race condition existed prior to this change and required any client
making use of network callbacks to sleep for a short amount of time after
receiving to actually be able to use the network.
Among other things, that race condition is now fixed.
Bug: 26694104
Change-Id: Ied92f5588a98c3e97f456bc98b676bf201ab5472
Allows callers to opt-out of blockading network traffic during boot and
on VPN app failure.
Bug: 26694104
Change-Id: Ibfbd43ad09a25f2e38053fcd6306df3711f8bde2
