GitLab

Before this, when WifiScanningService processed single scan results from
supplicant that only contained results that did not match a request the
filter code would return null indicating that the results should not be
delivered, causing a NPE later. This change updates the meaning of the
bucket index that the single scan code provides to the filtering code to
instead force it to always include scan results.

Change-Id: I65cd57b14abacec3f407991188c570601d05ac77
Fixes: 28794598

* changes:
  WifiConfigManager: clean up makeChannelList()
  WifiStateMachine: clean up dead code
  WifiConnectivityManagerTest: exponential backoff periodic scan
  Restrict connectivty periodic scan

Removed the unused input paramater 'restrict'. Updated its
callers.

Bug: 28786277
Change-Id: I44dc870ce3f353698187f76e8996cc77395b17d3
Tests: Wifi Framework Unit Tests, manual tests

Cleaned up the dead code from the original exponential back off
scan implementation.

Bug: 28750989
Bug: 28070598

Change-Id: I8abf82cdaa3530fb514794b4004c5d3f15950672
Tests: Wifi Unit Tests, manual test

Add a couple of unit tests to cover the periodic scan exponential
backoff feature.

Extended MockAlarmManager class such that users can query a
pending alarm's trigger time.

Bug: 28750989
Change-Id: I9520477180786fce2937e5fa87f790f60f12a3da

When the phone screen is on, the periodic scan interval is setup
in an exponential backoff fashion. Also, if the traffic is higher
than certain threshold, perform scan on certain channels only
instead of full band.

Bug: 28627603
Change-Id: I95b686d7835265d843edac7c005f661393ae5383

Since PNO scans are started by the PNO debouncer (which debounces PNO state
change for 5 seconds), the log message stating that we have started PNO
scan should be moved to the location where the scan is actually started.

This removes the confusion from the logs in the below case:
05-16 16:51:40.135 D/SupplicantWifiScannerImpl(  876): Change PNO state
from false to true
05-16 16:51:42.356 D/SupplicantWifiScannerImpl(  876): Change PNO state
from true to false
05-16 16:51:45.109 D/SupplicantWifiScannerImpl(  876): Start PNO timer
with delay 2247
05-16 16:51:45.116 D/SupplicantWifiScannerImpl(  876): Starting wifi PNO
scan
05-16 16:51:50.111 D/SupplicantWifiScannerImpl(  876): Change PNO state
from false to true
05-16 16:51:52.368 D/SupplicantWifiScannerImpl(  876): Change PNO state
from true to false
05-16 16:51:55.143 D/SupplicantWifiScannerImpl(  876): Start PNO timer
with delay 2225
05-16 16:51:55.148 D/SupplicantWifiScannerImpl(  876): Starting wifi PNO
scan

BUG: 28800979
Change-Id: Ib4cc7c59fde83a02a2b938fb334a85f0c046cd87

This also fixes the potential crash when handling intent
with null action string.

BUG=28689719
TEST=compile
TEST=runtest frameworks-wifi

Change-Id: I6ef3e07e38f33d8c5040dd358f161224095189d6

During 802.11 authentication, we've seen wpa_supplicant
report error information that is at odds with
over-the-air traffic.

For systems that provide packet fate for these early
frames, we can gather better information about the
auth process from the frames themselves.

Specifically: we can include the status code in the
packet fate summary. Make it so.

While there:
- fix a whitespace issue in parseIeee80211FrameCtrlType()
- rename frameControlField, since it didn't really hold
  all of the frame control info. (frameControlField
  omitted the frame control flags.)
- modify some packet fate tests to be less specific about
  expected whitespace; it's too hard to maintain the tests
  when exact whitespace matching is required

BUG=28717266
TEST=unit tests
TEST=manual

Manual test
- configure hostapd to allow zero connections
- configure bullhead to connect to hostapd
$ adb shell dumpsys > /tmp/dumpsys
- verify that packet fate summary shows auth frame with status 17

Change-Id: Ib8742091d0a9acc7fdde0423229d150bf4c1c6d8

Change-Id: I87779468d37971c53c1c9cfd615e5ca2e7a65108
Fixes: 28793104

Bug: 28437662
Change-Id: I9d478d644cc5b52a031a3ee3e157d40f952dff50

* changes:
  WifiController: set to proper state after SoftAP
  WifiControllerTest: cleanup style issues
  WifiSettingsStore: add methods for WifiSavedState

Now that writeApConfiguration has no return type, so we
should also ignore the value in the tests.

