Vpn test would destroy socket. If adb run over network, adb
socket would be killed during Vpn test. Then, test stop due to
adb disconnect.
Bug: 119382723
Bug: 135225500
Bug: 126645908
Test: Just cherry-pick with conflict fix
Change-Id: I91b4ab018a9e7fc73dcb7969e4a6520d6b27d629
Merged-In: I91b4ab018a9e7fc73dcb7969e4a6520d6b27d629
Merged-In: Id6f986aacc3cadf713ebbc8305ca535b861390fc
(cherry picked from commit de0f268f78)
WiFi is not a CDD requirement so these tests should not fail when the
device under test does not have WiFi. The behavior is changed so that if
there is WiFi then both metered and unmetered tests will run. If there
is no WiFi and the current connection is metered then only metered tests
will run. If there is no WiFi and the current connection is not metered
then only unmetered tests will run.
Test: Successfully ran CTS test on both emulator and shamu.
BUG: 31648368
Change-Id: Ic643d2490e0a7e69b57a44599f1a4c57c67da873
Symptom: It should be more reasonable to control battery saver function from setting DB instead of plugging/unplugging charger for “CtsHostsideNetworkTests” test case.
Root Cause: The test function “setBatterySaverMode” of “CtsHostsideNetworkTests” use command to set setting DB when trying to turn on battery saver. But while trying to turn off battery saver, it only use charger plug-in event. It should be more reasonable to turn off battery saver through similar DB setting as this function did at turning on.
Solution: To control battery saver function from setting DB.
Project:
Note:
Test done by RD:
Futher testing need Q team's support:
Bug: 31897608
Change-Id: Id70ba458e85f98393d7652bb4e79bd182172c60f
Since Linux kernel 4.2, net.ipv6.auto_flowlabels is set by default, and
therefore the request and reply may have different IPv6 flow label.
Bug: 31444338
Test: On a kernel 4.4 board, run com.android.cts.net.HostsideNetworkTests#testVpn
Test: On a kernel 3.18 board, run echo 1 > /proc/sys/net/ipv6/auto_flowlabels, then
com.android.cts.net.HostsideNetworkTests#testVpn
Change-Id: I913bbf91574239a24cb32ae908834eb951ea2010
It cannot use google.com because it's blocked in some countries where
CTS tests are run.
BUG: 29082308
Change-Id: I749659ec2cd33248fddbe5b4ab02bd6e90f24a67
- Tests what happens on foreground applications when a restriction (like
Data Saver or Battery Saver modes) is turned on (prior tests would
turn the restriction on *before* switching the app to foreground).
- Tests multiple restrictions simultaneously enabled.
Also improved existing code:
- Fixed background state check.
- Reused some common checks in helper methods.
- Retries checks for process state.
BUG: 28473659
Change-Id: Ifcf9cc6d895ccde0ab5177f9f5d8c347ce53b811
There are known issues that cause these check to fail, and the fix has
not been submitted yet.
BUG: 28473659
BUG: 28521946
Change-Id: I26dfbebc2d07396ef89ac78230645e4791c708ee
Also fixed code that checks for whitelist uids, otherwise it would pass
when the required uid is missing but a superset was present (for
example, when asking for 1009 but 10090 was whitelisted).
BUG: 28431507
Change-Id: Iaaa67e586907dba215496460445ad627ba7b63c5
- On hostside, checks if wi-fi is on instead of checking for connectivity (which can be very slow).
- Don't automatically reset metered network on superclass' tearDown().
- Make sure tearDown() cleans up all state changes.
BUG: 27808364
Change-Id: I4818047c5fb8f6f430b0aab5ecfa77717f860db3
When running the device-site tests, it's necessary to share state
between a second app and the main test app. Currently that's achieved
through a shared preference file that is accessed by both apps (since
they use a shared id), but this approach will not work on power save
mode tests (because the test app will be in foreground and the
background restrictions won't be applied in the second app).
This change refactors the data sharing mechanism by:
- Using an ordered broadcast that is sent from the test app to the
secondary app.
- Checking for the network status in the secondary app.
- Moving the test logic to the client-side tests.
BUG: 27127112
Change-Id: I44987701b908b329fdf40e3a7a97e9f30cfadecb
Previously NMPS was broadcasting an intent every time
add|removeRestrictBackgroundWhitelistedUid() was called, but that
behavior has been changed to just broadcast an intent when there is a
change.
BUG: 26685616
Change-Id: I4eb7a4fda864a28ea23b661d1a88e18bfb80533d
The current approach assumes that if the active network is null it is
blocked for background access, but that's not the case.
BUG: 26685616
Change-Id: Ic6990037a2bc503c14512d7303ec71eb178f784b
Initially HostsideNetworkTests.java was used to just launch VpnTest, but
it became more complex with the inclusion of ConnectivityManagerTest,
which required hostside logic.
By splitting these tests not only the VPN tests will run faster (since it
doesn't need the setup/clean from ConnectivityManager), but the
ConnectivityManager tests will be cleaner (since it can have more logic
on setup and teardown).
BUG: 26685616
Change-Id: Ie29c4a3e83956b217d90b84c9b4541690cde0344
This is a no-op change that will make it easier to split the
HostsideNetworkTestCase.java logic into multiple files.
In this change, HostsideNetworkTests.java was renamed to
HostsideNetworkTestCase.java and copied as-is to
HostsideRestrictBackgroundNetworkTests.java; the next change will split
the logic in between these class so they can be properly git-diffed.
In fact, the only difference between then is the class declarations:
diff HostsideNetworkTestCase.java HostsideRestrictBackgroundNetworkTests.java
39c39
< abstract class HostsideNetworkTestCase extends DeviceTestCase implements IAbiReceiver,
---
> public class HostsideRestrictBackgroundNetworkTests extends DeviceTestCase implements IAbiReceiver,
BUG: 26685616
Change-Id: I87dadec528eaeff776d55d3382f356066496429a
