- Retry on all cases (not only when expecting connected).
- Uses exponential back-off for timeout.
BUG: 27803922
Fixes: 30509643
Change-Id: I42454f43158598a72e30f290c27c5a02e80ea6d2
- 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
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
Although the main purpose of these change is to test the new public
API (ConnectivityManager.getRestrictBackgroundStatus()), it also
indirectly tests the new private API on
INetworkPolicyManager (addRestrictBackgroundWhitelistedUid(),
removeRestrictBackgroundWhitelistedUid(), and
getRestrictBackgroundWhitelistedUids()), since they're used on each test
to setup the device state.
This change also modified how the device-side tests are run: the
runDeviceTests() had a className parameter that was not used, and this
CL not only uses it but also introduces a methodName as well. The
reasoning for this change is that the host-side tests must interact with
the device-side tests many times during each test; in fact, the "real"
test is done at the host side, while the device-side test is just used
to assert the expected result of getRestrictBackgroundStatus()).
BUG: 26451391
Change-Id: I7114e350f3b247d2f05b0c280a09cad383c61f9a
It is a issue caused by bad test case.
Please ensure the previous vpn connection is disconnected before running next
vpn test case, this will affect the test result.And the CTS test case also
tries to connect socket before the vpn rule is set in netd.
It is the same issue as http://b/18436087 .
The delay 300ms is too short, and recommend extend to 1000 or 3000 ms.
Since L MR1 is known as supporting some low memory device, we suggest fixing
the new CTS test case for some low-end devices.
Change-Id: I6051c95c663e867fc66c580ce8bd8d25fce0b8fc
Signed-off-by: Junjie Hu <junjie.hu@mediatek.com>
This allows developers to build the test packages individually without
needing to build the entire CTS release.
Add new build target for support packages
bug: 18945639
Change-Id: I60b79797b2d254b96aa98f88cfd5b19d195ea982
