Issue 199610
When WifistateMachine enter Roaming State, WifiInfo
getSSID will return 0x, statusbar show "0x", because
roaming State do not update WifiInfo mWifiSsid.
Cherry pick from I241f8e9c11dc16db26cadde133043745f2f19573
BUG=27403109
TEST=compile and unittests
Signed-off-by: zhangshuxiao <zhangshuxiao@xiaomi.com>
Change-Id: Ieb7429511898a5ed3d44fd15fc1f250c122e802a
Add a boolean indicating if we have ever successfully connected to a
network given the current configuration. This value should be set to
true upon a successful connection and set to false if the credentials
change. The default value is false.
BUG: 27855896
Change-Id: I1af8f4ad7aac622b48f3c90d88b0debd671a1f40
Add internal comments to the |flags| and |capabilities| fields of
ScanResult to clarify their relationship to the fields in the per-BSS
scan results from WPA supplicant.
BUG: None
Change-Id: I8685283f8cc1006ffd22f2cb2ee8f8605cc0fd2b
TEST: N/A
Adding a new field, meteredHint, to WifiConfiguration so that it
can be passed through and eventually used to set the meteredHint
field on WifiInfo.
BUG: 27120794
Change-Id: If08966c6a5e8eab0905f3335b1c6822975b2f0b5
Instead of minting it's own hander thread, have WifiManager use
the looper from ConnectivityThread.
Bug: 27432949
Change-Id: Iddeebeb8ab506c912f526c7569f304e10b9d7ab8
Now that WifiManager instances are separate and do not depend
on a single static AsyncChannel for the entire process, all
contexts within a process will create an async channel on init.
Since creating this channel requires special permissions that
some applications do not have, it is problematic for them all
to request it in the process of getting a WifiManager instance.
This CL defers AsyncChannel initialization until it is actually
going to be used. This allows callers to create WifiManager
instances without necessarily creating an AsyncChannel.
Depending on what parts of the API will be used, some callers
will never need one. Also, this means that these apps will
not run afoul of permissions exceptions that do not apply to
them unless they actually request functionality that requires
the AsyncChannel.
While here, this CL no longer catches SecurityException while
requesting a messenger from WifiService. That hack appeared to
be an artifact of the static instance of sAsyncChannel -- it
was not clear to WifiManager which context had permissions to
successfully create the messenger, so it was necessary to
silently fail the attempt especially since that attempt was
made in the constructor. With the restructuring to keep
mAsyncChannel per-instance and now only created at the time
specific API calls require it, a SecurityException is
completely relevant to the caller and should not be discarded.
Bug: 27694933
Test: Boot full image, repro b/27694933 with com.google.android.music
Change-Id: I680bf2443bc5b057e629544a687f985261201ded
Thanks to b/24334032, we know that there can be more than one
WifiManager object per process. Also, due to b/19159232 we know
that holding static references to contexts within WifiManager is
not okay. This CL addresses both issues by correctly implementing
Wifimanager as the per-context CachedService as it is instantiated
in SystemServiceRegistry.
To do this, all previously static object members of WifiManager
are converted to non-static. This is primarily safe since:
- In processes which only instantiated WifiManager from a single
context, the behavior is functionally identical between the
static and non-static implementation.
- In situations where multiple WifiManager objects were created,
this is not a real issue:
+ sListenerKey is okay to be tracked per-instance since it
only tracks replies for asynchronous outgoing calls for a
single WifiManager instance (replies are not multicast to
all instances within a pid, since replies from
WifiServiceImpl are addressed to the other end of the
AsyncConnection the request message came from).
+ The same is true of sListenerMap and sListenerMapLock
+ Having a per-WifiManager-instance mAsyncChannel is at worst
a small linear increase with the number of contexts that
use WifiManager, but for the vast majority of processes will
not be an increase at all.
+ Having a thread per WifiManager is something that has been
brought up in the past (b/25644527 comes to mind). I think
we should continue to track that particular problem there.
One static was added: an sServiceHandlerDispatchLock which ensures
that listeners from multiple ServiceHandler threads will be called
sequentially instead of interleaved. Since ServiceHandler was
previously static, this preserves the behavior where multiple
WifiManager objects would not deliver callbacks in parallel.
BUG=19159232
BUG=24334032
Change-Id: I24125a285f97e0c5b3ca4fd721ba8ed19aa245e9
Added EIs to InformationElement to support the parsing of Supported
Rates, Extended Supported Rates, and ERP.
BUG=25691077
Change-Id: Ie540e94f9aa0dca11c3b1d6a46c5a638ec958cff
Add the hidden networkId list in scan settings to be used for
connectivity scans.
BUG: 27503786
Change-Id: Ibe7eaccd84d03a7b48728e3ea1d98ccc974377ec
TEST: Compiles & unit-test passes
Add the public interface for starting/stopping PNO scan.
This is the internal flow that is going to be used for PNO scan:
1. Set Pno list
2. Start background scan
This flow will not work as is for supplicant, since background scan is
done manually today. So, we'll need a flag to indicate that this
background scan is targetted for PNO.
BUG: 27167559
Change-Id: I3f6921c5d03f7d9e8ad1847e57e12fb38df6c9c9
TEST: Compiles & unit-test passes
When debugging WiFi issues, it's helpful to know whether
or not a network uses a hidden SSID. Update
WifiConfiguration.toString(), to provide this information.
BUG=26836097
TEST=capture bugreport, verify "HIDDEN: false" is present for normal net
TEST=capture bugreport, verify "HIDDEN: true" is present for hidden net
Change-Id: I1f7c587fc2eda358e0868e9a7ef0bb2058e726a8
Apps making calls into the system server may end up persisting
internal state or making security decisions based on the perceived
success or failure of a call, or the default values returned.
The reality is that if the system process just died, init will be
along shortly to kill all running apps, so we should have no problem
rethrowing the RemoteException as a RuntimeException.
Bug: 27364859
Change-Id: Ife0bcb079636c88d54c44d17eb580409fd79028b
