From f01b2efc1357030e8b15d876b604e3176b54e01b Mon Sep 17 00:00:00 2001 From: Chalard Jean Date: Thu, 7 Nov 2019 23:16:12 +0900 Subject: [PATCH] [NS A13] Move legacy broadcast handling after rematch. As opposed to other patches in this series, there is a logic change here. This will send all necessary legacy broadcasts after all matches have been done. This should be fine because the callbacks and the broadcasts are unordered anyway, and the broadcasts are still sent in the same order as before ; there should not be an observable change from apps besides some jitter. Bug: 113554781 Test: ConnectivityServiceTest Change-Id: Ibeab8d0a9106c5198228888ac33084238c0a4a1a --- .../android/server/ConnectivityService.java | 36 ++++++++++--------- 1 file changed, 20 insertions(+), 16 deletions(-) diff --git a/services/core/java/com/android/server/ConnectivityService.java b/services/core/java/com/android/server/ConnectivityService.java index fc42982fb4..2bbcf0dfa8 100644 --- a/services/core/java/com/android/server/ConnectivityService.java +++ b/services/core/java/com/android/server/ConnectivityService.java @@ -6521,22 +6521,6 @@ public class ConnectivityService extends IConnectivityManager.Stub } catch (RemoteException ignored) { } } - - // This has to happen after the notifyNetworkCallbacks as that tickles each - // ConnectivityManager instance so that legacy requests correctly bind dns - // requests to this network. The legacy users are listening for this broadcast - // and will generally do a dns request so they can ensureRouteToHost and if - // they do that before the callbacks happen they'll use the default network. - // - // TODO: Is there still a race here? We send the broadcast - // after sending the callback, but if the app can receive the - // broadcast before the callback, it might still break. - // - // This *does* introduce a race where if the user uses the new api - // (notification callbacks) and then uses the old api (getNetworkInfo(type)) - // they may get old info. Reverse this after the old startUsing api is removed. - // This is on top of the multiple intent sequencing referenced in the todo above. - addNetworkToLegacyTypeTracker(newNetwork); } /** @@ -6559,6 +6543,26 @@ public class ConnectivityService extends IConnectivityManager.Stub for (NetworkAgentInfo nai : nais) { rematchNetworkAndRequests(nai, now); } + + // Now that all the callbacks have been sent, send the legacy network broadcasts + // as needed. This is necessary so that legacy requests correctly bind dns + // requests to this network. The legacy users are listening for this broadcast + // and will generally do a dns request so they can ensureRouteToHost and if + // they do that before the callbacks happen they'll use the default network. + // + // TODO: Is there still a race here? The legacy broadcast will be sent after sending + // callbacks, but if apps can receive the broadcast before the callback, they still might + // have an inconsistent view of networking. + // + // This *does* introduce a race where if the user uses the new api + // (notification callbacks) and then uses the old api (getNetworkInfo(type)) + // they may get old info. Reverse this after the old startUsing api is removed. + // This is on top of the multiple intent sequencing referenced in the todo above. + for (NetworkAgentInfo nai : nais) { + addNetworkToLegacyTypeTracker(nai); + } + + // Tear down all unneeded networks. for (NetworkAgentInfo nai : mNetworkAgentInfos.values()) { if (unneeded(nai, UnneededFor.TEARDOWN)) { if (nai.getLingerExpiry() > 0) {