Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 24b7fe01 authored by Chalard Jean's avatar Chalard Jean
Browse files

[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
parent 3892583c

services/core/java/com/android/server/ConnectivityService.java

+20 −16
Original line number Diff line number Diff line
@@ -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) {