We continue to compile external/apache-http into ext.jar. This contains
a few changes apart fom the classes moving around :
- Makefile changes to build docs and api-stubs for now. A future change
will revert these changes and remove these classes from stubs and
docs.
- Hardcode event IDs in legacyerrorstrings to avoid a dependency between
the frameworks and apache. These strings are on their way out and will
never change anyway.
- Remove imports due to {@link} tags and use {@code} instead.
- Remove an accidental(?) dependency on apache commons code that's a
part of apache-http.
bug: 18027885
Change-Id: I51cd038d846ec7d02c283a4541b10a6a9cf62ecf
StaticIpConfiguration objects are parceled at least as part of the
IpConfiguration objects that are passed to IEthernetManager when an
application sets static IP configuration on Ethernet.
Change-Id: I49991e2f591cc6cf01b503c18eb343b5929efe29
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.
(cherry picked from commit c53113b37f33c7ed19660c8ec5bfd578e8bb5409)
bug:18252947
Change-Id: I6235fcd6b875aee516efbb5f880db1a99380355b
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
(cherry picked from commit 2dfb79a54adeb4bcf1f62332a9db467fce302ced)
Change-Id: I80088f291466dbd5a47f360dcc1620acee5cf57e
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
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
ICU, zlib & openssl export them using LOCAL_EXPORT_C_INCLUDE_DIRS.
The dependency on libc/dns/include was bogus and can be removed
trivially.
bug: 18581021
Change-Id: I4b8047ff0df1050ab48b61c0c886888b3f2f0c18
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
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 b5ae87a8d0, reversing
changes made to 32b61ab28f54e5b00f472b2166f9b1100375e4ff.
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
