It's with the rest of the logic now and allows checking whether the
lockdown state matches, too, which led to a lot of misunderstandings.
Fix: 29199431
Change-Id: I94a2c38c4837f9c33b5b9c2becb52eeb7e2a2534
All users should be made aware a captive portal is in place and be
given the opportunity to sign into the network. Without this fix
other users are not notified and given a chance to sign-in.
Change-Id: I1bf823d5f6a36f391dca4be5f6a584e8562a72a7
Fixes: 23079964
Fix 2 problems of always-on vpn after always-on package is removed
1. Prevent network being locked down (blocking all network traffic)
Otherwise, user has no way to download the vpn app from Play Store,
and never be able to gain control of the network again.
2. Allow user to connect other vpn app.
Implementation
1. Switch off always-on mode if the package gets removed.
2. Restart always-on mode if the package gets replaced/upgraded.
Bug: 29050764
Change-Id: Id3e389ae0b11c6002a5167919292d9634c2014cb
Previously this was included in the log messages from NetworkMonitor
but that has been removed (ag/944107), making it frequently impossible
to know what network the logs apply to as there may be no way to
correlate NetIDs to WiFi SSIDs or Cellular networks if the log has wrapped.
Bug: 26075613
Change-Id: I2e3cd41fffb616ab9f855cb16790360bd3414793
Cause: It revoked the user consent of the vpn app without reseting always-on vpn.
In addition, prepareVpn sets legacy vpn as the current package, the state in
Vpn.class is broken, as it thought the current always-on package is legacy vpn,
(mAlwaysOn is only for app vpn, not for legacy vpn). As a result, prepareVpn rejects
all VpnService.prepare.
Bug: 29031820
Change-Id: Id6bf1d6f38cf134a872811806301b8a602fb5725
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
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)
This stops Settings from telling the user detailed information, and
doesn't really protect anything secret -- privileged apps can already
tell that there's an active VPN by looking at network info.
Change-Id: I9c2a3cab6dff1b62e94a9e0735dccde226fd26a3
Fix: 28624328
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
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
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
- 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
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
Moved several USER_STOPPING registered receivers to listen
to USER_STOPPED, since they don't need to be blocking the
shutdown of the user.
Clear all stale broadcasts when stopping a user, so that we
don't unnecessarily start up processes and deliver stale
broadcasts. This was causing code to run when the user was
already stopped and resulted in crashes when other providers
and services couldn't be started anymore. Hopefully this fixes
many of those races.
Bug: 28371487
Change-Id: Ic35a7a23fa8fe009a53f8bf7545d4dad5fa34134
If tethering is on when Data Saver mode is turned on, tethering should
be disabled, and vice-versa.
BUG: 28313291
Change-Id: I7f3dadbd97ea1492ab76b41043dea7487c1db02d
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
This patches changes how captive portal tests and network lifecycle
events are logged as connectivity events:
- it splits NetworkMonitorEvent into two event classes:
- ValidationProbeEvent for logging individual probe events.
- NetworkEvent for logging network connection, validation,
lingering, and disconnection.
- it removes the redundant CaptivePortalCheckResultEvent class.
The information logged in CaptivePortalCheckResultEvent was already
logged by NetworkMonitorEvent, but missing the evaluation durations.
It is now logged by ValidationProbeEvent.
- it removes the CaptivePortalStateChangeEvent class, which is now
redundant with NetworkEvent, but missing evaluation durations.
In addition, it adds event logging when ConnectivityService puts a
network into lingering or removes a network from lingering.
Bug: 28204408
Change-Id: I8f9752e4d36175ecfcbd1545a01a41bad6e06ea4
When users add or remove an app to the Data Saver Mode whitelist, the
app is notified through a
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED. But besides this
broadcast, it's also necessary to notify internal apps such Settings,
hence a new method is being added to INetworkPolicyListener.
BUG: 27481520
Change-Id: I1537a77becf6b7da1535ed5faabdc894fd9f7084
Transport may use the redirect to make additional determination about network
state.
Bug: 25203607
Change-Id: I07d8918f13fdcbe0b6fd757536bfc1850a2a244f
Callers with CONNECTIVITY_INTERNAL permission can read off the netId
that an application is assigned to by default.
Necessary for making connections as the default network for a client
app eg. when downloading stuff on its behalf.
Bug: 27074270
Change-Id: I8d35e8e99126875f55f3c545090326f3e9be43fb
Since Lollipop, routes are isolated within Networks. Flushing a
Network's DNS cache whenever that same Network's routes are updated
doesn't provide any benefit. Any system components depending on this
behaviour need to uncovered and fixed.
Additionally, clean up no-longer-used flushNetworkDnsCache(). This
should be replaced, when needed, by a proper binder interface to netd.
Change-Id: I34bf79e4839da014d466058a876d754209d0c007
There's a few advantages to having ApfFilter in IpManager:
1. If things go wrong, crashing a particular transport is less bad then
crashing ConnectivityService. We also don't want to use
ConnectivityService as a dumping ground for transport-specific logic.
2. This makes implementing WifiManager.MulticastLock a lot simpler and
safer because enabling/disabling it doesn't have to go through the
NetworkAgent, which could risk various races (e.g. installing a filter
into the wrong WiFi network).
3. IpManager is the ultimate source for LinkProperties for a particular
transport and since ApfFilter uses the LinkProperties it's better to
have it closely paired with the IpManager. Likewise, ApfFilter needs
to know the APF capabilities of the transport, so having it in
the transport avoids having to parcel this information through the
NetworkAgent.
Bug: 26238573
Change-Id: I99b85f2b64972f0e7572170ec5d1926081aa3429
Felipe Leme
commited 
Robin Lee
authored and
Android (Google) Code Review
commited 
Paul Jensen
authored and
Victor Chang
commited 
Hugo Benichi
authored and
Lorenzo Colitti
authored and
Pierre Imai
commited 
Jeff Sharkey
commited 
Amith Yamasani
commited 
Narayan Kamath
commited 
Erik Kline
commited