summaryrefslogtreecommitdiff
path: root/tests/cts/net/util/java
Commit message (Collapse)AuthorAgeFilesLines
* Verify converting to Vpnprofile with IkeTunnelConnectionParams setchiachangwang2022-09-201-0/+6
| | | | | | | | | | | | | Add test to verify converting Ikev2VpnProfile to Vpnprofile with IkeTunnelConnectionParams set. Some fields like server should not be set since the information should contain in the assigned IkeTunnelConnectionParams. Bug: 243718982 Test: atest FrameworksNetTests Change-Id: Ie019ea98932a6d079f213e3bff45f21b44d3fa4e (cherry picked from commit 4e953f63dd419fa7793d07857bcb281a499654f6) Merged-In: Ie019ea98932a6d079f213e3bff45f21b44d3fa4e
* Test Ikev2VpnProfile provisioned with IkeTunnelConnectionParamschiachangwang2022-04-211-30/+59
| | | | | | Bug: 223841137 Test: atest CtsNetTestCases FrameworksNetTests Change-Id: I683f6242e4ed4a469893e3a17fe7b479a7a768e5
* Add test for Ikev2VpnProfile.getIkeTunnelConnectionParamsChiachang Wang2022-03-301-0/+59
| | | | | | | Bug: 226628416 Test: atest ctsNetTestCases Test: atest CtsNetTestCasesLatestSdk in R/Q Change-Id: Ie8f589f687946c863e1c2fd2afdf6665c719e581
* Caps callback should be called when underlying networks are changedlucaslin2022-01-041-0/+6
| | | | | | | | | Add a test to check if onCapabilitiesChanged will be called when the underlying networks are changed. Bug: 191918368 Test: atest CtsHostsideNetworkTests:HostsideVpnTests Change-Id: I8dfb16e01199d41b1b65f69e129ec40e37f9ab0f
* Flake fix : Wait setting applied before returning from setConfigChalard Jean2021-11-301-0/+1
| | | | | Test: DnsResolverTest Change-Id: I2e8d487a736d84ab37caf5a9aa95751ddd383588
* Fix a possible flake in disconnectFromWiFiChalard Jean2021-11-151-3/+9
| | | | | | | | | | | | 1. There is a theoretical issue where the callback is not yet registered when wifi is disabled, but there is no evidence of it actually happening 2. 2 minutes timeout makes no sense for these tests that have a total 1 minute timeout anyway Bug: 196387278 Test: CtsNetTestCases Change-Id: I120af9b312ca34431d0e62dd85233fcdaa1b09b9
* Use ConnectivityCheckTargetPreparer in CTSRemi NGUYEN VAN2021-10-281-170/+5
| | | | | | | | | | | | | | | | The preparer does basic checks for device configuration before any test is run, so that wrong device configuration can be identified at the module level, rather than fail individual test cases. If test devices are not properly configured with a wifi configuration and data-enabled SIM cards, the run will fail before starting the test module. As the preparer uses much of CtsNetUtils code for connecting to wifi, refactor that code out of CtsNetUtils. Test: atest CtsNetCasesLatestSdk Change-Id: I1214b6d6916e836bcd68d15c50486092c7fb9a6e
* Restore private dns host name after testingChiachang Wang2021-09-301-0/+3
| | | | | | | | | | | | | | The helper method in CtsNetUtils will not restore the private dns hostname back if the device private dns mode is not strict mode. It does not cause function break since the host configuration is useful only when the private dns mode is in strict mode. But tests should restore the setting back to its old state to prevent break other tests or erase setttings. Test: atest android.net.cts.ConnectivityManagerTest and check if the private dns server configuration is changed or not after testing Change-Id: I7c85ddac7306c7c3eeac84679d96c4cfb11bd875
* Merge "Deflake test to ensure system default network as expected"Chiachang Wang2021-07-201-1/+27
|\
| * Deflake test to ensure system default network as expectedChiachang Wang2021-07-191-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CtsNetUtils.toggleWifi() expects to receive a CONNECTIVITY_ACTION broadcast after disconnecting from wifi if wifi is enabled. The wifi may be connected but not validated since wifi just turns back to connected from the previous test. In this case, the system default netwok will not be wifi, so there is no CONNECTIVITY_ACTION broadcast after disconnecting wifi. It should ensure the wifi is system default network first before proceeding with other verifications. Bug: 192213759 Test: atest CtsNetTestCases --iterations 20 Change-Id: I82f0634883362e35b88854aae28e61b75a3cd7cc
* | Wait for next network in waitForAvailableRemi NGUYEN VAN2021-07-141-5/+21
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tests using CtsNetUtils.TestNetworkCallback would generally assume that waitForAvailable would return a non-null Network if onAvailable was called after it was registered. However this is not true if a network was available, then lost before waitForAvailable is called. This can typically happen if wifi was disconnected just before calling ensureWifiConnected (so wifi is being toggled). In case onUnavailable was called, always wait for the next onAvailable callback, so that waitForAvailable always waits for a network to be available. So: Old behavior: 1) registerNetworkCallback called 2) onAvailable called 3) onLost called 4) waitForAvailable called -> returns null immediately 5) onAvailable called -> unused New behavior: 1) registerNetworkCallback called 2) onAvailable called 3) onLost called 4) waitForAvailable called -> blocks 5) onAvailable called -> waitForAvailable returns the network Bug: 190913510 Test: atest CtsNetTestCases Change-Id: I6bde82ad787371ecffd6caa950b52d90a29ab20b
* Add retries for WifiManager#connectRemi NGUYEN VAN2021-07-061-14/+39
| | | | | | | | | | | | | Connect can error with BUSY if the framework is busy when connect is called. Add retries so that if this happens, the connection can succeed after the framework stops being busy. Also log the level of scan results when several configurations are available, and clarify the legacy broadcast assert. Bug: 188077861 Test: atest CtsNetTestCases Change-Id: I99ce72bd2604489cb419ea9984643b6985728461
* Use WifiManager.connect to reconnect wifiRemi NGUYEN VAN2021-07-061-28/+37
| | | | | | | | | | | | | Address a TODO to use WifiManager#connect to reconnect wifi, instead of WifiManager#reconnect. #connect also clears the BSSID denylist; that list has caused flakyness due to tests that cause the network not to validate such as captive portal or invalid private DNS behavior tests, causing wifi to ignore the access point in reconnect attempts. Bug: 188077861 Test: atest CtsNetTestCasesLatestSdk Change-Id: I5a11a802db8a4881c161e6038c1c183d2ac23a05
* Fix ConnectivityManagerTest initialization on QRemi NGUYEN VAN2021-06-281-6/+4
| | | | | | | | | | | | | | | | | The test can't have TetheringManager as an argument to methods or a field, otherwise the test runner will crash when scanning the class for tests because TetheringManager did not exist in Q. Although testFactoryReset is already skipped on Q, the test runner would fail at initialization time, before starting the run. Use CtsTetheringUtils instead. This ensures that TetheringManager does not have method signatures or members that reference classes that do not exist on Q, so the test runner can scan the class successfully before starting the run. Bug: 188851796 Test: atest ConnectivityManagerTest on Q Change-Id: I87488d0f23628a1ef2d7af0242513fcc5401d598
* Call ConnectivitySettingsUtils to set/get private DNS related settingslucaslin2021-06-211-41/+46
| | | | | | | | | | | ConnectivitySettingsManager and CtsNetUtils are doing the same thing to set/get private DNS related settings. To prevent making the duplication code in two places, move the body to frameworks/libs/net and call it. Bug: 185311744 Test: atest CtsNetTestCases CtsNetTestCasesLatestSdk Change-Id: I3272c825b86ec30c3d0bf4097088c653e668461b
* Merge "Improve handling of invalid private DNS settings"Treehugger Robot2021-06-091-3/+5
|\
| * Improve handling of invalid private DNS settingsRemi NGUYEN VAN2021-06-091-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | When private DNS mode is strict, there should always be a private DNS specifier with the hostname. Instead of restoring an invalid strict mode setting when set, have tests reset private DNS mode to opportunistic and fail. Bug: 190465704 Test: atest CtsNetTestCases Change-Id: I45adc527267aa86d52e824f426699c5a7e874f63
* | Merge "Fix restorePrivateDnsSetting with null hostnames"Treehugger Robot2021-06-091-7/+14
|\|
| * Fix restorePrivateDnsSetting with null hostnamesRemi NGUYEN VAN2021-06-081-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | When private DNS setting was set to opportunistic (mode) and null (hostname), CtsNetUtils would not restore it. Make sure that private DNS settings are restored after every test. Also fail if restore is called without having saved any setting beforehand. Bug: 190465704 Test: atest CtsNetTestCases Change-Id: Ic5d8d8b729469e0eef89a0b53f166e604264c1ee
* | Merge changes I00d1aa47,Icffbe67fYan Yan2021-06-081-3/+2
|\ \ | |/ |/| | | | | | | * changes: Add CTS for AES-CMAC Add tests for new IPsec algorithms in IpSecManagerTest
| * Add tests for new IPsec algorithms in IpSecManagerTestYan Yan2021-06-071-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL adds CTS tests that: - Verify IpSecAlgorithm#getSupportedAlgorithms - Verify new algorithms are supported in device that first launched with SDK beyond R - Verify IpSecTransforms can be built with new algortihms and traffic flows Since there is no hardware that first launched with SDK beyond R at the time of writing this CL, tests for new algorithms were manually enabled and verified on the pixel with an updated kernel. Bug: 171083832 Test: atest IpSecManagerTest Change-Id: Icffbe67fca29b051457dbf863ba3aaf653806a83
* | Correct the logic for CtsTetheringUtils.isWifiTetheringSupportedChiachang Wang2021-06-011-16/+21
|/ | | | | | | | | | | | The existing isWifiTetheringSupported only check if tethering side supports wifi tethering or not but not wifi side. A expected behavior should include both of them, so add the wifi side check into the helper function. Also update in the existing caller side due to a new parameter added. Bug: 186061922 Test: atest MtsTetheringTestLatestSdk Change-Id: Id69ac1d30ab2bbf23e870193335b139f54672636
* Test tethered callback with TetheringInterfacemarkchien2021-06-011-39/+112
| | | | | | | | | | | | | | | 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 Merged-In: I2a0b8c43fb340c3eaed7f0f90464199222a24280 Change-Id: I2a0b8c43fb340c3eaed7f0f90464199222a24280
* Define PRIVATE_DNS_MODE_OPPORTUNISTIC locallylucaslin2021-05-051-1/+1
| | | | | | | | | | | | | 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 Merged-In: Iafcd861714d8aca44cede658ed630f9d5afd5e59 (Cherry-picked from ag/14232792)
* Remove buggy ConnectivityManagerTest#ensureWifiConnected.Lorenzo Colitti2021-02-101-3/+3
| | | | | | | | | | | 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
* Use ACCESS_WIFI_STATE when clearing wifi blacklistRemi NGUYEN VAN2020-11-061-1/+2
| | | | | | | | | | 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
* Fix minor bug and deflaky for DnsResolverTestLuke Huang2020-11-041-1/+1
| | | | | | | | | | | | 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
* Merge "Don't run hotspot related tests if Soft AP is not supported"Treehugger Robot2020-10-291-0/+50
|\
| * Don't run hotspot related tests if Soft AP is not supportedmarkchien2020-10-291-0/+50
| | | | | | | | | | | | | | | | | | | | | | 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
* | Wait for connect before dropping permissionsRemi NGUYEN VAN2020-10-221-10/+31
|/ | | | | | | | | | | | | | | | | 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
* Migrate Tethering util functions to CtsTetheringUtilsmarkchien2020-10-161-0/+397
| | | | | | | | Bug: 166057846 Bug: 170265597 Test: atest MtsTetheringTest atest CtsTetheringTest Change-Id: I59d529cb50b4b6cdafc6be78ad61a55ee1be0404
* Auto-configure wifi on virtual devicesRemi NGUYEN VAN2020-07-161-10/+97
| | | | | | | | | | | | | | | | | | | | | | 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
* Toggle wifi when running CaptivePortalTestTreehugger Robot2020-06-161-7/+76
| | | | | | | | | | | | | | | | | | | | 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
* Fix CtsNetUtils connectTo/disconnectFromWifiTreehugger Robot2020-06-041-9/+29
| | | | | | | | | | | | | | | | 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
* Extract IPsec and test network utility methodsBenedict Wong2020-05-291-0/+54
| | | | | | | | | | | 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)
* Deflaky test for DnsResolverTestLuke Huang2020-05-261-6/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* Revert "Fix flaky test for DnsResolverTest"Luke Huang2020-05-191-47/+6
| | | | | | | | | | | | | 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)
* Fix flaky test for DnsResolverTestLuke Huang2020-05-181-6/+47
| | | | | | | | | | | | | | | | | | | | | | | | | 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)
* Force reconnect in connectToWifiRemi NGUYEN VAN2020-04-301-0/+3
| | | | | | | | | | | | | | | 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
* Reduce DnsResolverTest flaky rateLuke Huang2020-02-211-1/+18
| | | | | | | | | | | | 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
* Fix testResNApi in MultinetworkApiTestLuke Huang2019-11-251-0/+19
| | | | | | | | | | | 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
* Fix ConnectivityManagerApi23Test failures and remove duplication.paulhu2019-05-301-0/+353
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
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-15 04:40:05 +0000