Don't match network requests to legacy API requests.

Currently, we look at network requests that are created by the
current requestNetwork API to see if they look like requests
that could have been created using the legacy
startUsingNetworkFeature API.

This causes those networks to be added to LegacyTypeTracker,
and so cause CONNECTIVITY_ACTION broadcasts, be accessible
using getNetworkInfo(int type), etc. This was done in the L
timeframe so that apps could request networks using the
then-new requestNetwork APIs and still use them using legacy
APIs such as requestRouteToHost.

However, the resulting CONNECTIVITY_ACTION broadcasts are
expensive. requestRouteToHost has been deprecated since L, and
mixing the old and new APIs was never recommended, so it's time
to delete this hack.

Bug: 22513439
Bug: 23350688
Bug: 25295964
Change-Id: Id867058446e5ee44396743d126d26fa57da0c990

diff --git a/core/java/android/net/ConnectivityManager.java b/core/java/android/net/ConnectivityManager.java
index 02c5bbd..515e9a2 100644 (file)
--- a/core/java/android/net/ConnectivityManager.java
+++ b/core/java/android/net/ConnectivityManager.java
@@ -1028,13 +1028,25 @@ public class ConnectivityManager {
      * Guess what the network request was trying to say so that the resulting
      * network is accessible via the legacy (deprecated) API such as
      * requestRouteToHost.
-     * This means we should try to be fairly preceise about transport and
+     *
+     * This means we should try to be fairly precise about transport and
      * capability but ignore things such as networkSpecifier.
      * If the request has more than one transport or capability it doesn't
      * match the old legacy requests (they selected only single transport/capability)
      * so this function cannot map the request to a single legacy type and
      * the resulting network will not be available to the legacy APIs.
      *
+     * This code is only called from the requestNetwork API (L and above).
+     *
+     * Setting a legacy type causes CONNECTIVITY_ACTION broadcasts, which are expensive
+     * because they wake up lots of apps - see http://b/23350688 . So we currently only
+     * do this for SUPL requests, which are the only ones that we know need it. If
+     * omitting these broadcasts causes unacceptable app breakage, then for backwards
+     * compatibility we can send them:
+     *
+     * if (targetSdkVersion < Build.VERSION_CODES.M) &&        // legacy API unsupported >= M
+     *     targetSdkVersion >= Build.VERSION_CODES.LOLLIPOP))  // requestNetwork not present < L
+     *
      * TODO - This should be removed when the legacy APIs are removed.
      */
     private int inferLegacyTypeForNetworkCapabilities(NetworkCapabilities netCap) {
@@ -1046,6 +1058,14 @@ public class ConnectivityManager {
             return TYPE_NONE;
         }
 
+        // Do this only for SUPL, until GpsLocationProvider is fixed. http://b/25876485 .
+        if (!netCap.hasCapability(NetworkCapabilities.NET_CAPABILITY_SUPL)) {
+            // NOTE: if this causes app breakage, we should not just comment out this early return;
+            // instead, we should make this early return conditional on the requesting app's target
+            // SDK version, as described in the comment above.
+            return TYPE_NONE;
+        }
+
         String type = null;
         int result = TYPE_NONE;
 
@@ -1062,7 +1082,7 @@ public class ConnectivityManager {
             type = "enableDUN";
             result = TYPE_MOBILE_DUN;
         } else if (netCap.hasCapability(NetworkCapabilities.NET_CAPABILITY_SUPL)) {
-           type = "enableSUPL";
+            type = "enableSUPL";
             result = TYPE_MOBILE_SUPL;
         // back out this hack for mms as they no longer need this and it's causing
         // device slowdowns - b/23350688 (note, supl still needs this)