This requires mocking lots of new things that weren't mocked
before but is otherwise fairly straightforward.
A few changes to MockVpn are needed as well:
1. Set the VPN's NetworkInfo to CONNECTED, so methods such as
isBlockingUid will work. While I'm at it, set the interface on
the LinkProperties as well to make things a bit more
realistic.
2. Constructs the VpnConfig when registering the agent, not when
the MockVpn is created. This is needed because starting and
stopping lockdown VPN calls prepare, which nulls out mConfig.
But constructing the VpnConfig when registering the agent is
more realistic anyway. The production code does that in
establish, but we can't do that in ConnectivityServiceTest
because some of the test cases don't call establish and call
registerAgent directly.
Bug: 173331190
Test: atest FrameworksNetTests
Change-Id: I827543751dbf5e626a24ec02cd6f50b423f5f761
CAPTIVE_PORTAL is a CS-managed capability, and causes CS to log a wtf.
When this test is run on an eng build, this sends SIGSEGV to the test,
which is pretty difficult to debug.
Test: FrameworksNetTests NetworkStackTests
Change-Id: I72fc46a6daa4e886425b4dc967318cca9f1a5302
Currently, ConnectivityService assumes that only VPNs can have
underlying networks. Make the code decide this based only on the
return value of NetworkAgentInfo#supportsUnderlyingNetworks.
This allows non-VPN network types to support underlying networks
in the future.
This requires storing the original agent's capabilities in
NetworkAgentInfo so that applyUnderlyingCapabilities can mix in
the underlying network capabilities without overwriting the
capabilities of the network itself. Currently, the only
information that applyUnderlyingCapabilities takes from the
original agent's capabilities are the metered bit (stored in
NetworkAgentInfo#declaredMetered) and the transports (assumed to
be exactly {TRANSPORT_VPN}. Store the full capabilities instead.
This is more state than needed but it ensures that we do not need
to make any changes if in the future we want to propagate new
types of information from the underlying networks.
This should have no impact on current use cases (i.e., VPNs).
There is a change in ordering: in disconnectAndDestroyNetwork,
the new code propagates underlying network capabilities before
removing the network from LegacyTypeTracker, instead of after.
This is done to simplify the new code. When the new code
propagates underlying network capabilities in response to a
change for a particular network (e.g., connect, disconnect,
capabilities change), it only considers networks that have the
changed network as underlying. Because determining the
underlying networks requires knowing the default network,
the new code runs before the default network is changed and
LegacyTypeTracker is updated.
This shouldn't have app implications because the connectivity
broadcasts sent by LegacyTypeTracker and the callbacks cannot be
ordered, since they run on separate threads with unpredictable
delays. The capability change callbacks resulting from
propagation of underlying network capabilities were already
sent before the rematch, so the callbacks themselves are not
reordered in any way.
Bug: 173331190
Test: atest FrameworksNetTests \
CtsNetTestCases:NetworkAgentTest \
CtsNetTestCases:Ikev2VpnTest \
CtsNetTestCases:VpnServiceTest \
CtsNetTestCases:android.net.cts.ConnectivityDiagnosticsManagerTest \
HostsideVpnTests com.android.server.connectivity.VpnTest
Change-Id: Ic5353a928a3a3541dcf953c35f47277c5e295db8
* changes:
Remove support for legacy network agents
Remove deprecated constructors for NetworkAgent
Migrate NetworkAgentWrapper to the new NA API
Cleanup TestNetworkService
ConnectivityService is going to become a mainline module which
cannot access hidden APIs. Thus, replace the VPN uid range
controlling APIs from NMS to INetd directly.
Bug: 170598012
Test: atest FrameworksNetTests
Test: atest HostsideVpnTests
Test: manually test to connect to VPN and check the uid range
Change-Id: Ie6656ef36f54c2f14d5a2899e763a29b70a30f5d
From S, it's required to specify explicitly either FLAG_MUTABLE
or FLAG_IMMUTABLE when creating a PendingIntent. Thus, add a
mutability flag to the PendingIntent in ConnectivityServiceTest
that doesn't specify it before.
Bug: 173157160
Test: atest FrameworksNetTests
Change-Id: I755c53b90d709dfbac576dc076722476c3edee35
* changes:
Add a convenience method to update a network's capabilities.
Disallow NetworkAgents from changing the owner UID.
Observe mOwnerUID in NetworkCapabilities#equals.
The current behaviour with regards to changing the owner UID is
bizarre and arguably incorrect. A NetworkAgent can change the
owner to whatever other app it wants, regardless of signatures,
at any time. This includes, for example, transferring ownership
to another UID and then recovering it.
Fortunately no existing NetworkAgent appears to do this:
- ClientModeImpl sets it to the UID of the app that created the
configuration. It doesn't look like it can change while the
network is connected.
- Vpn sets it to the UID of the VPN owner. That also can't change.
- Telephony does not appear to set it at all, it only sets the
administrator UIDs (and updates them whenever it gets
EVENT_CARRIER_PRIVILEGED_UIDS_CHANGED).
Disallow this now before code is written that depends on it.
Bug: 175188445
Test: modified tests in ConnectivityServiceTest
Change-Id: I638e29fda2481ec3bf4fff562ea66a73322881df
Currently, NetworkCapabilities's equals and hashCode methods
ignore mOwnerUID. This is confusing because it is inconsistent
with pretty much every other member of this class.
Bug: 175188445
Test: atest CtsNetTestCases:NetworkAgentTest \
CtsNetTestCases:Ikev2VpnTest \
CtsNetTestCases:VpnServiceTest HostsideVpnTests \
CtsNetTestCases:android.net.cts.ConnectivityDiagnosticsManagerTest \
ConnectivityServiceTest com.android.server.connectivity.VpnTest
Change-Id: I2348b7a35f32a931687f2d3c2fa57620a12fe06f
The current behaviour is at least bizarre and arguably incorrect.
Add a test to document the current behaviour so we can check that
any changes we make to this behaviour are correct.
Test: test-only change
Change-Id: I345bd320eced96316d92e520f576ae06b8020d9f
This reduces verbose assertions and makes the test more compact.
I'm not sure whether it's actually more valuable, since the
current code, while more verbose, is probably more
straightforward to understand.
Also add a test for passing in a null underlying network (i.e.,
follow default network). This requires a minor refactoring in
ConnectivityService because the applyUnderlyingCapabilities does
not currently treat null specially.
Bug: 173331190
Test: test-only change
Change-Id: Ic5a3e16969ea9e1a529706850f148cb0d5fd8e09
This is essentially a straighforward move of code from Vpn to
ConnectivityService, and from VpnTest to ConnectivityServiceTest.
Bug: 173331190
Test: passes existing tests, moved tests pass
Change-Id: I76daa3abcc777e9c3ba57efb750de0e2e2f3bb74
The existing method is confusing (the argument used to be called
includeDying) and it puts the burden on the caller (which need to
understand what the parameter means).
Furthermore:
- The majority of calls are for getUsers(excludeDying=true).
- The calls for getUsers(excludeDying=false) are equivalent to
calls to getUsers()
Test: m
Test: a VpnTest ConnectivityServiceTest PermissionMonitorTest
Bug: 157921703
Change-Id: Ife767a40b7b7790ba28b5377046de822ddbf275c
Merged-In: Ife767a40b7b7790ba28b5377046de822ddbf275c
(cherry picked from commit 6dc6d2b964)
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
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
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
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
* 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
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
* 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.
MockVpn is very difficult to use because it requires the test
caller keeping track of both the MockVpn object and an
accompanying TestNetworkAgentWrapper.
It's also not very realistic: for example, connect() doesn't
actually connect anything, it just makes it so that if
ConnectivityService tries to update the capabilities, the attempt
will not be ignored. Also, unlike the real code in Vpn, it
connects with empty NetworkCapabilities (in particular, with
empty UID ranges).
Make this easier to use and a bit more realistic by:
- Allowing TestNetworkAgentWrapper to take a "NetworkCapabilities
template" that will form the initial capabilities sent when the
agent registers with ConnectivityService. This allows the VPN
to register its agent with its UID ranges already set, like the
production code does.
- Providing separate methods to register the NetworkAgent and
mark it connected for cases where the test needs to make
changes to the NetworkAgent before connecting (e.g., poking
NetworkMonitor).
- Putting the TestNetworkAgentWrapper inside MockVpn and driving
it through MockVpn's methods. In order not to have too many
wrapper functions (and because we can't delegate like in
Kotlin), there's still an agent() method that returns the
TestNetworkAgentWrapper.
Bug: 173331190
Test: test-only change
Change-Id: I749ff325bc13ac96f512270b86d1f67686eec378
This CL removes four methods in MockVpn by slightly changing the
test code to leverage the actual methods implemented by the
(production) Vpn superclass.
This works because setting mInterface results in
isRunningLocked() returning true, which makes a number of methods
behave as if the VPN is connected (which is what the test
expects).
The more realistic behaviour exposes a minor bug in the treatment
of underlying networks. Add a TODO to fix it.
Bug: 173331190
Test: test-only change
Change-Id: I49421183538ba61ca790af71e309ece36b653bf9
This test checks that if a VPN declares an underlying network
that does not exist, the capabilities of that network are applied
to the VPN as soon as the network starts to exist.
Bug: 173331190
Test: test-only change
Change-Id: Icc0701cb4cea7d91f7738c1e426e94cd26686b74
Replace InterfaceConfiguration with InterfaceConfigurationParcel
for the incoming ConnectivityService mainline since mainline
modules could not use @hide API.
Bug: 170598012
Test: atest FrameworksNetTests
Change-Id: I17ce8741e985fd30e3c8f0c34e79564a82890dc6
Connectivity service module is using some NotificationManager
@hide APIs but they are not able to call after CS become a
mainline module. Thus, replace them with similar System APIs.
Bug: 170593746
Test: atest FrameworksNetTests
Change-Id: I2644867cfc01d8d651c7029134294a9d44fdb471
Replace the hidden setDefaultNetId and clearDefaultNetId NMS
APIs with accessing INetd directly for the incoming
ConnectivityService mainline.
Bug: 170598012
Test: atest FrameworksNetTests
Test: manually connect and disconnect wifi
Change-Id: I162fae5ca444207a037e5ac4bf8fa0a77a648ca1
ConnectivityService is going to be a mainline module, it can only
use formal APIs or @SystemApi. So use public API -
Context#getSystemService() instead of hidden API -
ServiceManager#checkService().
Bug: 170598012
Test: atest FrameworksNetTests
Change-Id: I9824caa7aec57e70f0ba405fcce39f9bc068732d
ConnectivityService is going to become a mainline module, and
it will not able to use hidden method anymore. Thus, use
alternative new sysprop as API to control the tcp init rwnd
value.
Bug: 170917042
Test: adb shell getprop net.tcp_def_init_rwnd and check if
value is set correctly
Test: atest FrameworksNetTests
Change-Id: If9e99c88de50b6829721b0dfacc430a3b53c7728
Create a new target service-connectivity to split
ConnectivityService from services.core.
Add ConnectivityServiceInitializer for initializing
ConnectivityService and add systemReady() in
ConnectivityManager so that SystemServer can call systemReady()
through ConnectivityManager which won't change current behavior.
Bug: 158268939
Test: make target-java, make host-java
atest FrameworksNetIntegrationTests
atest FrameworksNetTests
make, device can boot,
atest CtsStrictJavaPackagesTestCases
wifi and mobile data work.
Change-Id: I99401772ba9c1c34adca20040da3c7c72d86ddd9
Merged-In: Ie732bfaf381404af0bb599ca2f421a96e7aa4257
In current design, crash has been generated when stop function
has been re-entered to catch unexpected behavior. However,
it is possible to re-enter stop function if the network
disconnection occurs after stopping.
Thus, skip stop if keepalive is already in stopping state.
Test: atest ConnectivityServiceTest#testNattSocketKeepalives \
--rerun-until-failure 60000
Bug: 167332570
Change-Id: Ic7068ad3dc990e957c37b8d87d48ebb6469b101f
