Setting the same code is redundant, and may cause supplicant to drop
currently connected connection.
Bug: 11303252
Change-Id: I1af57b3af2d0b8cc51939a8b9872fb3fe0105a91
Note that this CL does not change any behaviour.
At the center of this change is
CaptivePortalTracker#detectCaptivePortal(), which does nothing
except call back into ConnectivityService. Removing it allows us to
simplify code in ConnectivityService. It also allows us to remove
ConnectivityService#captivePortalCheckComplete which was only ever
called in response to this method.
While this does not change any behaviour, it preserves existing
bad behaviour, i.e, that the CAPTIVE_PORTAL_CHECK NetworkInfo
state does not correspond to actual captive portal detection.
We transition into that state and immediately (and unconditionally)
out of it and into CONNECTED.
Change-Id: Ib3797f956d2db5e3cacaaa53e899d81aa8e958af
We were ending up with 1 reference to every char array
in which a new AP was discovered. In a busy env this could
cost several hundred K from the dalvik heap.
bug:11087956
Change-Id: I3b14c39fd0c98e4aea08a406e80bcf6af40d0664
The method would previously always return false.
Note that this is the simplest fix, and not the most
optimal fix. That said, in this change, a call to
WifiInfo#getHiddenSSID costs the same as a call to
WifiInfo#getSSID, so it isn't that bad.
bug: 10705138
Change-Id: I980563fd8a5bafe8c58c586449e778a0aa8b58a4
Networks should be unconditionally disabled when going to
scan only state or we risk connecting when we don't want to.
bug:11062188
Change-Id: If89621ca07d86673a661d2e5fe4ce89286f8835e
The transition from driver-started to scan-only state was incorrectly
always marking wifi disabled, but transitioning back only marked it
enabled if we were exiting due to leaving the scan-only-with-wifi-off
mode.
bug:11062188
Change-Id: I44fe64fd8dac8f36f4e22cb1c16b9d7a06bdbac0
When we disable wifi while wifi p2p peer searching is in progress, we don't get
a WIFI_P2P_DISCOVERY_CHANGED_ACTION broadcast saying that discovery is stopped.
Since this broadcast is sticky, applications will still get the previous one
saying discovery is started even if wifi p2p has been disabled. Adding a
sendP2pDiscoveryChangedBroadcast when exiting P2pEnabledState fixes this problem,
and it won't be a duplicate as sendP2pDiscoveryChangedBroadcast checks for that.
Bug: 11151666
Change-Id: I62de8f3d17d80f151403b91cf5c62866d931c01b
After a L2ConnectedState to WpsRunningState transition, network is disconnected.
However, the disconnected message is ignored by WpsRunningState, leaving DHCP
still running. When entering L2ConnectedState again, WifiStateMachine gets stuck
on waiting for DhcpStateMachine, because DHCP is already running and the command
CMD_START_DHCP is ignored. Calling handleNetworkDisconnect() when exiting
L2ConnectedState fixes this problem, plus it handles disconnection correctly.
Bug: 10900241
Change-Id: Id29e4989b29db7e64719940cf93eba1f1a90912a
After a reboot, KeyStore is locked, and certificates encrypted with user
PIN are not accessible. So statemachines are not able to connect to
EAP-TLS networks. This change makes the problem less severe by
1. Not signing certificates with user PIN on devices with hardware backed
KeyStore.
2. Issuing a reconnect upon first USER_PRESENT event.
This means HH (which has a hardware backed keystore) can connect to
EAP-TLS networks without requiring user intervention and other devices
will automatically connect to those networks after user punches PIN.
Bug: 10325089
Change-Id: I023d60e58d8214152f051bd9ec84b85b702d829a
This ignores any previous setting and instead uses
a value set at build time. This does not preclude
us from using some other signal to determine country
for wifi channel limits.
bug:10513734
Change-Id: Ib82c07285af70fbd82eb0466b7391979ebc8be10
ScanModeState is trying to undo whatever it did in its enter(), in its
exit() function. But doing that is incorrect because it is possible to
transition to multiple states that require different conditions.
In this bug, the state machine transitioned from ScanModeState to
WaitForP2pDisabled state; in response to Stop Supplicant command. Well,
when we are trying to stop supplicant, there is clearly no need to
enable P2P or load all networks. But since this code exists in exit(),
it is executed nonetheless, causing race conditions accessing the
wpa_supplicant (WifiStateMachine is trying to shut it down, but
P2pStateMachine is trying to bring up the p2p interfaces).
We solve that problem by moving this code to the place where we transition
to DisconnectedState - since that's the state that needs this as a
precondition.
Bug: 10761752
Change-Id: Iaf0ffd8056de8533b5d2bfdf8c440fbb7e406dac
Framework sets allowedKeyManagement to WPA_EAP + WPA_PSK, if
WifiConfiguration didn't supply any value for it. It should probably
change to NONE; but that is post K thing. I am allowing that
combination for now.
Bug: 10843500
Change-Id: Id0c28f4aaf32c6a7e7dca07114a2452ce194a798
Scanning while dhcp is running breaks dhcp, so stop the batched scans
when we need dhcp and start it up again after.
bug:10691401
Change-Id: Ifdeb6f35cfe4509b90fed1e1e694d0c107f24a7e
There used to be some STOPSHIP code in WifiWatchdogStateMachine for debug
purposes. We don't need them for the release.
Bug: 10841961
Change-Id: I501d62e9891ace52317e6c1d399b877175099a3c
Multiple authentication methods are currently considered invalid; but
WPA_EAP and IEEE8021X are set simultaneously. This means we need to
fix code to consider them a valid combination.
Bug: 10325089
Change-Id: I2b4f4d75f21df78bfca66a930e85214c0cd6922e
