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
The function should be named "clone", not "Clone".
Also add @Override so that this error can be detected at
compile time.
Change-Id: I976723978a5e3eafbfbc599bac95b8646d18d5ca
When making Network requests in ConnectivityManager, make sure we install the
callback prior to a response from ConnectivityService arriving causing us to
search for the callback and inadvertently not find it.
bug:15928097
Change-Id: Ie5feb9cc8f5effc19870f54dba07218b2e11d82a
The network policy manager now monitors battery save mode and,
when in battery save, uses its facility to block access to metered
networks to block access to all networks. That is, it tells the
network management service that all networks have an (infinite)
quota, and puts various app uids to be restricted under quota
interfaces as appropriate.
This new network blocking needs a new facility to be able to white
list apps, such as GmsCore. To do this, I refactored the package
manager's permission configuration stuff into a separate SystemConfig
class that can be used by others, and it now has a new tag to
specify package names that should be white-listed for power save
mode. These are retrieved by the network policy manager and used
to build a whitelist of uids.
The new general config files can now go in system/etc/config,
though currently everything still remains in the permissions dir.
Still left to be done is changing the semantics of what uids are
allowed in this mode, to include all perceptable uids. (So that we
can still do things like background music playback.) This will be
done in a follow-on CL.
Change-Id: I9bb7029f61dae62e6236da5ca60765439f8d76d2
A candidate scorer may have an activity registered to listen for the
ACTION_CUSTOM_ENABLE intent action. If so, when the user attempts to
select this scorer as the active one, this custom activity will be
launched and will be responsible for requesting that the framework
activate the scorer. This is to enable more complex opt-in flows prior
to becoming the active scorer.
Scorers which do not specify this activity will default to using the
framework switcher (currently ActiveNetworkScorerDialog, though this
may change).
Note that all switches must still go through the framework switcher;
the opt-in activity simply allows scorers to first show another screen
and perform the framework switch on their own terms.
Bug: 15775314
Change-Id: I3847e5d3161a8fcc9622abc03218795697c32778
Allows scorer apps to set a custom name for the scoring functionality,
even if the app has other non-scoring responsibilities, in which case
the application's label would be too generic.
Bug: 15775300
Change-Id: I61a7d1966742d463508e6801b7845ced8392db84
1. Make addDnsServer not add duplicate servers and return a
boolean value incating whether it changed anything. This is
consistent with what we do for LinkAddresses and routes.
2. Add a setDnsServers method that sets all the DNS servers to
the specified collection. This is consistent with what we do
for LinkAddress.
Bug: 9180552
Change-Id: I5baed09253261b66ea42ae2ea82398118e3ab0ac
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
1. Realize that mDestination can never be null and update the
code accordingly.
2. Simplify isDefaultRoute.
3. Provide two new hidden utility methods, isIPv4Default() and
isIPv6Default(), that can be used by LinkProperties to
to determine if the system has connectivity.
4. Update tests.
Bug: 9180552
Change-Id: I85028d50556c888261d250925962bdedfe08e0c6
