IssueTracker

Thank you for reporting this issue. We have shared this with our product and engineering team and will update this issue with more information as it becomes available.

Response from engineering team:
==========================================
Please describe the use-case you are trying to solve. The current request lists a set of APIs that you want (i.e. specific solutions) - but we need to understand what it is you're trying to solve before discussing specific APIs.
==========================================

We are a Wi-Fi access points manufacturer and want to keep providing our existing original Wi-Fi connection setup solution for Android Q users.
Solution overview:
  - Our app gets some sets of  SSID and PSK to connect to access points (e.g. scanning QR code).
  - Our app calls WifiManager#addNetwork() to register WifiConfiguration to OS.
  - Then, our users open Settings app (WifiSettingsActivity) and select one of  registered SSIDs they want to connect to. Users can manually switch to their preferred SSID (e.g. bands, the nearest, guest port, etc.).

Prior to Android Q, our app can register WifiConfiguration but cannot register it on Android Q. We tried to use WifiNetworkSuggestion as an alternative, but it seems to automatically connects to one of suggested SSID that is judged as 'suitable' by OS, so users cannot manually switch to their preferred SSID.

We expects one of below:
  - Keep supporting WifiManager#addNetwork() and WifiConfiguration.
  - Users can manually switch to their preferred SSID from SSIDs suggested by WifiNetworkSuggestion.
  - Any other alternative method is provided.

Thanks

Response from engineering team:
==========================================
We don't currently support users interacting with app suggested networks (via WifiNetworkSuggestion API surface). If the user clicks on the network in wifi settings & provide the credentials, the network will be stored as a saved network (separate from the suggestion provided by the app for the same network). We've intentionally tried to separate user added network database from external app added network databases because we want to handle these network classes differently for auto-connection, etc.

We might consider this scenario in R, but this is not going to be implemented in Q.

There are a few options for the app developer to consider For Q:
a) Apps can use WifiNetworkSuggestion API surface to provide a priority among their networks. If the app can provide a UI to let the user set a priority among the networks inside their app, the app can pass that priority down into the platform via the API surface & the platform will honor it.
b) Apps can continue to use the old API surface by targeting a lower SDK (<=P). Note: This exception might go away in R.
==========================================

We understand your intention that you added WifiNetworkSuggestion but we believe it is also necessary to be able to select a SSID which the users want to connect to. Additionally, our users need auto-saving networks solution and so our app is indispensable for them.

We also know that our app can work as in the past on Android Q because the apps can use the old API by targeting a lower SDK (<=P). However, we afraid that our app will be not able to work on Android R or later, so we expect that the API to be able to store the networks the same as before will be provided.

Thanks

Response from engineering team:
==========================================
I'm not sure if this is a use case we plan to support via this API surface. Android Q adds native support in the platform to provision credentials from AP's via QR codes & Easy Connect (DPP). I would recommend switching to those WFA standard based solutions instead.
==========================================

@7 I've found about this now too.
Wrote here:
https://issuetracker.google.com/issues/136787263

Please consider bringing back the addNetwork API, or provide a better API.
There is no reason to remove it completely.

Would like to chime in here to agree VERY STRONGLY with the concerns outlined in this bug!

There is an entire class of apps out there that exist to help users get connected to wireless networks.   These API changes effectively gut those apps, and there doesn't appear to be any new APIs that provide an alternative method of configuring a network.   (Such as something like mobileconfig on iOS.)

While the suggestion that apps continue to target API 28 as a "workaround" for this seems like an okay suggestion, the reality is that it isn't really an option.   With API 29, the old API doesn't work the same as it did on API 28, even when targeting API 28.   Worse, if you continue to use API 28, you can't make use of WPA3.  (https://issuetracker.google.com/issues/135376217)

So, perhaps we should use a combination of WifiNetworkSuggestion (through reflection maybe?) plus the old method while targeting API 28?   Well, that might work, except for the fact that there doesn't appear to be any way for an app to request that the OS connect to a different network, if it is already connected to one!  (https://issuetracker.google.com/issues/136123248)

Which means that you have effectively killed off apps by Cisco, HP/Aruba, Commscope/ARRIS/Ruckus, Buffalo, and probably a whole host of others!   Apps that *MILLIONS* of users rely on!  (Pick any one of the companies I listed.  Each one of them has MILLIONS of users!  So, the aggregate total is probably hundreds of millions of users!)   How is it going to look to Android users when all of those companies either tell their customers via support channels, release notes, or perhaps press releases that Android 10 isn't supported because Google has decided that they know best, and users can configure their own networks?   (Does nobody at Google have a parent or friend that isn't handy with computers?)

Although the companies I previously listed are generally competitors, it might be fun to get their PR departments together to issue a combined press release talking about how Google has decided that their products aren't worthy of running on Android, and how Android users are basically screwed.   C'mon Google!  You guys are SMARTER than this!!

Meanwhile, on boarding an iOS device is relatively simple.   You download a signed mobileconfig file, install it, and you are off and running!

We've deferred this issue for consideration in a future release. Thank you for your time to make Android better. In case you want to provide more information with respect to this bug, please file a bug in AOSP via "https://goo.gl/TbMiIO

Any update on bringing back legacy wifimanager api's(addNetworks, enableNetwork etc) on Android R?

As we'll need to update the targetSdk to 29 by November 2,2020(https://support.google.com/googleplay/android-developer/answer/113469#targetsdk). . .
We'll either need to go ahead with suggestions api or scrap our app.

There is a same error here
https://issuetracker.google.com/issues/150400470

Thank you for your feedback. We will be closing the issue as “won't fix - obsolete”. In case you want to provide more information, we request that you log a new issue here https://goo.gl/TbMiIO and reference this bug for context.