This follows other TYPE_* constants like TYPE_WIFI_P2P that are
@SystemApi or public.
TYPE_PROXY has a use-case for the system to set network policies based
on proxy network templates. Although network types are deprecated, that
use-case needs to be supported and significant amounts of network
management would need to be rewritten to stop using network types.
The constant needs to be API as ConnectivityManager is planned to move
out of framework.jar, so only its formal API will be available to the
system server.
Bug: 174436414
Test: m
Change-Id: I266ed6bc59f5eb72302afe14472c93933733c8f8
Instead of sharing the constant from LinkProperties, use the already
defined constant in the NetworkConstants class.
This allows Ikev2VpnProfile to allow depending on non-public
LinkProperties APIs, as LinkProperties is planned to move to
framework-connectivity.
Bug: 174436414
Test: m
Change-Id: I594bb7e81bc7681799c16eff621a5ffd1b29624c
On top of being a cleanup this is useful for the S Network
Selection project that will need to enrich the Network
Agent API, and as such should not have to support legacy
agents.
Test: FrameworksNetTests NetworkStackTests
Bug: 167544279
Change-Id: Id3e5f6e19829c64074cd6a52c5f950cee56b860b
Connectivity service module uses Slog which is @hide so
migrate to Log, which is public, to remove hidden API usage.
Bug: 172050541
Test: FrameworksNetTests
check log is moved from system buffer to main buffer.
Change-Id: I0dcc0e169b892cc872ed4510f699642cb81b633a
ConnectivityService may not be available in a NetworkProvider
constructor, if it is created (but still unused) before
ConnectivityService starts.
As ConnectivityManager is only necessary in
declareNetworkRequestUnfulfillable, which should not be called often,
just query ConnectivityManager at that point.
This is necessary for VcnManagementService, which is started before
ConnectivityService and creates its NetworkProvider in its constructor.
Fortunately VcnManagementService does not call
declareNetworkRequestUnfulfillable at this point.
ConnectivityManager may be migrated to classic service getters that
cache "null" when the service was not available the first time it is
queried, so no system service must query it before it starts.
Bug: 171540887
Test: atest FrameworksNetTests:NetworkProviderTest
Change-Id: I8dadcd0e1360a9464192f330493e13aa69dd9fe2
The class-level @IgnoreUpTo annotation only applies with that runner.
Change-Id: I065618f2345c1d91de2fa1f2f558e5ed5b066f3e
Fixes: 174268969
Bug: 171505922
Test: atest FrameworksNetTests:android.net.OemNetworkPreferencesTest
Instead, make Vpn#onUserAdded and Vpn#onUserRemoved notify CS
of UID range changes through the VPN's NetworkAgent.
After this change, ConnectivityService no longer touches the
VPN's NetworkCapabilities directly, which is a much cleaner
design.
Bug: 173331190
Test: passes existing tests in ConnectivityServiceTest
Change-Id: If2201f392cdb5f00c89a97683ad4ce6bda7b89e5
This is only used for NetworkStatsService and only called on the
handler thread, so it can be replaced by a simple scan over
mNetworkAgentInfos without having to take any locks.
Bug: 173331190
Test: passes existing tests in ConnectivityServiceTest
Change-Id: I194e0cc55603a0f59f7138f38329f505b55da132
Much of registerNetworkAgent calls internal ConnectivityService
methods which generally assume that they are not processing an
IPC and are running under the system's calling identity.
However, only the call to makeNetworkMonitor is run with caller
identity cleared. Expand the scope of clearing the caller
identity over the creation of the nai.
Bug: 173331190
Test: passes existing tests in ConnectivityServiceTest
Change-Id: Icad28601a612fb5e1ed0451ec9e2066f4e766d0e
This CL allows an app that has the MANAGE_TEST_NETWORKS
permission to create test VPN networks.
The code enforces that such networks can never apply to any UIDs
and thus will never carry any traffic.
Bug: 173331190
Test: passes existing tests, moved tests pass
Change-Id: I5befea0e3b4b6dce4ca0c6a04471a055186b644c
Add support to ConnectivityService to track underlying networks
directly instead of through the Vpn class.
1. Communicate all information necessary to propagate underlying
network capabilities to ConnectivityService via NetworkAgent.
This includes:
a. Underlying networks:
- Add SystemApi for NetworkAgent to declare its underlying
networks to ConnectivityService, and use it in Vpn.
- Add a new declaredUnderlyingNetworks member to
NetworkAgentInfo and store the underlying networks in it.
Move propagation of underlying network capabilities to
mixInCapabilities, which is a natural place for it.
b. "Always metered" bit:
- Communicate this to ConnectivityService via the existing
NOT_METERED capability. Store it in a new declaredMetered
boolean in NetworkAgentInfo to separate it cleanly from
the NOT_METERED bit in the capabilities, which depends on
whether the underlying networks are metered or not. In
order to ensure that this is only ever changed when a NC
update is received from a NetworkAgent, define a new
processCapabilitiesFromAgent similar to the existing
processLinkPropertiesFromAgent.
2. Ensure that propagating underlying network capabilities does
not read the VPN's NetworkCapabilities. In order to do this,
ensure that all relevant information on underlying networks
and metering is sent to ConnectivityService at NetworkAgent
registration time. CS still calls Vpn#updateCapabilities when
a user is added/removed, but that is deleted in a future CL.
3. Slightly generalize propagating underlying network
capabilities because there may be other network types that
also have underlying networks that aren't VPNs (e.g., VCN).
- Introduce a new supportsUnderlyingNetworks() boolean method
in NetworkAgentInfo.
- Rename updateAllVpnsCapabilities to
propagateUnderlyingNetworkCapabilities.
This commit does not move the actual logic of calculating the
underlying capabilities out of Vpn.java. That can be done in a
subsequent change once CS stops calling getUnderlyingNetworks().
This commit also does not modify any of the other code in CS that
directly accesses VPNs' underlying networks.
Bug: 173331190
Test: passes existing tests in ConnectivityServiceTest
Test: CTS test in r.android.com/1511114
Test: atest CtsNetTestCases:Ikev2VpnTest HostsideVpnTests
Change-Id: I5f76cb1aa4866efed3d5c4590e931fdb0e994f8d
Currently, checkConnectivityDiagnosticsPermissions takes the VPN
lock to examine the VPN's underlying networks. Use the underlying
network data that is available in ConnectivityService instead.
Bug: 173331190
Test: passes existing tests in ConnectivityServiceTest
Change-Id: Ia1c366c5e9974d4d2c4b38030e66c007d62020ff
* changes:
Test passing an underlying network array with null network in it.
Make testVpnNetworkActive more deterministic.
Add a test for restricted profile added/removed with VPN up.
This test is a bit brittle because it sets the underlying
networks while the VPN is undergoing validation by
NetworkMonitor. The test does attempt to disable validation,
but that's not actually possible - the only thing that's possible
is to tell NetworkMonitor to validate immediately without sending
any probes. So the underlying network change races with the
validation. I'm not sure why the test isn't flaky. It might be
because both the network change and the validation result in a
capabilities change, and the test expects "a capabilities change"
without expressing what change that should be.
Make this a bit more predictable by ensuring that the network
validates before the underlying networks are set.
This is useful because an upcoming CL will change the way
underlying network capabilities are propagated. With this test
CL, both the old and the new code pass.
Bug: 173331190
Test: test-only change
Change-Id: I319858228e8d097c0b60a107029f296385f91269
Adding @IgnoreUpTo to OemNetworkPreferencesTest so that it can run as
part of MTS.
Bug: 174268969
Bug: 171505922
Test: atest FrameworksNetTests:android.net.OemNetworkPreferencesTest
Change-Id: If7fb039c2cdb061f803c8a59e826e485e1f1c761
The method - satisfiedBy() has changed to canBeSatisfiedBy()
starting from Android R, so the method - canBeSatisfiedBy()
cannot be found when running this test on Android Q.
Ignore verifying canBeSatisfiedBy() on Android Q to fix this
problem.
Bug: 173911834
Test: Run MatchAllNetworkSpecifierTest on Android Q, R, S.
Change-Id: Ibe317b56f82d3ea100b1d78c3907dce4f2fd964d
* changes:
Update toString() to use the correct request
Update requestsSortedById() to sort by collection
Allow a way to track the active request in an NRI
Update ConnectivityService.NetworkReassignment#toString to use either
the current satisfier's request otherwise highest priority request when
executing toString(). This is part of the mulilayered request changes.
Bug: 173336774
Bug: 171991028
Test: atest FrameworksNetTests
Change-Id: Ibed6cdd4522133164b2b919f62ecc9411943f026
Update requestsSortedById() to sort NetworkRequestInfo by their
nested collection of NetworkRequest objects vs a single request.
Before the NetworkRequestInfo with the request with the lowest
requestId would be sorted to the top. Now the NetworkRequestInfo
which contains the request with the lowest requestId will be
sorted to the top.
Bug: 173292541
Bug: 171991028
Test: atest FrameworksNetTests
Change-Id: I51e3c00d59443e37ddbf168c423d13df8d14fa64
As we are now allowing for multi-layered requests in NetworkRequestInfo
(NRI), we need a way to track which of those requests ended up being
satisfied. This also includes updates to NetworkRequestInfo itself to
support multilayared requests.
Bug: 173146509
Bug: 171991028
Test: atest FrameworksNetTests
atest FrameworksNetIntegrationTests
atest CtsNetTestCasesLatestSdk
Change-Id: I7bb5a564769c90928871fe28de05195c9cfae6b5
Change-Id: Ibf37f94b53eb2e833821553e00d76fe38bfea266
* changes:
Increase test coverage for VPN info sent to NetworkStatsService.
Simplify MockVpn.
Test a VPN with an underlying network that does not yet exist.
Minor fixes to NetworkCapabilities#toString.
MIN_MTU_V6 is increasingly used, and the LinkProperties version is used
as a source of truth for the constant.
Bug: 163602123
Test: atest FrameworksNetTests
Change-Id: I67134cd4fb7e2cf59c36947b62f681ac9b94ea4a
This comment is not true anymore since NetworkMonitor is not only
verifying the default network but also verifying VPN when private
DNS is enabled.
Test: Build pass.
Change-Id: Ib975aa28c84b9974a73d1baca9d5185c01b71217
