Reduce the duplication of some logic so when falling back to Cellular
when WiFi fails to validate is enabled, there's less chance for bugs
and failures:
1. De-duplicate several Network vs NetworkRequest matching functions
2. Remove the very tricky nascent logic by adding a simple "lingering" bit.
Bug:20896761
Change-Id: I21da9e827eec9cfd6835fcaa650192b9186ed053
Move reachable DNS server computation out of ConnectivityService
and split it into LinkProperties#isReachable() and a companion
change in WifiStateMachine's makeLinkProperties().
Restore previous ConnectivityService#updateDnses() behaviour, as
the pruning is done in WifiStateMachine now.
Bug: 19470192
Bug: 20733156
Bug: 22098233
Change-Id: I810ef74d504e5dc1ca2017d435cdadd6b82171e6
This serves no purpose and adds several log messages every time a
network disconnects. The extra log messages contribute to
NetworkMonitor's chatty-ness and towards it getting muted.
Bug:21480101
Change-Id: I372f9939c534f77b052a15fdb2cd5288d19ddbab
Occasionally, "dumpsys connectivity --diag" will show measurement
results without success or failure messages. Properly record the
error before decrementing the countdown latch.
Bug: 20733156
Change-Id: Ic654dedb753a65a96fe870f79fb296fbfc459fcb
Currently, when connecting to a network that has a captive portal
or has no Internet access, we display a regular notification.
Because this notification is easy to miss, switch to using a
heads-up notification if the user just manually selected the
network. If the system connects automatically, continue to use a
regular notification.
Bug: 20081183
Change-Id: I7a988b2bddfe898a0d2607ad85a04b227d678469
With bursty WiFi traffic, we end up sampling the WiFi controller's
energy data quite a lot. Extend the timeout so that we sample
once there has been no activity for 15 seconds.
Note: Once the WiFi radio goes down after being active, it can come back and be
active in less than 15 seconds, which means we may sample twice quickly.
Bug:21478443
Change-Id: I99081b664f8a33fef734bc55eef4d33ac297e83a
It's not clear what it means to request a network with a mutable
NetworkCapability like NET_CAPABILITY_VALIDATED or
NET_CAPABILITY_CAPTIVE_PORTAL. Presently requesting such a network
would fail in a number of different ways:
1. The NetworkFactories would fail to match the request against their
filter which doesn't include stateful NetworkCapabilities.
2. If the NetworkFactories did match, they'd bring up networks to try
and satisfy the requests, but the networks would not have any
mutable NetworkCapabilities initially so they'd be reaped.
Because of these problems it's safest to simply disallow these
requests.
Bug: 21343774
Change-Id: I56303242b81d39b370b8d5d1e32059bfcfc25949
Without this fix if a listening NetworkRequest with NET_CAPABILITY_VALIDATED
is submitted after a network has been validated but failed the most recent
validation attempt, the NetworkRequest will never receive callbacks.
Bug: 21343774
Change-Id: I6fa6d563c9a6f278b20e645776b707559033b249
Before falling back to cellular we used to first delete all the
network routing tables and rules for WiFi. This isn't necessary
and can take significant time as it requires a lot of netd
shelling out to ip and ip[6]tables to flush routes and remove
the incoming packet mark rule. Instead have netd delete all the
network routing tables and rules after we've either fallen back
to cellular or at least kicked off a cellular connection attempt.
Bug: 21932815
Change-Id: Iabac4a8b962492682df3073cc41a12e35bc9f1bb
Without this API we're more or less encouraging apps to have long running
processes (battery draining) to receive NetworkCallbacks for the stateful
NetworkCapabilities NET_CAPABILITIES_VALIDATED and
NET_CAPABILITIES_CAPTIVE_PORTAL. With this API they can instead using
PendingIntents which outlive their apps.
Bug: 21343774
Change-Id: I168d0ac3757729acf7ca5546079846f575a0eedd
Select only DNS servers that:
- are reachable, according to routes in the LinkProperties, AND
- have a "suitable" source address in the LinkProperites, meaning:
- IPv4 DNS server:
- only if LinkProperties has any IPv4 address
- IPv6 link-local DNS server:
- only if the server has a scopeId set
- assume for now that LinkProperties has a suitable
link-local address
- IPv6 non-link-local DNS server:
- only if LinkProperties has a global, preferred IPv6 address
Bug: 19470192
Bug: 20733156
Change-Id: Ibd95f3f7b33a4fb6c36d1cea4adb63c99068f657
- There are no callers of
NetworkInfo.setIsConnectedToProvisioningNetwork(), so remove all the
code that deals with mIsConnectedToProvisioningNetwork being true,
including the two ConnectiviyManager APIs.
- There are no callers of
ConnectivityManager.getMobileRedirectedProvisioningUrl(), so remove
the code that reads this URL.
- There are no callers of
ConnectivityManager.captivePortalCheckCompleted(), so remove this
API which is currently a no-op.
Change-Id: Ifa44c7553c7c45ebe261a2a124d9bf8d6f96c690
Additionally:
- make zero more obvious for debugging, rather than emitting
some inscrutable magic value.
Bug: 19537384
Change-Id: Iac9a3297a0dda1ba3d69fd01cf6de81f01fd837e
The API review comments in http://b/21343774 point out that the
suggested use case for onPreCheck (captive portal login apps) is
not a good use case as it requires that the app always be
running.
Also, unhide NET_CAPABILITY_VALIDATED, which is useful to apps
that want to detect captive portals and network connectivity
failures.
Bug: 21343774
Change-Id: Iad7c839bcc136b0fa9581dccc5fd97a28efed4ab
We used to only remove requests that we'd acted on but that's
just wrong.
Also adds test case which exposed the problem but passes with the fix.
bug:20731384
Change-Id: I581a005560cc71167b857abf2452769399a9e1b7
Overlapping the NetIDs can cause the ConnectivityService instance under test
to inadvertently use real networks, for example when NetworkMonitor attempts
to validate a network. This fixes test hangs when run on devices with
active internet connections.
Change-Id: I5e1898953f0117b9f75beccac4a52ae2db173567
Previously, we displayed a dialog on top of whatever the user was
doing. Instead, display a notification that can take the user to
the dialog.
Because the notification is less intrusive, also enable it even
if the network without Internet access is already the system
default network. Previously we did not do this because in that
case the user might not have other useful options, and thus a
dialog would have been too intrusive.
Bug: 20081183
Bug: 20538448
Change-Id: I677be238d675c13a13dc0bae2dbb37cbe4f52cb6
These are more consistent and have placeholders for the description of
whatever VPN apps are actually active.
Bug: 20516964
Bug: 17474682
Change-Id: I37ff287b795f10bbbb192540f09f8100bb27b1a0
Code that uses android.system.Os to create sockets as FileDescriptors
should be able to bind them to networks. Note that FileDescriptors
could already be marked as "protected from VPNs" via
NetworkUtils#protectFromVpn(), but heretofore were not easily bound
to any particular network.
Bug: 21449922
Change-Id: I4bb86db5d95d5a55bb2d7e245848d11eaa351e65
- Print NetworkFactories on one line.
- Only print LegacyTypeTracker networks if they are connected,
and record supported network types on a separate summary line.
- Print all tethering upstreams on one line.
- Summarize the state of the transition wakelock on one line.
- Don't print Inet condition reports if there are none.
(Currently there can never be any.)
Bug: 21449922
Change-Id: Ib4b29a7fd882e6c105839a255fffecf4f346cf7e
