- Verify that inbound and outbound IpSecTransforms
are created when a Child Session is created
- Verify that when Child Session is deleted,
the IpSecTransform pair is deleted
Bug: 148689509
Test: atest CtsIkeTestCases
Change-Id: If142b3fb2ac791322921beeab1bc8d43db255317
on Q startCaptivePortalApp was guarded by CONNECTIVITY_INTERNAL instead
of NETWORK_SETTINGS: change the permission adopted by shell on Q to
match the platform.
Test: atest CaptivePortalTest on a Q device
Bug: 150904735
Change-Id: I24b6907d164aba07df0f5a1a3715669e99cddd88
- Migrate the test to JUnit4, as JUnit3 cannot use assumeTrue
- Skip IPv4 keepalive tests on networks that do not have native IPv4.
- Refactor usage of adoptShellPermissionIdentity to use try / finally
or runAsShellPermissionIdentity: test failures could lead to
permission failures in other tests due to mismatched adopt/drop.
- Fix ensureWifiConnected to support the "wifi enabled but not fully
connected" case.
Bug: 150949391
Test: atest CtsNetTestCasesLatestSdk:ConnectivityManagerTest \
--rerun-until-failure 50
Change-Id: I7459753b1068e1760a95337760db58d1df213fad
- Add java doc in IkeSessionTestBase about the necessity to use
different addresses and Networks in each test
- Use ArrayTrackRecord in Test Session Callback to retrieve the
latest result.
- Verify that IpSecTransform pair is created and deleted
Bug: 148689509
Test: atest CtsIkeTestCases
Change-Id: Ib747c8cdfe1827e8df2aa7544e28e98a177d3d1c
It's possible that private DNS setting is not in the state we expected
when we tried to enable strict mode during tests. The problem here is
that there are 2 setting Uris(mode and specifier) relating to strict
mode, each of them might trigger private DNS setting changing evnet in
ConnectivityService.
Previously, we tried to enable strict mode with first set private DNS
mode and then private DNS specifier. This may result in 2 consecutive
private DNS changes events with very short intervals, which caused
conflicts between DnsResolver / NetworkMonitor and lead to flaky tests.
So
0. Use opportunistic as default mode if no default mode existed.
1. Change the order (mode and specifier) for enabling strict mode.
2. Change private DNS mode only when needed.
(If original mode is "hostname", then we only need to set
specifier)
Bug: 153624005
Bug: 151122313
Bug: 150952393
Test: atest DnsResolverTest --rerun-until-failure 100
Test: forrest (git_master, cts/networking/gce-all)
Test: forrest (git_rvc-dev, atest CtsNetTestCases)
Test: forrest (git_rvc-dev, mts/dnsresolver/device-all)
Change-Id: I224a6493c87cebaf0bf954c2644e2945ccd50db1
This reverts commit fb735de0e8.
Reason for revert: This CL made whole test failed.
Bug: 153624005
Bug: 150952393
Bug: 151122313
Change-Id: I083529616dbf80421ea6a322bb57d2bb0f2bca62
The CtsNetTestCasesLatestSdk needs to build against platform (for hidden
API access), The JNI library libnativedns_jni used by
CtsNetTestCasesLatestSdk needs to build against stable SDK (for running
on Q). To fulfill the combination, property jni_uses_sdk_apis must be
set.
Bug: 151122313
Bug: 150904735
Bug: 150918852
Test: atest CtsNetTestCasesLatestSdk on R and Q platforms
Change-Id: I5db3cb28829847e74412d270db7d17b81c5e26a2
It's possible that private DNS setting is not in the state we expected
when we tried to enable strict mode during tests. The problem here is
that there are 2 setting Uris(mode and specifier) relating to strict
mode, each of them might trigger private DNS setting changing evnet in
ConnectivityService.
Previously, we tried to enable strict mode with first set private DNS
mode and then private DNS specifier. This may result in 2 consecutive
private DNS changes events with very short intervals, which caused
conflicts between DnsResolver / NetworkMonitor and lead to flaky tests.
So
1. Change the order (mode and specifier) for enabling strict mode.
2. Change private DNS mode only when needed.
(If original mode is "hostname", then we only need to set
specifier)
Bug: 153624005
Bug: 153624702
Test: atest DnsResolverTest --rerun-until-failure 100
Change-Id: Iaed6285677f74a5ee6cc6684534ddc0758b25974
Test will be affected by logic modification from different
NetworkSpecifiers. Since this test tries to test the behavior
of NetworkRequest but not NetworkSpecifier, use local defined
NetworkSpecifier to test to prevent repeating noisy breaks.
Also update test for testing invariant.
Bug: 154451660
Test: atest CtsNetTestCasesLatestSdk:android.net.cts.NetworkRequestTest
Change-Id: I7e357c75a68244432231d59646ddf67c8d969c6d
In R, to avoid data overages due to apps not detecting a
meteredness change, when a wifi network changes from unmetered
to metered the network will go down and will be replaced with a
new network. It will make NetworkCallbackTest fail because the
original design is getting the active network in setUp(). So once
the wifi reconnects, the network which is got in setUp() will be
meaningless and make the test fail due to network mismatches.
The new changes are:
1. Moving some initial pre-configurations into setUp().
2. Override the onCapabilitiesChanged() to check if network has
changed to metered or not.
3. Add unregisterNetworkCallback() into iMyService.aidl so that
NetworkCallbackTest can call it to unregister the network
callback.
4. Enlarge the timeout of connecting network and receiving
callback to prevent network cannot reconnect in time or
callback cannot be received in a short time.
Bug: 153485744
Test: atest CtsHostsideNetworkTests:com.android.cts.net.HostsideNetworkCallbackTests
Change-Id: I1aa0e107cf6797b06dee4a15896c63321d822156
Merged-In: I1aa0e107cf6797b06dee4a15896c63321d822156
This commit:
-Extend TunUtils for processing IKE packets
-Add IkeSessionBaseTest containing common functionality for all IkeSession tests
-Add end-to-end test for IKEv2 PSK verifying creating IKE SA, creating child SAs
and closing sessions
-Add basic tests for error scenarios
Bug: 148689509
Test: atest CtsIkeTestCases
Change-Id: Ie6c18591ffcc883abbf0484d9a59dfda61b33257
