The old callback only report interface list, new callback could provide
the mapping of interface and type. Replace old callback usage in cts
with new callback and check whether old callback could get the correct
interface list by comparing the result between old and new callback.
Bug: 162920185
Bug: 152203943
Test: atest CtsTetheringTest on S
atest CtsTetheringTestLatestSdk on R
atest MtsTetheringTestLatestSdk on S and R
Ignore-AOSP-First: Its dependences CL is not in aosp currently.
Change-Id: I2a0b8c43fb340c3eaed7f0f90464199222a24280
The type of ConnectivityManager#PRIVATE_DNS_MODE_OPPORTUNISTIC
has changed from String to int, but the String definition is still
needed to update to Settings.Global.PRIVATE_DNS_MODE, so the
simplest way is to define one locally.
Bug: 185311744
Test: atest CtsNetTestCases
Change-Id: Iafcd861714d8aca44cede658ed630f9d5afd5e59
Ignore-AOSP-First: In the same TOPIC, there is a merge conflict in
DevicePolicyManagerService.java in the internal branch, so it's needed
to merge the code into internal branch to fix the merge conflict.
This method does not behave correctly when wifi is connected but
the last CONNECTIVITY_ACTION broadcast was not for wifi. This
could happen due to another network connecting or disconnecting,
such as VPN.
Bug: 179774433
Test: test-only change
Change-Id: Ib2010b3871133c38b6d508bf508134dd9b814ce2
Some tests using CtsNetUtils, like tethering CTS tests, do not hold
ACCESS_WIFI_STATE at install time. Use shell permissions to allow the
utility to work in such configurations.
Bug: 171621759
Test: atest CtsTetheringTest:TetheringManagerTest
Change-Id: I63e76918421e5deb59fe67a64674348fb8d20265
1. Add the missing countdown() in the test callback
2. Add ensureWifiConnected() to prevent no available network problem.
3. Increase the timeout for awaiting private DNS setting because
current one might not be enough.
Bug: 168027339
Test atest
Change-Id: I91190d8644ff7a7dfaf4fa3f2d43c17f67dfac11
Also explicitly hold ACCESS_WIFI_STATE permission to avoid
no permission problem when using WifiManager#getScanResults
without shell identity.
Fix: 169219565
Test: "atest CtsTetheringTest" in cuttlefish and phyical device
Change-Id: I3d8fa7e8882bf96f61f3316a70efdf991addbcb2
WifiManager#connect is implemented with a oneway binder call, so it may
return before the permission check. The previous code could drop shell
permissions before the check is performed.
Use WifiManager.ActionListener to wait for the operation to end before
dropping permissions.
Also refactor current usages of various "run as shell" utilities to use
TestPermissionUtil.runAsShell, which is the "standard" utility used in
connectivity tests (both in CTS and in other tests).
Bug: 170371191
Test: atest CtsNetTestCasesLatestSdk:CaptivePortalTest
Change-Id: I0f47c455f2c1596a887abab7d35146d8557d736a
At the moment tests run on virtual devices through TEST_MAPPING do not
necessarily have wifi configured to auto-connect to a test SSID.
This could be fixed by adding a TargetPreparer in AndroidTest.xml with a
given SSID, but that configuration would then apply to all runs,
including local ones. There is also no good way to apply a preparer that
configures wifi "if it is not already connected": WifiPreparer in
particular will not configure wifi even if just a mobile network is
active.
Implement auto-configuration in CtsNetUtils#connectToWifi so that if no
network is configured, and a virtual SSID is detected when scanning,
that SSID will be added to the list of configured networks. This allows
addressing the issue until TEST_MAPPING can support configuring wifi,
with minimal side-effects on other runs.
Test: atest CtsNetTestCasesLatestSdk:CaptivePortalTest
Bug: 158153057
Change-Id: I47df4c325b073f8a9bf320894245eed211606952
Instead of reconnecting without disabling/re-enabling wifi in
CaptivePortalTest, actually do the toggle during the test and
on teardown to ensure that the BSSID blacklist is cleared.
CaptivePortalTest intentionally makes the network not validate, which
causes it to be added to the BSSID blacklist. Toggling wifi is necessary
to make sure the test does not affect other tests.
Also check development SDK instead of the exact SDK_INT number so that
the test can pass on current AOSP builds.
Bug: 158924461
Test: atest CtsNetTestCasesLatestSdk:CaptivePortalTest \
CtsNetTestCasesLatestSdk:ConnectivityManagerTest
Original-Change: https://android-review.googlesource.com/1336114
Merged-In: I31f9f4a9678e11042005c29535af840246358764
Change-Id: I31f9f4a9678e11042005c29535af840246358764
connectToWifi needs to clear the wifi networks blacklist before calling
reconnect(), otherwise wifi may not reconnect if the previous network
was blacklisted.
disconnectFromWifi should not wait for a onLost callback if wifi was
already disconnected.
Test: atest CtsNetTestCasesLatestSdk:ConnectivityManagerTest
Test: atest CtsNetApi23TestCases
Bug: 150949391
Original-Change: https://android-review.googlesource.com/1322428
Merged-In: I244b91bdd8708694fce9f10d92b8b6646d28188f
Change-Id: I244b91bdd8708694fce9f10d92b8b6646d28188f
This patch moves some test setup functions to util classes in
preparation for IKEv2 VPN tests which will use those same utilities.
Bug: 148582947
Test: atest IpSecManagerTunnelTest; passing
Change-Id: I9aeafa45ab515ce72a72c3de6f70fb26e32e7fd4
Merged-In: I9aeafa45ab515ce72a72c3de6f70fb26e32e7fd4
(cherry picked from commit 30432fa7640603c1e746b7d8c83e2e6052d8f967)
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)
Merged-In: I224a6493c87cebaf0bf954c2644e2945ccd50db1
Change-Id: Ib61ad7bd510341366ebbbb72aa451e5809ee3e9d
(cherry picked from commit 7561b1499c1b8da0334b32c0452d49113d9e4806)
This reverts commit dd9608b7d1147a4eaf36ea634b9fc2f0feca1145.
Reason for revert: This CL made whole test failed.
Bug: 153624005
Bug: 150952393
Bug: 151122313
Merged-In: I083529616dbf80421ea6a322bb57d2bb0f2bca62
Change-Id: I002c39d6535fb31b13bc463812517fe1882f1884
(cherry picked from commit 98015badd01863fa4a79c089f371d9a50f2ae98c)
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
Merged-In: Iaed6285677f74a5ee6cc6684534ddc0758b25974
Change-Id: I566bdfa98dc070247b52fe29ca1f31cbd1bb8cc2
(cherry picked from commit 877af1ee3ed2c3a9e9256e216709908d2beb3bfb)
There is no guarantee that Wifi will automatically reconnect after
enabling, especially in cases where no internet access was detected on
the access point the last time it was connected.
Use WifiManager#reconnect to force wifi to reconnect to the access
point. The API is deprecated for general use, but system apps are
documented as exempted from the deprecation.
Bug: 152280218
Test: atest --rerun-until-failure 200 CtsNetTestCases:CaptivePortalTest
Merged-In: Ia7d83337ee0ffad9414031711cf7e937b14f968d
Change-Id: Ia7d83337ee0ffad9414031711cf7e937b14f968d
Adjust some timeout value and correct the conditional checking
for private DNS waiting mechanism.
Also move the fail() statement from callback thread to test thread.
It is used to avoid the test process crashing.
Bug: 148471807
Test: atest DnsResolverTest
Change-Id: I244cefeae97fe99838d1c72d867c1d7a1a7d5e87
This test can not pass in T-Mobile Network becauseT-Mobile
has configured their network to return a "search page" when
the user looks up a name that doesn't exist.
Enable private DNS strict mode before doing testResNApi
Bug: 144521720
Test: atest MultinetworkApiTest
Change-Id: I269962a30f224fd434a1915c9b1bf264f20b780c
1. All ConnectivityManagerApi23Test were failed due to
WifiManager#setWifiEnabled doesn't allow to use since
Android Q. So we need to use shell command to enable/disable
Wi-Fi instead.
2. Some methods are duplicated between
ConnectivityManagerApi23Test and ConnectivityManagerTest, but
they are not identical. So put these methods into
ConnectivityUtils to clean up duplications and prevent fork
happened again.
Bug: 133334943
Bug: 133209319
Test: Run the below tests on Crosshatch, Sailfish, Bonito.
atest CtsNetApi23TestCases
atest CtsNetTestCases
Change-Id: Ic37111cb12a46f5c36c2be887250c5d762216f6e
Merged-In: I075b7408d2a1e1145c7a9031075e07fa1db37fed
Merged-In: I0c02357eff07b98c1745de35d08ae6b8349de7fb
Merged-In: I04d1e1d096bcd4a9626cf9f00396fca7f9892a82
