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
Per API guidelines - non-overlapping constants can be (should be)
named with "FLAG".
Bug: 27122760
Change-Id: If8b2c0f9b2818215a64b5635e76731c8fdfd3b8d
Changes in the android framework to use the modifed HAL API to
fetch the host wakeup reasons from the driver.
BUG: 26902794
Change-Id: I4df53c00b6b4ffd9f9ddb45577f6bccf150c43e4
The "auth=GTC" method was never valid for the TTLS outer
authentication for wpa_supplicant. Instead, to perform
GTC authentication within TTLS, we should use EAP-GTC.
This CL performs this mapping within WifiEnterpriseConfig.
It accomplishes this by making the EAP Method and Phase 2
Method parameters a part of the internal object state
instead of maintaining this value within the mFields
hashmap.
Further, the problematic "getFields" method is removed
since as this actually provided read/write access to the
entirety of the WifiEnterpriseConfig's internal state.
This was understandably suboptimal. All callers have
been updated to either use getFieldValue() or to call
a newly added getSupplicantFields() / setSupplicantFields()
methods which make the WifiEnterpriseConfig object a sole
arbiter for the mapping between its internal state and
wpa_supplicant.
In the future it might be good to change this logic to
strip WifiEnterpriseConfig of all of the string hashmap
entirely, leaving WifiEnterpriseConfig as a "struct"
and move supplicant mappings to WifiConfigStore.
Bug:26400915
Change-Id: I866e2f77ad53d9a51c5f61acb9adef522661f721
Test:runtest frameworks-wifi # New unit test in the same topic
Test:cts-tradefed run cts -d --class android.net.wifi.cts.WifiEnterpriseConfigTest
The interfaces had multiple functions and are hence callback
and not a listener.
Note: purely a rename operation.
Bug: 27122760
Change-Id: Ib12711f56a64052455843859125d72268c465fc0
Add the concept of a client ID which is used to identify a specific
(one of several) clients in all API calls.
Bug: 26962024
Change-Id: I43f13d51bee8b57c6d0ba1174168288b8d6c21c5
This method seemed like a good idea at the time (quickly check whether a
network configuration is visible to a given user). However, once managed
profiles come into play, this simple method is no longer appropriate.
There is a more comprehensive replacement at
com.android.server.wifi.WifiConfigurationUtil.isVisibleToAnyProfile()
now and this method here can go.
BUG:26867426
Change-Id: Ia66aa6f74003a16eca24c5088d3aba8e0c9f8140
In the (hopefully rare) situation where there is a remote exception
from a call to getScanResults(), do not pass null back to callers.
Nobody expects this, and failures that occur as a result can distract
from the real problem (e.g., the system server crashing). This CL
now returns an empty list.
BUG=27139097
TEST=None
Change-Id: I637eae1fa8ac1a1bc2b76dea8628359b5dec06e1
