LinkProperties can represent way more complicated configurations
than what we can actually apply to interfaces. This makes it
error-prone to use it to represent static configuration, both
when trying to apply configuration coming from LinkProperties
and when trying to save configuration from current
LinkProperties.
Instead, move static configuration (IPv4 only, since we don't
support static IPv6 configuration) into a separate
StaticIpConfiguration class.
Bug: 16114392
Bug: 16893413
Change-Id: Ib33f35c004e30b6067bb20235ffa43c247d174df
Add logic to obtain the mtu from the network PCO parameter and set it to kernel
when the mobile data connection is established. When there is no PCO mtu configured
from the network, the mtu size defined in the corresponding APN will be used. In case
no mtu size is defined for an APN used for data connection, the MCC/MNC based MTU
defined in the framework overaly will be applied.
bug:17046179
Change-Id: I6465d4b8f2076aaa380ae3617fb3f24adbe136d4
This addresses a TODO and also makes it possible to create
routes to destinations that are not valid LinkAddresses, such as
multicast addresses.
Bug: 16875580
Change-Id: Id4c77b00dc3064bf27d78cdcbbe035e645748cfe
-Perform additional checks for the SCORE_NETWORKS permission when
broadcasting scoring requests to the active scorer and when accepting
score updates. In theory, these checks are unnecessary as we manually
check package manager when obtaining the list of valid scorers, but
they cannot hurt to add.
-Fix multi-user. Since the active scorer is a global setting, we
ensure that scoring can only be done by apps available to the primary
user / owner of the phone, and that the request scores broadcast is
sent to that user's profile. When the scorer is changed, we send that
to all user profiles as it's just informational, although it's
unlikely that apps outside the primary user's profile would need to
respond.
Bug: 14117916
Bug: 16399238
Change-Id: Iaf06bda244eec730b590a30a3f4ffab4965bde96
Some devices use clatd for catching raw IPv4 traffic when running on
a pure-IPv6 carrier network. In those situations, the per-UID
stats are accounted against the clat iface, so framework users need
to combine both the "base" and "stacked" iface usage together.
This also means that policy rules (like restricting background data
or battery saver) need to apply to the stacked ifaces.
Finally, we need to massage stats data slightly:
-- Currently xt_qtaguid double-counts the clatd traffic *leaving*
the device; both against the original UID on the clat iface, and
against UID 0 on the final egress interface.
-- All clatd traffic *arriving* at the device is missing the extra
IPv6 packet header overhead when accounted against the final UID.
Bug: 12249687, 15459248, 16296564
Change-Id: I0ee59d96831f52782de7a980e4cce9b061902fff
Anything that runs as a singleton may need to attribute traffic to
various client apps; in particular, backup transports need to do this.
Apropos of which, introduce a @SystemApi method specifically for that
purpose, setThreadStatsTagBackup().
Bug 16661321
Change-Id: Id5d22e28bdc68edb53f2a1fdba80b144fcbc61d2
If Socket.connect() times out, the socket cannot be used any
more - any attempt to do so fails with EBADF. Use a new
socket for each IP address.
Bug: 16664129
Change-Id: If3616df86f7c2da0eabd30dca5db65d0da85cb17
Starting with startUsingNetworkFeature and stop.
Figure it's easier to code review incremental changes.
Change-Id: I19aee65e740858c3a9a2a1a785663f6fee094334
Bypassable VPNs grab all traffic by default (just like secure VPNs), but:
+ They allow all apps to choose other networks using the multinetwork APIs.
If these other networks are insecure ("untrusted"), they will enforce that the
app holds the necessary permissions, such as CHANGE_NETWORK_STATE.
+ They support consistent routing. If an app has an existing connection over
some other network when the bypassable VPN comes up, it's not interrupted.
Bug: 15347374
Change-Id: Iaee9c6f6fa8103215738570d2b65d3fcf10343f3
It was calling into dead ConnectivityService code rather than using
the new ConnectivityManager shim code.
bug:15221541
Change-Id: I1e3eea8a658a162ce36673ed1cf7b1e7e4372c42
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
This CL adjusts android.net.PSKKeyManager as follows:
* Renamed to PskKeyManager to follow naming conventions.
* Changed from interface to abstract class with default
implementations for all methods.
Bug: 16403305
Bug: 15073623
Change-Id: Iefce26b394d4a753412315dad554b5342f3f0b44
Ideally, we'd only expose the methods that we intend unbundled apps to
call (e.g. not NetworkScoreManager#setActiveScorer, which should only
be called by Settings), but this isn't harmful in terms of permissions
as the APIs still check security appropriately.
Bug: 15833200
Change-Id: I2047515b41c8be0cf7cb51dd495fe72309c05f68
This CL adjusts the example code in android.net.PSKKeyManager Javadoc
to no longer explicitly enable TLS-PSK cipher suites. These are now
enabled automatically if SSLContext is initialized with a
PSKKeyManager.
Bug: 15073623
Change-Id: I7f7f713478171491347cdfb9651fd9a095dc60ee
A VPN declared bypassable allows apps to use the new multinetwork APIs to
send/receive traffic directly over the underlying network, whereas without it,
traffic from those apps would be forced to go via the VPN.
Apps still need the right permissions to access the underlying network. For
example, if the underlying network is "untrusted", only apps with
CHANGE_NETWORK_STATE (or such permission) can actually use it directly.
New API with stub implementation to be filled out later.
Bug: 15347374
Change-Id: I8794715e024e08380a43f7a090613c5897611c5b
The goal of blocking an address family by default is to prevent unintended
security holes. For example, a VPN that only deals with IPv4 doesn't know or
care about IPv6 at all, so it doesn't do anything for IPv6. An app shouldn't be
able to get around (bypass) the VPN by using IPv6.
Therefore, it is not necessary to block an address family in removeAddress().
The VPN was clearly aware of the address family (since it had configured such an
address before), so if it wants to block that family, it should add a default
route for that family and explicitly drop/block/reject those packets.
Bug: 15972465
Bug: 15409819
Change-Id: I845426fa90dc2358d3e11bc601db0b4bd5d3b7ac
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
If a VpnService only configures IPv4 addresses, routes and DNS servers, block
IPv6 by default, and vice versa. Also add an API to unblock a family without
needing to add an address, route or DNS server.
New API with stub implementation to be filled out later.
Bug: 15972465
Change-Id: I70d4d5c30ee71802610f6e16f100db6cbccef42c
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
