summaryrefslogtreecommitdiff
path: root/opengl/java
diff options
context:
space:
mode:
authorLorenzo Colitti <lorenzo@google.com>2020-12-02 00:48:09 +0900
committerLorenzo Colitti <lorenzo@google.com>2020-12-13 00:10:56 +0900
commit6c01b8ebf7c7242c99c0765e5d03072c11e1a33b (patch)
tree16cad910ed45ccad6c6507f5a34f57136d1e5938 /opengl/java
parenta07cabc065c5b00c6937b8fd8e357957e2cd15a5 (diff)
Generalize support for underlying networks.
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
Diffstat (limited to 'opengl/java')
0 files changed, 0 insertions, 0 deletions