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
Minor cleanup as per nit comments on approved CLs in the relation chain.
Namely:
- removing an extranous space
- changing requestsSortedById() to be package private
- changing releaseNetworkRequest() name to releaseNetworkRequests()
- adding final in a couple spots
- added some test requests in testDumpDoesNotCrash()
Bug: 173145245
Bug: 173292541
Bug: 173146509
Bug: 171991028
Test: atest FrameworksNetTests
Change-Id: I177ec6072a44acd247022b65b56e90cc231094b9
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.
UserManager#getUsers() is a hidden API, use getUserHandles() to
get user id instead in PermissionMonitor.
Bug: 171529940
Test: atest FrameworksNetTests
Change-Id: Ic304627688de8e49505a95ebc99628b2e0eafab9
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
NetworkProvider does not require ConnectivityService to be started at
creation time after R, but on R it is queried in the constructor.
Fixes: 175164957
Test: atest FrameworksNetTests
Change-Id: I435ace581668970a7d88e68f11cb37814edb79ea
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
NetworkUtils is planned to move to a dedicated JAR for connectivity
classes, while NetworkUtilsInternal would stay in the
frameworks-minus-apex JAR, in the com.android.internal.net package.
Bug: 171540887
Test: m, boots, wifi working
atest FrameworksNetTests
Change-Id: I3d38d72ad23a4bf84af823c7baeb6fed25c0665f
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 6dc6d2b96498bcca132913dbfc6338f8f9f6c697)
Cleaning up tests, so I can easily add more for restricted networking
mode.
I merged the NetworkManagementInternalTests with the
NetworkManagementServiceTests.
Test: atest NetworkManagementServiceTest
Change-Id: If8c3cc1883cfb2524eeb78e23165fc868130f0e7
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
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
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
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
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