BUG=28692504
TEST=compile
TEST=runtest frameworks-wifi

Change-Id: Ia4a562335de2c1dcadb5f41dcb3dc9f96a926680

After receiving a CMD_AP_STOPPED message, WifiController should return
to the DeviceActive state or the appropriate Idle state.  This CL sets
the correct pending state and also adds a check for the idle state.
A test is also added to confirm the DeviceActive state is entered after
the SoftAp state is completed.

Note: An additional test for the DeviceIdle path will be added at a
later point after some code refactoring (bug 28669096)

BUG: 28434530
Change-Id: Ie19e66b9c84ff545a622119890bc7705ebd74c46

Clean up some style issues for WifiControllerTest.

This is in preparation for additional tests being added for the bug fix.

BUG: 28434530
Change-Id: Idfcc51e2d30753051b9d8e2ec066035f771f0339

Add methods to get and set WifiSavedState in WifiSettingsStore.  This
change allows us to better test state transitions in WifiController
since we can now mock out the calls easily.

BUG: 28434530
Change-Id: Ie2b6f0311462da0179ecd28665f78f4bf14a02f9

Quite some logs should be debug message instead of error
message.

Bug: 28619076
Change-Id: Iee06f57bab58aeca881068f0b4f36a0d5bbb3230
Test: Wifi Unit Tests

This CL uses value comparision instead of reference comparision
for strings.
This also removes returning value in finally block, otherwise
exception may be suppressed.

BUG=28605846
TEST=compile
TEST=runtest frameworks-wifi

Change-Id: I6ace4d233d2b0af3627f75dfdb7dcec6a46b0092

Truncate the hidden network id list if it goes beyond wpa_supplicant's
max value. wpa_supplicant has a hard coded value of 16 for the max
number of networks that can be specified for each scan.

There is currently no way to query this value from wpa_supplicant, so
hardcoding this value in SupplicantScanner.

BUG: 28632556
Change-Id: I31a338b91c221c1686437b738894e13abb897474
TEST: Compiles & unit-test passes

Always return when the current preferred BSSID is the same as
the target one. This was done previously only if the DBG flag
is set.

While there, fixed the log message wording a bit.

Bug: 28619076
Tests: Wifi unit tests, manual connection & roaming tests
Change-Id: I109b57d54b1bcaccb00a148b488244b7d9358907

Clear the config BSSID after roaming completed and before entering
ConnectedState. Wifi chipset may roam from this point on and
having the BSSID specified by QNS would cause the roam to fail
and the device to disconnect.

We used to rely on the fact that entering ObtainingIpState
clears the config BSSID. But this assumption was broken by
commit bcbc449d, which changed from transition
to ObtainingIpState to ConnectedState.

Bug: 28520770
Test: Wifi unit tests, manual tests
Change-Id: I09a2d5d1132ff597c63a324a24d13719be384603

* changes:
  WifiConnectivityManager: Unit tests for metrics
  WifiConnectivityManager: Increment metrics

Add couple of unit-tests for metrics. Had to migrate the unit-tests to use
mock alarm manager.

BUG: 27479439
BUG: 27704599
BUG: 28480516
Change-Id: I1424053c35799905612b37edeb679e7556568ca5
TEST: Compiles & unit-test passes

Make changes to increment the watchdog related metrics in
WifiConnectivityManager.

PS: Will need to add mock alarm manager to add unit-tests here. This is
done in the next CL.

BUG: 27479439
BUG: 27704599
Change-Id: I96e35e06d222056ec29488666619486a65746b38

If the vendor's Wifi HAL does not provide packet fate
functions, then WifiServiceImpl (and hence, system server)
will crash when WifiLogger calls packet fate functions.

Fix this, by providing stub implementations. These will
be automatically overriden by vendor-provided implementations.

BUG=28565646
TEST=manual

Manual test:
- repeat for angler and bullhead:
  - try to connect to WPA-2 network with wrong password
  $ adb shell dumpsys > /tmp/dumpsys
  - verify that dumpsys contains "Last failed connection fates"
  - verify that dumpsys shows Authentication messages
- on bullhead
  - hack up HAL, so that packet fate functions are not registered
  $ adb logcat -d | grep 'Failed to start packet fate'
    -> should see matching lines
  (with the hacked up HAL, and without this patch, the call to
  startPktFateMonitoring() causes a SIGSEGV, instead of just a
  clean failure message)

Change-Id: I86ce34784dea396f9e8741353395cab1ec6e0913