Fix a bug where a spurious capabilities callback is sent.

When a VPN connects and it has any underlying network (which
means almost always, because it will take the default network
if it doesn't declare any), it has default capabilities and
will only take the capabilities of its underlying network
as part of an update happening after making the network
available but before the rematch can take place. This in turn
causes the capabilities callback sent as part of the rematch
to be spuriously sent.

Test: FrameworksNetTests. Also tested together with a
      followup that adds tests with drive-by coverage for this.
Bug: 150570873
Change-Id: Id7d8bba486bada1a7ba5b0f152d2aa02e407f249
This commit is contained in:
Chalard Jean
2020-05-07 12:07:03 +09:00
parent 93c21fc7b5
commit d568791283
2 changed files with 8 additions and 2 deletions

View File

@@ -7095,6 +7095,14 @@ public class ConnectivityService extends IConnectivityManager.Stub
networkAgent.networkCapabilities.addCapability(NET_CAPABILITY_FOREGROUND);
if (!createNativeNetwork(networkAgent)) return;
if (networkAgent.isVPN()) {
// Initialize the VPN capabilities to their starting values according to the
// underlying networks. This will avoid a spurious callback to
// onCapabilitiesUpdated being sent in updateAllVpnCapabilities below as
// the VPN would switch from its default, blank capabilities to those
// that reflect the capabilities of its underlying networks.
updateAllVpnsCapabilities();
}
networkAgent.created = true;
}

View File

@@ -5393,8 +5393,6 @@ public class ConnectivityServiceTest {
// Even though the VPN is unvalidated, it becomes the default network for our app.
callback.expectAvailableCallbacksUnvalidated(vpnNetworkAgent);
// TODO: this looks like a spurious callback.
callback.expectCallback(CallbackEntry.NETWORK_CAPS_UPDATED, vpnNetworkAgent);
callback.assertNoCallback();
assertTrue(vpnNetworkAgent.getScore() > mEthernetNetworkAgent.getScore());