X509TrustManagerExtensionsTest used internal implementation details to
test X509TrustManagerExtensions#isUserAddedCertificate, these
implementation details are no longer the same and so this test failed to
catch the API being broken and then incorrectly flagged the fixed API as
broken.
To ensure that isUserAddedCertificate is properly covered the tests for
the API are split into two places: X509TrustManagerExtensionsTest covers
tests for the default case where there are no added CAs and
CaCertManagementTest to test the behavior when CAs have been added.
Bug:28262103
Change-Id: I14f3211c277fdc9c8bfc3d4ac932be375961fa28
- 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
Some partner test networks connect by VPN and if the connection
fails during the testing this test will fail as the local internet
provider intercepts the DNS request and returns an ipv4 address.
Added a message to check the network configuration and rerun the test.
Bug: 26560000
Change-Id: I54e4976b2cef549bfe9fd55ff9609ba2e6513239
This adds one more assert statement to ensure the ScanResult
variable is not null before we proceed.
Bug: 27744749
TEST=run cts test without error
Change-Id: I48f3c5369792d3a55b594b71250b0dfdf0d5282b
There is nothing in the WifiWatchdog test that supports the
assumption that the device under test is pre-configured with a
working WiFi network configuration. This CL makes it possible
from the test stack trace whether the test failed at the
beginning or during the reconnections.
Bug: 27638295
Change-Id: Iff1bd398c74076fb1a969741818562ea582e868e
Wifi framework only enables a network if it is going to connect to it
which is not the case when 'disableOthers' flag is false.
BUG: 27567420
Change-Id: I45d39f4f8efebd7e19fd0bcf5bd97a68d08217ee
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
