1. Always keep ConnectivityService's validated bits current:
- Apply the validated bit whenever a NetworkAgent updates its
NetworkCapabilities.
- Set or clear the validated bit whenever lastValidated changes.
2. Send callbacks when the validation state of a network changes.
3. Delete getNetworkCapabilitiesAndValidation, removing code
duplication with getNetworkCapabilities.
4. Add the validated bit to NetworkCapabilities#toString.
Bug: 18591282
Bug: 20081183
Change-Id: I6aa53b61c15cc137f203f9fc6bbd4c16894be750
Settings and SystemUI need to act on other users than USER_OWNER.
This is gated by INTERACT_ACROSS_USERS_FULL in addition to the existing
CONTROL_VPN checks, so the number of processes able to interfere with
other profiles' VPNs should be quite small.
Bug: 20692490
Bug: 20747154
Bug: 20872408
Change-Id: I6e5d7220f73435bec350719e7b4715935caf4e19
All ConnectivityManager APIs taking a network type have been
deprecated so there should be no need to validate a network type.
bug:20647016
Change-Id: I2dcf24f58016e94aa814dda38cfc848366cc461c
Because LegacyTypeTracker#remove can send broadcasts that cause
apps to refresh their view of network state, it needs to be
called only after network state has been updated. This requires
that callers determine whether the network was the default, and
updating state, before calling remove().
While I'm at it, fix maybeLogBroadcast's concept of whether the
network it's logging about is/was the default. This has never
been correct.
Bug: 20613953
Change-Id: Ia175ac454aa4e0a4c4f0151866314ebada681438
This enables persisting the mobile internet data connection, even
when Wi-Fi is enabled and serving as the default network (for faster
network switching).
Change-Id: I9d1512b3a8413c4f163c63d57e66bded017101e4
The ConnectivityManager documentation uses {@link requestNetwork}
without specifying which version of that method it refers to.
This results in javadoc incorrectly linking to the version of the
method that takes a PendingIntent instead of the version that
takes a callback.
Change-Id: Ia914ec88005a6401b6391c5b4fc92f988baa3922
Track apps going in and out of idle in the NetworkPolicyManagerService.
Apply DROP rules in firewall controller if app is to be blacklisted
for network access.
Firewall can now be in whitelist (old) or blacklist mode. When in
blacklist, it allows all by default and we can selectively DENY
some uids.
Track app idle in UsageStats and update periodically.
Track charging/discharging states.
TODO: Check for appidle temporary parole state
Bug: 20066058
Change-Id: Ia65d7544204b3bcb78a517310ef4adcc05aac6fb
The documentation for setProcessDefaultNetwork does not
mention that it requires ACCESS_NETWORK_STATE, but a process
without ACCESS_NETWORK_STATE that calls it will crash because
we can't fetch the proxy properties.
Because ACCESS_NETWORK_STATE is not required to obtain a Network
object (Network objects can come from broadcasts too), it may not
be reasonable to require the permission. We did not do so in L.
For now, ignore the failure and don't crash the app. I've filed
http://b/20470604 to track a longer term fix.
Bug: 20081183
Bug: 20423580
Bug: 20470604
Change-Id: I158016130b4afb1d300357fe703804d2e7bc609b
The compatibility measure introduced in bug 20081183 for apps
that connect to a Wi-Fi network without Internet access and then
expect to be able to use that network requires that such apps
register a NetworkCallback so that their WifiManager can pin them
to whatever wifi Network connects.
Currently, registering the callback requires ACCESS_NETWORK_STATE
and the app may not have that permission. Allow registering wifi
(only) callbacks if the app has ACCESS_WIFI_STATE.
If the app does not have ACCESS_WIFI_STATE (unlikely, since
CHANGE_WIFI_STATE is not very useful without ACCESS_WIFI_STATE),
then don't enable the compatibility measure.
Bug: 20081183
Bug: 20423580
Change-Id: Iad328d30c2d170dead883868fece3d922da68f6f
Since the demise of the connectivity change delay,
CONNECTIVITY_ACTION_IMMEDIATE has been sent out back to back with
CONNECTIVITY_ACTION.
Interested parties should watch for CONNECTIVITY_ACTION.
Bug: 20013379
Change-Id: I072dddf95adb3bbd17fa1f7159d4ea848ade8f19
Since the demise of the connectivity change delay,
CONNECTIVITY_ACTION_IMMEDIATE has been sent out back to back with
CONNECTIVITY_ACTION.
Interested parties should watch for CONNECTIVITY_ACTION.
Bug: 20013379
Change-Id: I072dddf95adb3bbd17fa1f7159d4ea848ade8f19
