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
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
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
