This is not ideal but better than the current situation given that the
rest of the connectivity stack does not properly support multi-user.
Bug: 17320659
Change-Id: Ia0d4c746b4ebe6ce90df7ff39f0398ca78fd61f6
Per the latest mocks, advanced wireless settings will be the only
location in platform settings where Wi-Fi Assistants are configured.
The card is no longer being used.
Bug: 13780935
Change-Id: Idddf971404532256165045665bd0a6b19966d2bd
Configurations for these networks are not returned in
getConfiguredNetworks() and likely shouldn't be as clients of this API
would not expect them. (Note also that the ephemeral bit is marked
@hide). But the framework may connect to them regardless.
In these cases, as long as the connection status is something other
than the coarse-level DISCONNECTED, we show the status to be an
accurate representation of Wi-Fi state. (To make this possible, we
pass around the full NetworkInfo instead of just the DetailedState,
allowing us to get the coarse state where needed).
When long pressing on a non-DISCONNECTED ephemeral network, we offer
the ability to save the configuration. (Note that this flow is
currently broken and being tracked by another bug, but the behavior is
consistent with what happens when you simply click on the SSID).
Bug: 18205278
Change-Id: I30592c89546068c796f458a86bb26eb3b28c64df
This allows QS to set an extra that will launch the adding network
dialog directly for a specified ssid. It will be used to take users
straight from QS to the password entry, when a secure network is
selected.
Bug: 17722817
Change-Id: I570596af906de005c505678b539f915c06e6fd14
In Wi-Fi setup, when the connection state changed, query
ConnectivityManager for the latest Wi-Fi connection state instead of
relying the NetworkInfo attached in the intent, because the first
network info upon changing AP still shows the network as connected.
Bug: 17511772
Change-Id: I9c7765086dc8fbc5e1c2a37124ca89db3eab04a3
It is happening because there previous view doesn't disconnect
itself from setting change; and then two views alternatively
enable/disable wifi.
Bug: 17157005
Change-Id: I42916a7bbd735960a26efbae670c9b927ec8574d
+ Removed Wi-Fi Assistant message in Wi-Fi Advanced since it was
overridden by the Wi-Fi Assistant.
+ Removed Wi-Fi Assistant message in Wi-Fi Assistant Card. Instead,
it is programatically created when the scorer is known.
+ "Google" was replaced with a placeholder.
Bug: 17457236
Change-Id: If3aab06c911ecf6ec13cbf00dea2fe9333abc1fc
This change removes requirement that sender has this permission for
protected broadcasts (since they can only come from framework)
Bug: 17409667
Change-Id: I3431c20a4ed28b3ba2bfc3cf53772e63a3424a2c
- remove any reference to the Switch and use the SwitchBar API instead
- set the initial state of the SwitchBar depending on the WifiManager
Change-Id: I556bf8a007892c057edf7c6c144f71b2dcfe4f99
This change addresses concerns from the API review. Things that
are fixed are -
1. WifiAdapter is removed, until we have 'real' support for it
2. All the methods from WifiAdapter are moved to WifiManager
3. Changed WPSListener API names to be onFailed/onSucceeded et al
4. Removed ActionListener from WPS APIs, they now take WpsListener
Bug: 16403303
Bug: 17115004
Change-Id: I609c42f08b52f77240ce9a97b1a9941a9c154752
SDK version is an int, not a long. (Also change SharedPreference key
to avoid issues for people who've already dismissed the Wifi Assistant
card).
Bug: 17304642
Change-Id: Ic959516b88e91edd53562703fa7db9c15ead20e4
