Since the demise of the connectivity change delay,
CONNECTIVITY_ACTION_IMMEDIATE has been sent out back to back with
CONNECTIVITY_ACTION.
Interested parties should watch for CONNECTIVITY_ACTION.
Bug: 20013379
Change-Id: I072dddf95adb3bbd17fa1f7159d4ea848ade8f19
This API allows apps other than the system's CaptivePortalLogin
to handle signing in to captive portals.
bug:19416463
Change-Id: I27fce5856b635233e6ff66396d50ccabedd76cf5
Recommend ConnectivityManager.getAllNetworks() and various state
inspection functions as a way forward.
Bug:19608294
Change-Id: Ibd53629995897047fc532ffa56f079dfba10a7c7
This new API allows reporting networks that are perceived to provide Internet
connectivity and networks that are not. This allows the framework to avoid
needlessly reevaluating networks where the apps perception matches the
framework's perception. This was not possible with the prior API,
reportBadNetwork.
Bug: 16214361
Change-Id: Id4409bd7538854bd837231fb50e693c10a62b4f2
Rework NetID allocation in ConnectivityService so registerNetworkAgent() can
return the allocated NetID.
Bug: 19416463
Change-Id: I68e395552cf27422c80b4dfae5db5d56a0d68f5d
1. Remove ConnectivityService.findConnectionTypeForIface() as this can be done
just as easily with supported APIs now.
2. Avoid making copies of Network objects as this precludes reuse of Network
internals (e.g. socket factory, connection pool).
Change-Id: I52f92e35d769d8350471f485e408169608630082
1. Unhide ConnectivityManager.getDefaultProxy() and update it to
take into account process-bound-Networks.
2. Deprecate EXTRA_PROXY_INFO and instead encourage querying via
getDefaultProxy().
Bug: 17905627
Bug: 17420465
Bug: 18144582
Change-Id: I45358ee82fe705d048022c8238b2452f52c37b88
These functions risk hitting an unchecked Exception due to ConnectivityManager
not being instantiated yet. Also, change Network.openConnection() to throw a
checked Exception rather than an unchecked Exception when ConnectivityManager
is not yet instantiated.
bug:19416463
Change-Id: Ie1e2b3238aec0343d267c76b64927073f2f05f85
This state leaves dhcpcd running and polls for results, with
exponential backoff to once every 32 seconds.
Bug: 19422416
Change-Id: I87f481969629ba104491f25ea36de1efc4ad105a
* changes:
DHCP: Minor cleanups to the packet code.
DHCP: Move the packet code to frameworks/base/services.
DHCP: Add a native method for making a DHCP socket.
DHCP: Add a superclass for DhcpStateMachine.
There's no need for it to be in frameworks/base/core, since it
will only be used by services.
Bug: 19704592
Change-Id: I2f5277eca848b7000ca46db575e8602eacb5c8bd
This can be used to switch between different DHCP client
implementations. The caller can declare objects of type
BaseDhcpStateMachine, and call its methods, without needing to
care what implementation is in use.
Bug: 19704592
Change-Id: Icefad9b0d0f83b349681388b1fa16b5e2e37c042
1. Add a validating method to convert a netmask to a prefix length.
2. Add a function to get the implicit netmask of an IPv4 address.
3. Add a unit test.
Bug: 19704592
Change-Id: Icb9f58d3903ea01df9e3720383c9bd5db6dd8f26
Separate out starting DHCP (DISCOVER) and RENEW operations from fetching
the results. Add NetworkUtils.getDhcpResults(), to enable quick checks
of any available DhcpResults without extraneous interaction with the
DHCP daemon.
Bug: 19422416
Change-Id: I58808e529dda8429737e749f5caef56d923c0809
Introduce new RAT as IWLAN.
- Allow registration polling in airplane mode.
- Allow non-default PDP activation for iwlan RAT.
Implementation of iwlan and wwan coexistence.
- A new callback event for unsol oem hook response to indicate
if cellular and iwlan RAT co-exists.
- If co-existence is possible then allow default PDP activation
along with other PDPs.
Change-Id: Icc6f8111ec3c86ec06e8facd5a5b60b4d5e08e78
In K and earlier, we would connect to a network where the gateway
was not covered by the subnet mask of the IP address. This is an
invalid configuration, but it used to work, and other OSes appear
to accept it too, so support it.
Bug: 19067207
Change-Id: I822e1d754b336691b675438eefa959a3d75fd07b
This simplifies the code, and also makes it possible for
users to point multicast routes at the VPN. The LinkAddress
objects we were previously using to construct the RouteInfo do
not accept these, but IpPrefix objects do.
Bug: 18485968
Change-Id: Ie914a2eb359b78161810ee473df725059f944f4e
When requests made by ConnectivityManager.startUsingNetworkFeature() are
expired or are canceled via ConnectivityManager.stopUsingNetworkFeature(),
we must remember to clear the binding of DNS requests from the calling
process to the Network satisfying the request.
bug:18778725
Change-Id: I800c808ac6486000241b5d263aa79a1192a9fe9e
Needed some additional logging to track down this bug
so add toString to capture the state.
bug:18569575
Change-Id: I4047b8f8797bac09bcff31e99d9cb117abb04df4
1. Send PROXY_CHANGE_ACTION broadcast when any network's proxy changes,
not just the default network.
2. When a process is bound to a particular Network, update the proxy
system properties to those for the bound Network, and keep them
updated when PROXY_CHANGE_ACTION broadcasts are received.
3. Make Network.openConnection() use the proxy for the Network.
bug:17905627
bug:17420465
bug:18144582
(cherry-pick of https://android-review.googlesource.com/#/c/115170)
Change-Id: Ia2819985e6108a8c121e74c683a5646becfd0a97
Connectivity broadcasts recently changed and are no longer sent for
certain types of network changes. For example, when stacked network
interfaces change for a mobile network. To ensure that we pick up
all these details, directly wire the two services together.
Also remove some unused code for split network types.
Bug: 18666753
Change-Id: I0467bd5b330c0e0cb51af2306d821b41ad16337a
There are some cases where multiple subscriber identities (IMSI)
should be treated as "merged together" from a data usage
perspective. This is done by extending the template used for
matching purposes to support multiple subscribers.
Then, when we query historical usage or set network policies, we
normalize the matching template to merge to any other identities
that should be included. When normalizing, the "lowest" identity
is always used for equality and storage purposes, which allows
identities to come and go over time.
This change also fixes data usage recording for multi-SIM devices
by passing along the concrete subscriber identity for each network
interface. Also correctly create default policies for multi-SIM
devices. This change also drops setPolicyDataEnable() until it can
be wired up to the right underlying NetworkAgent. (This means we
still bring up the network, and then rely on iptables rules to block
traffic when over the limit, instead of proactively disabling the
connection.)
Bug: 18012787
Change-Id: If6acf32009fdfea2b836f5aff8e2f3e5e0248b4a
Since optimistic addresses are useable upon kernel notification
there is no need for this extra connectivity delay.
---
This functionality was originally submitted in ag/572619. Owing
to issues with bind()ing to optimistic addresses (see b/18609055)
this was reverted in ag/598673.
This reverts the revert. :-)
Bug: 17769720
Change-Id: Ibee490b2af72050693b6bd748193f51e312ca527
This is the revert of ag/572619.
This reverts commit 9261d9d645, reversing
changes made to 32b61ab28f.
Bug: 18609055
Bug: 17769720
Change-Id: I122eba200f2071d4e5777ec34c1d04fb567345a8
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
