C-1-1: MUST implement the WifiAwareManager APIs as described in the SDK documentation.
--> SingleDeviceTest
C-1-4:MUST randomize the Wi-Fi Aware management interface address at intervals no longer
then 30 minutes and whenever Wi-Fi Aware is enabled
-->SingleDeviceTest#testAttachDiscoveryAddressChanges()
CDD SECTION:7.4.1.1/C-1-1,C-1-3: Wifi Direct
C-1-1: MUST implement the corresponding Android API as described in the SDK documentation.
C-1-3: MUST support regular Wi-Fi operation.
--> ConcurrencyTest
7.4.2.4/C-1-1,C-2-1:
C-1-1: MUST implement the Passpoint related WifiManager APIs as described in the SDK documentation.
C-1-2: MUST support IEEE 802.11u standard, specifically related to Network Discovery and Selection,
such as Generic Advertisement Service (GAS) and Access Network Query Protocol (ANQP).
--> Passpoint configuration tests
Added C-0-3 to ConnectivityBackgroundTestActivity as well
CDD VERSION: 8.1: https://source.android.com/compatibility/8.1/android-8.1-cdd
Bug: 112612833
Test: make cts
Change-Id: Ief11b3ae7899bfdca12a7cce63daca600b1f0cdf
One of the preparation steps for running cts involves loading up the sim
card with the key used to sign CtsCarrierApiTestCases.apk. It
means if the same key is used for signing networkpolicy test app too,
then the app is considered as carrier privileged by the system and can't
be forced into app standby state.
Fixes: 77861812
Test: cts-tradefed run singleCommand cts-dev -m CtsHostsideNetworkTests -t \
com.android.cts.net.HostsideRestrictBackgroundNetworkTests#testDataSaverMode_disabled
Change-Id: Iaa9f4fabe83430fa42b6f67c1025db41a5e1d938
Merged-In: Iaa9f4fabe83430fa42b6f67c1025db41a5e1d938
One of the preparation steps for running cts involves loading up the sim
card with the key used to sign CtsCarrierApiTestCases.apk. It
means if the same key is used for signing networkpolicy test app too,
then the app is considered as carrier privileged by the system and can't
be forced into app standby state.
Fixes: 80077890
Test: cts-tradefed run singleCommand cts-dev -m CtsHostsideNetworkTests -t \
com.android.cts.net.HostsideRestrictBackgroundNetworkTests#testDataSaverMode_disabled
Change-Id: Iaa9f4fabe83430fa42b6f67c1025db41a5e1d938
Modify the assert message to print out the # of failures and the total
number of iterations. Will help diagnose scope of test failures.
Bug: 109836816
Test: atest WifiRttTest
Change-Id: Ic4d5b6844225edbd9704694c539e31754b7a340c
Currently, DnsTest immediately executes a DNS lookup as soon as
it starts. If the device has just connected to a network - as it
might if the test framework has just enabled wifi - and IPv6
connectivity is not yet available, the test will fail with little
proof that the network doesn't have IPv6.
Fix this by waiting for IPv6 connectivity and by adding the
active LinkProperties to the failure message.
Bug: 109670546
Test: DnsTest passes on dual-stack network
Test: DnsTest fails on IPv4-only network
Change-Id: I88b8d001f08fe41af666bccf8094c67729dda9c2
BATTERY_CHARGING which triggers the parole state
will only be sent if the level is > 90.
Change-Id: I1073e473c27eb5d29744f4a967771392729b4e1a
Fixes:80534062
Test: Verified that updating the level activates the parole mode.
AppStandbyController is now listening to BatteryManager.ACTION_CHARGING
for starting parole state and this broadcast won't be sent immediately
after plugging in the device. So, update the charging status too which is
going to trigger this broadcast and parole state can be started
immediately.
Bug: 80109076
Test: cts-tradefed run singleCommand cts-dev -m CtsHostsideNetworkTests -t \
com.android.cts.net.HostsideRestrictBackgroundNetworkTests
Change-Id: I6f19f7a509ec48e96eaea4b188262d5a9735edf1
If appStandby is not enabled, then
testAppIdleAndBatterySaver_tempPowerSaveWhitelists is not supported.
Fixes: 79942156
Test: cts-tradefed run singleCommand cts-dev -m CtsHostsideNetworkTests -t \
com.android.cts.net.HostsideRestrictBackgroundNetworkTests
Change-Id: I2f4012ff2cf42481e089d7fc33930258e501ddbf
Add checks to validate that the reported number of measurements and
of successes is reasonable: non-zero for successful results.
Bug: 79879905
Test: 'atest WifiRttTest' passes
Change-Id: Ie79b10edacb660dd8c5d116539a4ee5cc32a779d
Update CTS to select a test AP:
- Scan for APs
- Select the APs supporting IEEE 802.11mc
- Pick the AP with the highest RSSI
Bug: 74518964
Test: atest WifiRttTest (and pick the CTS test)
Change-Id: I6467c75eedcc8260703d2a99214154c9e888cce9
This reverts commit 47d58e2a69.
The revert restores the older method of test AP selction: hard
code the name of the test AP. Subsequent CLs will update to
preferred test AP selection method.
Bug: 74518964
Test: atest WifiRttTest (with rest of CL stack)
Change-Id: Iab71978607aeaf37babdb1afdaeca5c114ccdbf7
Tests need the parole state to get started immediately after device
starts charging, so update stable_charging_threshold constant to 0.
Also simplify the logic to update the global setting as the tests only rely
on a couple of constants.
Fixes: 79319040
Test: Test: cts-tradefed run singleCommand cts-dev -m CtsHostsideNetworkTests -t \
com.android.cts.net.HostsideRestrictBackgroundNetworkTests
Change-Id: Ie9ef67bb1544dd0179980d537365d13e6b6020c1
Now that WifiService can/will support dual simultaneous mode operation, make
sure the tests allow for it as well.
Bug: 31346104
Test: atest android.net.wifi.cts
Change-Id: Id3aaacb3651568c18850a0fdf3832c0f52218cf2
The libcutls library is no longer directly writing to the xt_qtaguid
module proc file. Instead, all the qtaguid related helper function is
moved to libqtaguid in P release. So the cts should directly call into
libqtaguid instead of using libcutils to do that, otherwise it will
faill on devices that using new traffic stats tools.
Bug: 78788976
Test: atest CtsNativeNetTestCases
Change-Id: I1169f598b6e558acf1d7724416b2b70abe2f5878
Merged-In: I1169f598b6e558acf1d7724416b2b70abe2f5878
(cherry picked from aosp commit 7d9870466bc5d57769fccf43ec3d1b2716f54b81)
Addition of eBPF requires tweaks regarding packet counting of
UDP-encapsulated-ESP packet bytes. This patch conditions the expected
number of bytes received based on eBPF being enabled
Bug: 74113670
Test: Ran CTS tests, passing on 3.18, 4.4, 4.9 kernels
Merged-In: If02a4bb6ebfdf949fdb58b5816aa9d252d9eef52
Change-Id: If02a4bb6ebfdf949fdb58b5816aa9d252d9eef52
(cherry picked from commit e061f54d7215729309e9e977743f5b28813878b0)
When wifi location scans are off, the scan is expected to fail. But,
WifiManager.getScanResults() could still return results from the last
scan. This was causing the test to fail because it was relying on
|mScanResults| being null to detect scan failure.
Also, changed the scan done internal state name in the test to more accurately
reflect that scan has been completed (could be success or failure).
Bug: 77601152
Test: Ran `atest android.net.wifi.cts.WifiManagerTest#
testWifiManagerScanWhenWifiOffLocationTurnedOn` with location turned on,
but wifi scans turned off.
Change-Id: I6d5203a836d86d03fbb8e9af0035fe951a6b9db8
This may not be true on all platforms (Android wear for example don't
want to support this functionality)
Bug: 78242827
Test: atest android.net.wifi.cts
Change-Id: I73ab8cd31a9b4a29bd47f8e47957c921a0b16fa3
