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
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
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
Internal logic relies on Arrays.copyOf(), so always give ourselves
valid arrays, using shared empty objects to save overhead.
Bug: 17502649
Change-Id: I5dbb00545bdfe45bbd48144ab505ea08cc92cbcd
Currently just valid/invalid based on NetworkMonitor findings.
Changed NetworkMonitor to start out in default state since starting in Offline causes
a spurious invalid report at creation time.
Added some logging.
bug:17395269
Change-Id: I9ae650b561834d8f8979033744d97df852e76df9
HttpHandler and HttpsHandler classes have a lot of bug fixes baked into
them that the Network.openConnection() API should be using, for example
disabling SPDY support.
bug:17420465
Change-Id: I9f1472753a542d1dd6bffde3a60c37a9145098aa
Future HTTP requests could use an old socket that's bound to a different Network
causing unexpected results. DNS results could also not be appropriate.
bug:17283566
bug:17432215
Change-Id: I88b40b723c7b442000cafe8ce8b9d989d8995991
Network Factories are allowed to go below, but networks need to be
constrained. Allowing the network to go below 0 meant that -1 could
sometimes leak through and foul the logic.
The core of 17361330 will be fixed when we stop sending scores for
listens to NetworkFactories, but it exposed this issue too. Summary:
1 - add a network listener. This isn't a request so it's not sent
to networks.
2 - alter your score (ethernet sets score to -1 when the link goes
down) (16:07:39.782)
3 - a bug in ConnectivityService causes score changes to get sent for
all network requests and network listeners causing NetworkFactories
to no see 2 entities. This bug will be fixed by a pending change
(https://googleplex-android-review.googlesource.com/#/c/540840/).
This causes the ethernet NetworkFactory to see two entities, both
served by networks of score -1. (16:07:39.989)
4 - disconnect Ethernet - this only sends 0 scores for known
requests, not network listeners. Had it been sent for both entities
they both would have evaluated that the networkfactory score (-1)
was lower than the request score (0) and both released their
refcount. (16:08:03.147)
5 - this means the listener is tracked by the EthernetNetworkFactory
with a score of -1 while the factory itself has a score of -1 so the
network release isn't called.
bug:17361330
Change-Id: Ife34ca0f9c233dd3c3df80f6fea580af43afcdeb
Using reflection you could do this and it would crash the system.
Thanks, ServiceFuzzer!
bug:17379629
Change-Id: I8b470bda78a69761ccd92496746f5d295b5d07f2
This constructor does nothing, including doing nothing with its
only argument. This causes it to return a NetworkInfo for
TYPE_MOBILE no matter what was passed in.
Bug: 16610051
Change-Id: I4ccd5ec050f7824fb06496c00fcd7901defeb7bd
If we don't do this, per-network HTTP requests will go over the
wrong network if any previous HTTP request was made by the same
app on another network.
Bug: 17300006
Change-Id: I1854c16dee6adb9e81fb12b097577439d69a644e
This makes tethered clients use the correct DNS servers when
tethering to non-default networks like the DUN APN.
Bug: 16357676
Change-Id: I8933b6de198a92c2aaf0291931ace8966ddba275
This reverts commit e0101cd and removes the related NetworkMonitor code.
The thinking is the broadcasts are not robust enough as they rely on apps
working together and are not sufficiently tested.
bug:17115050
Change-Id: I433032867cc4fea7191a1b13842b16825dc74df4
