ConnectivityService has been rewritten for L and is in a stabilizing period.
We need the logging to track down bugs people report.
Restoring to Pre-L conditions.
If there's excess logging please report it - it probably indicates a bug.
Change-Id: I7baf891e3bf12e1545afeb92b8d5af0b01e12a7b
ConnectivityManager.requestNetwork pass TYPE_NONE to
sendRequestForNetwork which prevents it from being used with legacy API
requestRouteToHostAddress. This CL infers the legacy network type
automatically from the network capabilities.
b/16324360
Change-Id: I591d38f875f42f56e8cfc157db2069c9eee0ee26
When a network comes online, is a candidate for being the default network
(i.e. satisfies default NetworkRequest), and the device has no default
network, then make the new network the default network for the purposes
of routing network traffic. This does not affect NetworkRequests or
NetworkCallbacks. This ignores but does not affect network validation.
Benefits:
1. Offers a fail-safe in case network validation returns a false negative.
For example: It would be nice if every Android device didn't fail when
clients3.google.com/generate_204 went down.
2. Offers a method to debug connectivity issues.
For example: If WiFi is failing, disabling Cellular would rule out
interference from WiFi network validation.
3. Reduces delay between no connectivity and any connectivity.
4. Offers a fail-safe in cases of unreliable networks.
For example: You need rescuing from a remote location with a weak signal
offering 90% packet loss. You just want your distress call to go out
but are infuriated to find network validation blocks connectivity.
Change-Id: I78621a1fe8ed2a336591f65bf7b07a6cbcc7ba5e
Don't rely on the NetworkAgent still being connected when we go to
hide the notification. The notification is hidden when the
NetworkAgent is disconnected so that wasn't a safe assumption.
By using the NetID as the notification identifier we also fix the
issue of multiple notifications of the same network type inadvertently
hiding the incorrect notification with the same network type.
bug:16317917
Change-Id: I01fdc466a0f430af9fc378445586ec7b83b3ac83
* commit '39a9ec20d4cb149f1a8f8e4806aded3d67d6bd66':
Allow overlays to configure ConnectivityService's network sampling to not wake the device. This can increase clockwork device battery life. Bug:15455204
Allows transport specific network selectivity where multi-sim or sta+sta
is supported.
bug:1575597
Change-Id: I9c60fe7710e988c17d63236788b492a3ddd264a1
This eliminates the need for the ConnectivityService.VpnCallback class.
This requires shifting VPNs to the new "network" netd API.
VpnService.protect() is modified to no longer go through ConnectivityService.
NetworkCapabilities is extended to add a transport type for VPNs and a
capability requiring a non-VPN (so the default NetworkRequest isn't satisfied
by a VPN).
bug:15409918
Change-Id: Ic4498f1961582208add6f375ad16ce376ee9eb95
Add getTetheredDhcpRanges() interface and call it before calling
mNwService.startTethering to update dhcp ranges. This will allow
p2p apps to run well concurently with other tethering apps.
Manual import of AOSP change 81546 by jianzheng.zhou@freescale.com
Change-Id: Iebc62f95bdcedde80e2c1d3e9580d3f625c3b50b
Adds a new kind of alarm that represents an alarm clock and
a way to query the next scheduled alarm clock.
Deprecates Settings.System.NEXT_ALARM_FORMATTED.
Bug: 14589952
Change-Id: I297eeeff36d07adcda010afac183d0f5ee37dc99
Network validation prevents networks claiming to provide internet connectivity
from becoming the default network in cases where internet connectivity is not
found to actually exist.
If a captive portal is encountered the appropriate broadcasts and notifications
are surfaced to allow apps to handle signing in. If no app handles signing in,
my system app will handle it.
Bug:15409233
Bug:15409354
Change-Id: Ie240d7eac4bdbab8cc7578782bd72d8b26de7951
Indicates the user has indicated implicit trust of a network. This
generally means it's a sim-selected carrier, a plugged in ethernet,
a paired BT device or a wifi they've asked to connect to. Untrusted
networks are probably limited to unknown wifi AP.
Change-Id: I89490bdaa3c2d63d33f876c72d8b088dc155fa3d
This fixes a problem where a requested network can later suddenly disappear if
it was lingering when the request arrived and later the linger timeout expired.
bug:15927234
Change-Id: Ib3fae45820ce4421e3bc5b623937a16d5f1efa0f
Make it all internal to ConnectivityService - we know when a network
is lost, so grab a wakelock then.
Moves the call out of WifiStateMachine which was grabbing at bad times
like every dhcp renewal or corp-network roam. These would always
go the full 1 minute and chew up battery.
bug:15595155
Change-Id: I80157a818cc149072cc7706d78c1e79c6e679ab3
When making Network requests in ConnectivityManager, make sure we install the
callback prior to a response from ConnectivityService arriving causing us to
search for the callback and inadvertently not find it.
bug:15928097
Change-Id: Ie5feb9cc8f5effc19870f54dba07218b2e11d82a
Enforce that callers of ConnectivityManager.releaseNetworkRequest() are the
creators of the NetworkRequest being released by matching UIDs.
Change-Id: I439468c054bacc035e2db2c4967b24d183e78e9c
1. Make addDnsServer not add duplicate servers and return a
boolean value incating whether it changed anything. This is
consistent with what we do for LinkAddresses and routes.
2. Add a setDnsServers method that sets all the DNS servers to
the specified collection. This is consistent with what we do
for LinkAddress.
Bug: 9180552
Change-Id: I5baed09253261b66ea42ae2ea82398118e3ab0ac
In IPv4, a link is provisioned when DHCP succeeds. In IPv6, a
there is no such signal, because addresses and DNS servers can
be notified by the kernel at different times.
Add an isProvisioned method that returns true if we believe that
enough information has configured to use a network. For IPv6,
this requires an IP address, default route, and DNS server. For
IPv4, this requires only an IPv4 address, because we support
static configuration that doesn't have a default route or DNS
server.
To do this we use the existing hasIPv4Address method, rename the
all-but unused hasIPv6Address method to hasGlobalIPv6Address
(which is what we want anyway) and add new hasIPv[46]DefaultRoute
and hasIPv[46]DnsServer methods.
Bug: 9180552
Change-Id: Ib2f5ff8af920f7b6f1edf0e2afaaa0edce9bc72d
1. Realize that mDestination can never be null and update the
code accordingly.
2. Simplify isDefaultRoute.
3. Provide two new hidden utility methods, isIPv4Default() and
isIPv6Default(), that can be used by LinkProperties to
to determine if the system has connectivity.
4. Update tests.
Bug: 9180552
Change-Id: I85028d50556c888261d250925962bdedfe08e0c6
Add getTetheredDhcpRanges() interface and call it before calling
mNwService.startTethering() to update dhcp ranges. This will allow p2p app
to run well concurrently with other tethering app(e.g. usb tethering).
Change-Id: I5e8ffeb5d2d396f48b897cd9396f133e25ecca57
Signed-off-by: Jianzheng Zhou <jianzheng.zhou@freescale.com>
This will allow us to dynamically track routes being added and
removed, similar to what we do for IP addresses.
1. Support removing routes. Since this is a new function, we
don't need to jump through hoops to support callers passing
in routes that have no interface, we just fail to match them.
2. Make the addRoute method return a boolean value indicating
whether anything changed. This is consistent with what we do
for addresses and is used to decide whether to update the
rest of the system when an update comes in.
Bug: 9180552
Change-Id: I50648b5f81ec55c88501a7640e119cda2bb540f2
1. Allow IpPrefixes to be created from strings. In order to do
this, factor out the code from LinkAddress which already does
this to a small utility class in NetworkUtils.
2. Truncate prefixes on creation, fixing a TODO.
3. Add a toString method.
4. Write a unit test.
While I'm at it, make RouteInfoTest pass again, and convert it
to use IpPrefix instead of LinkAddress.
Change-Id: I5f68f8af8f4aedb25afaee00e05369f01e82a70b
