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 c53113b37f)
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 2dfb79a54a)
Change-Id: I80088f291466dbd5a47f360dcc1620acee5cf57e
These strings only ever end up in logcat (at best), so there's no
point having them translated. Also, rename the ErrorStrings class
and move it android.webkit where the last remaining caller lives.
(congrats webview people, this is now your mess to maintain.)
Change-Id: I04dae37c34191b26a69282970318c1b782af1edf
Move the code to the only point of use. Preparatory work for
decoupling apache-http from the frameworks.
Change-Id: Ieee54bb725cbac19d0c7513867635df6fbcf2b49
Most of this logic is simply removed from ConnectivityService.
The captive portal detection is now done by the NetworkMonitor.
The notification logic is still left in ConnectivityService as
it's used by both the NetworkMonitor and telephony's mobile
provisioning logic.
bug:17324098
Change-Id: Ibd1c42b1a75795f90a6483d3d0a5a14f88b193d8
Now that we support unreachable routes, use those to block
address families on VPNs. This is a much more elegant solution.
Also update LinkProperties when IP addresses are added and
removed, fixing a TODO.
Bug: 17462989
Change-Id: Ib749d84710dca70d672350b9f129bb91419ec77e
The BT and Wifi mechanisms for enabling Tethering did their own
permission checks. This set of changes unifies the check into
a ConnectivityManager function so they can be kept in sync.
bug:17435527
Change-Id: I8c157a5acf56ffbddd349cb6a45160ae7be8541b
Internal logic relies on Arrays.copyOf(), so always give ourselves
valid arrays, using shared empty objects to save overhead.
Bug: 17502649
Change-Id: I5dbb00545bdfe45bbd48144ab505ea08cc92cbcd
Currently just valid/invalid based on NetworkMonitor findings.
Changed NetworkMonitor to start out in default state since starting in Offline causes
a spurious invalid report at creation time.
Added some logging.
bug:17395269
Change-Id: I9ae650b561834d8f8979033744d97df852e76df9
The major change is that consent is now "sticky" and lasts until the
user explicitly disables the VPN connection.
Bug: 17474362
Change-Id: Id4e7807e635bbfc7645741135209d46763e280f9
These APIs were added because we thought we needed them to provide
seamless transition from one server backend to another using local IP
addresses to distinguish between the backends. I.e., connections whose
local IP address was old would be routed to the old backend; connections
whose local IP address was new would be routed to the new backend.
It turns out that's not needed. VpnService already supports seamless
re-establishment, so VPNs just need to call establish() again with a
different IP address. I've verified with a custom VPN app that this
works, and can distinguish traffic based on the old and new addresses.
Nobody is using these APIs at the moment, so we could even consider
removing them altogether, but I prefer just hiding them, just in case.
Bug: 15409819
Change-Id: I30949926a0f859c9d839981ccbc5d8e1e535a3a5
HttpHandler and HttpsHandler classes have a lot of bug fixes baked into
them that the Network.openConnection() API should be using, for example
disabling SPDY support.
bug:17420465
Change-Id: I9f1472753a542d1dd6bffde3a60c37a9145098aa
Future HTTP requests could use an old socket that's bound to a different Network
causing unexpected results. DNS results could also not be appropriate.
bug:17283566
bug:17432215
Change-Id: I88b40b723c7b442000cafe8ce8b9d989d8995991
Network Factories are allowed to go below, but networks need to be
constrained. Allowing the network to go below 0 meant that -1 could
sometimes leak through and foul the logic.
The core of 17361330 will be fixed when we stop sending scores for
listens to NetworkFactories, but it exposed this issue too. Summary:
1 - add a network listener. This isn't a request so it's not sent
to networks.
2 - alter your score (ethernet sets score to -1 when the link goes
down) (16:07:39.782)
3 - a bug in ConnectivityService causes score changes to get sent for
all network requests and network listeners causing NetworkFactories
to no see 2 entities. This bug will be fixed by a pending change
(https://googleplex-android-review.googlesource.com/#/c/540840/).
This causes the ethernet NetworkFactory to see two entities, both
served by networks of score -1. (16:07:39.989)
4 - disconnect Ethernet - this only sends 0 scores for known
requests, not network listeners. Had it been sent for both entities
they both would have evaluated that the networkfactory score (-1)
was lower than the request score (0) and both released their
refcount. (16:08:03.147)
5 - this means the listener is tracked by the EthernetNetworkFactory
with a score of -1 while the factory itself has a score of -1 so the
network release isn't called.
bug:17361330
Change-Id: Ife34ca0f9c233dd3c3df80f6fea580af43afcdeb
