After vts-core is renamed to vts, the CTS tests won't be needed in vts
suite.
Bug: 151896491
Test: local build
Exempt-From-Owner-Approval: This CL removes all CTS tests in vts suite,
as vts is renamed to vts10. This CL won't change test logic or behavior.
Change-Id: Idc9e9cc1d1080ff689823671a736bbb78bd7a740
This is to prepare renaming vts to vts10.
Bug: 151896491
Test: local build
Exempt-From-Owner-Approval: This CL adds all tests in vts to a new
suite vts10. vts10 will be the new name of existing vts suite. This CL
won't change test logic or behavior.
Change-Id: Ia9af1fbddc66d3c94976a58c36d274425f1fe461
See build/soong/README.md for more information.
Bug: 122332514
Test: atest CtsHostsideNetworkTests
(same failures as in baseline)
Change-Id: I5b6a22263331b19570b42f156d7ad5d59f8208b4
Currently, due to foreground app will never get blocked by
NetworkPolicyManagerService, so onBlockedStatusChanged cannot be
tested under cts net app.
Thus, listen for network change events in app2 allows subsequent
tests on NetworkCallbacks.
Bug: 118862340
Test: m -j cts
Change-Id: I26ca370fc6ae4dd3f32ce6cf448bae83f3fbfbcc
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
b/62423436.
This CL was generated using the following command:
master/cts$ grep -rl "LOCAL_COMPATIBILITY_SUITE := cts" . | \
xargs sed -i \
's/LOCAL_COMPATIBILITY_SUITE := cts/LOCAL_COMPATIBILITY_SUITE := cts vts/g'
Based on change: d98ea4bc2a
Test: make vts -j32
Verified VTS output contained the CTS test case source code.
Change-Id: Id52ac1639447276171006c33bdfa7b4e6c874745
Adds all the cts tests to general-tests so they can will
be included in the general-tests.zip file.
This cl was generated using the following command:
master/cts$ grep -rl "LOCAL_COMPATIBILITY_SUITE := cts" . | \
xargs sed -i \
's/LOCAL_COMPATIBILITY_SUITE := cts/LOCAL_COMPATIBILITY_SUITE := cts general-tests/g'
Bug: None
Test: make general-tests -j
Change-Id: Idbddf1560a31961cb2e6cab8cf55b55e22ecbbff
In the tests, we check the ouput from "am get-uid-state" command to see
if the app is coming to foreground and check for network access. But the
command gives internal uid state info in AMS and it's possible that the
activity/service is not started yet. Update this behavior so that we check
for network access only after the activity/service is started.
Bug: 27803922
Test: cts-tradefed run singleCommand cts-dev --module CtsHostsideNetworkTests
Change-Id: Ic0d94a585439c1d8629a897a8b56bcbf178a4371
Put an app in standby, make it show a toast and ensure
that it doesn't come out of standby. This is to test
for a bug fix for the same behavior.
Bug: 31544592
Test: cts-tradefed run commandAndExit cts -m CtsHostsideNetworkTests -t com.android.cts.net.HostsideRestrictBackgroundNetworkTests#testAppIdle_toast
Change-Id: I796ecde8e346c308a27969d873e3ce384414fee3
- Retry on all cases (not only when expecting connected).
- Uses exponential back-off for timeout.
BUG: 27803922
Fixes: 30509643
Change-Id: I42454f43158598a72e30f290c27c5a02e80ea6d2
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
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
These tests require a second app (besides the test app) that defines a
service; the host-side test then launches the service whose only purpose
is to define a broadcast receiver, which in turn will count the number
of intents received in a shared preferences file. Then the test app will
read the shared preferences and assert the proper number of intents have
been received.
BUG: 26451391
Change-Id: I4c5d5e57c09a0bd57a7f6581820cc9115318dd47
