The dependency is unnecessary as by default conscrypt
is included in the "standard libraries".
Test: build
Bug: 113148576
Change-Id: I30d68049215c61931bdd7aa5e2a0f125e6d1bf90
Add a much more verbose message for the common failure case in which
the CTS is run without an AP which supports IEEE 802.11mc / RTT. That
may help speed up issue resolution.
Bug: 116849381
Test: atest WifiRttTest
Change-Id: I4ea3fbe17563f0087a013cbf48f7f601fec7e363
Location Wi-Fi scanning should not be turned off when the screen turns off.
Bug: 113876483
Test: Run CTS, manually toggle location Wi-Fi scanning off right after the screen
turns on and observe failure.
Test: Run CTS with location Wi-Fi scanning initially turned off and observe failure.
Test: Run CTS with location Wi-Fi scanning initially turned on and observe
success.
Change-Id: I092a3854b6365de72c2cfe38a55a0e1cedfcabd9
This access is going away for apps. Move these tests to hostside
tests to be executed by the shell domain.
Test: atest cts/hostsidetests/net/src/com/android/cts/net/ProcNetTest.java
Test: atest android.net.cts.ConnectivityManagerTest
Test: atest android.net.cts.IpSecSysctlTest
Test: atest android.net.cts.MultinetworkSysctlTest
Bug: 116053204
Change-Id: Id7e867184dd344a2d877515956e76019d627788b
Test connection->UID resolution for both UDP and TCP connections.
Bug: 9496886
Bug: 109758967
Test: atest HostsideVpnTests
Change-Id: Ic17c64df74f65d788fd3d95a25af3c5b44946881
The shell access to the proc/xt_qtaguid/ctrl file is blocked in next
android release since no apps or users should directly read/write to
those proc files anymore. This CTS test is checking some critical kernel
behavior to make sure the xt_qtaguid module have specific kernel fixes.
So if the ctrl file is not accessible, there is no way to verify those
critical fixes, we can only skipped the test. These testcases are also
added in VTS qtaguid test so we can still check the devices have those
kernel fixes.
Bug: 110906349
Test: atest CtsNativeNetTestCases
Change-Id: Iae0512bb37f8b93577a134f15affb4f2a448be18
The internal UriCodec class is being removed from libcore/ and the
associated CTS tests are being removed. This change adds equivalent
URI decoding tests to the UriTest CTS test class.
Test: make droid && make cts
Test: run cts-dev -m CtsNetTestCases -t android.net.cts.UriTest
Bug: 111055375
Change-Id: Ided15d5abf8478064d193034e84c4dbe0689c6f0
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)
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
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
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
Change-Id: If02a4bb6ebfdf949fdb58b5816aa9d252d9eef52
