It was calling into dead ConnectivityService code rather than using
the new ConnectivityManager shim code.
bug:15221541
Change-Id: I1e3eea8a658a162ce36673ed1cf7b1e7e4372c42
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
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
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
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
Enforce that callers of ConnectivityManager.releaseNetworkRequest() are the
creators of the NetworkRequest being released by matching UIDs.
Change-Id: I439468c054bacc035e2db2c4967b24d183e78e9c
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
rename isNetworkActive -> isDefaultNetworkActive
rename registerNetworkActiveListener -> registerDefaultNetworkActiveListener
make listenForNetwork/requestNetwork take a NetworkRequest
rename NetworkCallbackListener -> NetworkCallback
rename listenForNetwork -> registerNetworkCallback
rename releaseNetworkRequest -> unregisterNetworkCallback
remove NetworkRequest param from NetworkCallback functions
rename onNetworkCapabilitiesChagned to onCapabilitiesChanged
remove onReleased
change time units in onLosing from Sec -> ms
bug: 15142362
Change-Id: Ibc96e3f461706efe1eafa0d85605249cfd6e9fdd
Applying API council comments.
bug: 15142362
(cherry picked from commit Ie0bde68b72656a676d90c0343b9756fe9268d8d6)
Change-Id: Ie0bde68b72656a676d90c0343b9756fe9268d8d6
This change uses IpPrefix only in the public API and continues
to use LinkAddress for everything else. It does not change the
callers to use the new APIs, with the exception of changing
all current uses of getDestination to getDestinationLinkAddress
to make room for the new getDestination method that returns an
IpPrefix.
Based on Sreeram's earlier change:
https://googleplex-android-review.git.corp.google.com/#/c/477874/
but a bit simplified and with a bit more documentation.
Bug: 15142362
Bug: 13885501
Change-Id: Ib4cd96b22cbff4ea31bb26a7853989f50da8de4e
(cherry picked from commit 7d3b4b9a3d4de9673119632da0ebd583e50126f7)
1. Rename getNetworkPrefixLength to getPrefixLength. Update all
callers in frameworks/base and add a shim method and a TODO
for the rest.
2. @hide isSameAddressAs. It doesn't add much, and it's just
one-liner that callers can implement if they want.
3. Fix the alignment of the initial paragraph (<ul> should have
been </ul>).
4. Remove the documentation that talks about creating
LinkAddresses, since there's no public API for creating them.
With these changes I think LinkAddress is fine as a public API.
Bug: 15142362
Change-Id: Iaf3b1db577745bb68a9e1dd7f96d666dd3f3ec7c
(cherry picked from commit 9ab53650cfcd91a2a151b44b3fd1381841f76269)
1. Rename getNetworkPrefixLength to getPrefixLength. Update all
callers in frameworks/base and add a shim method and a TODO
for the rest.
2. @hide isSameAddressAs. It doesn't add much, and it's just
one-liner that callers can implement if they want.
3. Fix the alignment of the initial paragraph (<ul> should have
been </ul>).
4. Remove the documentation that talks about creating
LinkAddresses, since there's no public API for creating them.
With these changes I think LinkAddress is fine as a public API.
Bug: 15142362
Change-Id: Iaf3b1db577745bb68a9e1dd7f96d666dd3f3ec7c
This change uses IpPrefix only in the public API and continues
to use LinkAddress for everything else. It does not change the
callers to use the new APIs, with the exception of changing
all current uses of getDestination to getDestinationLinkAddress
to make room for the new getDestination method that returns an
IpPrefix.
Based on Sreeram's earlier change:
https://googleplex-android-review.git.corp.google.com/#/c/477874/
but a bit simplified and with a bit more documentation.
Bug: 15142362
Bug: 13885501
Change-Id: Ib4cd96b22cbff4ea31bb26a7853989f50da8de4e
The change is specific to AT&T as they want no signaling from device during provisioning.
I've tested following cases:
- expired AT&T SIM to make sure provisioning flow works as expected.
- airplane mode on/off with both active and expired AT&T SIM.
- wifi <-> mobile transitions work okay.
- LTE with Verizon SIM (basic sanity).
bug: 13190133
Change-Id: I215963174ae6000ae71d1dda693f95413f3d6e81
This is a first order approx of what we want - should probably be good enough in most cases.
bug:15277751
Change-Id: I10e3b25f6ad5c7e022ba966ed514d4e6a999180d
(cherry picked from commit 94a5c61cb82401dd777d0a7ac43183d92d955323)
This is a first order approx of what we want - should probably be good enough in most cases.
bug:15277751
Change-Id: I10e3b25f6ad5c7e022ba966ed514d4e6a999180d
Two fixes. First make sure we mark the request as handled by the network handling it.
Second, convert ensureRouteToHostForAddress to use the new legacyNetworkForType.
bug:14993207
Change-Id: I230968938ca0ed91f834b36a2af60caff2eab682
Make the connectivity changed broadcasts send correct NetworkInfos.
Also update the results of getNetwork.
bug:15290306
bug:15191336
bug:14993207
Change-Id: Ie99ad25f3ebb90d18348e7013761b139e7481866
(cherry picked from commit 16fe1c18289de200d2249e51db8c0986619f487b)
