The basic principle is: if an app's traffic could possibly go
over a network without the app using the multinetwork APIs (hence
"by default"), then the status bar should show that network's
connectivity.
In the normal case, app traffic only goes over the system's default
network connection, so that's the only network returned.
With a VPN in force, some app traffic may go into the VPN, and thus over
whatever underlying networks the VPN specifies, while other app traffic
may go over the system default network (e.g.: a split-tunnel VPN, or an
app disallowed by the VPN), so the set of networks returned includes the
VPN's underlying networks and the system default.
Specifically:
1. Add a NETWORK_CAPABILITY_VALIDATED bit to NetworkCapabilities.
2. Add a hidden API to retrieve the NetworkCapabilities of
all default networks for a given macro-user.
3. Modify the status bar code that used getActiveNetworkInfo to
determine which network was active, and make it consider all
validated networks instead.
4. Because the set of active networks depends on which VPN app
the user is running, make the status bar re-evaluate the
networking situation when the active user changes.
Bug: 17460017
Change-Id: Ie4965f35fb5936b088e6060ee06e362c22297ab2
Define and print a compact version of network statistics when dump
is requested with the "--checkin" flag. Defaults to last 24 hours,
but included data can be tweaked with various flags.
Groups together detailed network identities into larger umbrella
terms like "mobile" and "wifi."
Bug: 18415963
Change-Id: I70cf9c828ea5c6e5bb6884837d3608f66fbad2e6
These are used when responding to getActiveNetworkInfo() (and cousins)
when an app is subject to the VPN.
Bug: 17460017
Change-Id: Ief7a840c760777a41d3358aa6b8e4cdd99c29f24
The previous code retrieved information from the legacy tracker multiple
times for each user query, leading to race conditions where the info
could've changed between the calls.
Refactors the handling of legacy data types in ConnectivityService and
unifies call paths so that APIs that deal with legacy data types
(NetworkInfo and int/networkType) and newer types (such as Network) go
through common code paths, using NetworkState to hold all the necessary
data pieces. This enables follow-on bug fixes to getActiveNetworkInfo().
The changes are limited to public "query" APIs (those that retrieve some
network information or the other). More details about the specific
changes and their rationale can be found in the code review thread.
Bug: 17460017
Change-Id: I656ee7eddf2b8cace5627036452bb5748043406c
Do not use LOG_FATAL_IF in JNI setup. This is one-time on startup
and important enough to always check.
Add a header with common helper definitions. Move to inlined functions
instead of macros to clean up the code.
Change-Id: Ib12d0eed61b110c45d748e80ec36c563e9dec7e5
ConnectivityManager.requestNetwork(NetworkRequest, PendingIntent)
was unhidden and implemented.
Added ConnectivityManager.removePendingIntentRequest(PendingIntent) as
the companion method.
Bug: 17356414
Change-Id: I656a1e149cc1292c443ebfe9e61ee3eb5a80f143
We're starting to get network requests for specific SIMs
and the Legacy Type Inference was broken because the incoming
request included a network specifier while the legacy requests
it was compared with did not. Only compare the things we care
about.
bug:18031008
Change-Id: If107042828c152ede51a2497a3859bc1a6c83694
setDomain() and toLinkProperties() were not setting the domains.
The setDomain() bug affected Wifi and I believe the toLinkProperties()
bug affected Ethernet and Bluetooth reverse-tethering.
bug:18252947
Change-Id: I8764cb944c293e01d99822bb52b55af7e9d77853
Once optimistic addresses become useable upon kernel notification
there will be no need for a connectivity delay.
This change requires kernel changes like:
https://android-review.googlesource.com/#/c/109934
Bug: 17769720
Change-Id: I8510c540aa655aad6a82ee322d591331357ee272
If the kernel sends notification of an optimistic address then
treat is a useable address (isGlobalPreferred()).
Note that addresses flagged as IFA_F_OPTIMISTIC are
simultaneously flagged as IFA_F_TENTATIVE (when the tentative
state has cleared either DAD has succeeded or failed, and both
flags are cleared regardless).
Additionally: do not consider RFC 4193 ULA addresses sufficient
for "global preffered". They are, by definition, of global scope
but not sufficient for global reachability.
Bug: 17769720
Change-Id: I759623b28fd52758f2d4d76d167f3cafd9319d6a
This simplifies callers.
Also remove all "implementations" of addStackedLink and
removeStackedLink except the one in LinkProperties, because they
are unused.
Bug: 12111730
Change-Id: Ie294b855facba4b1436299dcb3211b72d9ba448e
Specifically:
[1] provide a hasIPv4(), and
[2] a hasIPv6()
each of which requires an IP address, a default route, and
address-family-specific DNS servers to evaluate to true.
Additionally:
[3] redefine isProvisioned() to return the logical OR
of [1] and [2] above.
Any external caller can still use any of the has*() methods to
construct its own, different definition of "provisioned".
Bug: 17769720
Change-Id: Ia692fb8508484ff403d3920c94d0e1db4563f807
Most of this logic is simply removed from ConnectivityService.
The captive portal detection is now done by the NetworkMonitor.
The notification logic is still left in ConnectivityService as
it's used by both the NetworkMonitor and telephony's mobile
provisioning logic.
bug:17324098
Change-Id: Ibd1c42b1a75795f90a6483d3d0a5a14f88b193d8
Now that we support unreachable routes, use those to block
address families on VPNs. This is a much more elegant solution.
Also update LinkProperties when IP addresses are added and
removed, fixing a TODO.
Bug: 17462989
Change-Id: Ib749d84710dca70d672350b9f129bb91419ec77e
The BT and Wifi mechanisms for enabling Tethering did their own
permission checks. This set of changes unifies the check into
a ConnectivityManager function so they can be kept in sync.
bug:17435527
Change-Id: I8c157a5acf56ffbddd349cb6a45160ae7be8541b
