Some previous setup steps were implemented in NsdManager test cases
hence we couldn't reuse them in Thread test cases. aosp/3377549
introduced more methods in TestableNetworkAgent class which we could use
to get unify the behavior and reduce redundant code.
Not sure if this can deflake the integration test cases.
Bug: 338061061
Change-Id: I6b4542505ec80bf06b736fecbbe7d6901d27cbc4
This is for reduce the overall time of the ThreadNetworkIntegrationTests
which now runs twice for both BR and non-BR cases
Bug: 403360961
Bug: 402480982
Change-Id: Ifa80b8e8885ed980064f92100ef817f9f62b4dc2
Because some APIs in RealtimeScheduler are higher than the min
SDK version for the standalone MDNS build, an abstract class is
required to allow the standalone MDNS build to pass.
Bug: 366373064
Test: atest FrameworksNetTests NsdManagerTest
m service-connectivity-mdns-standalone-build-test
Change-Id: I0b3ac7b4f8dfceeb3dd81e6a5f368b5d57927c41
This provides more accurate delay callbacks, thereby enhancing
the executor's overall functionality.
Bug: 366373064
Test: atest FrameworksNetTests NsdManagerTest
Change-Id: I903851464a92427b6e256573d693bb89a96d013f
failureEnablingIpForwarding verifies that TetheringMetrics sends one
more error report than it should. This extra verification is caused by
any(class) being passed into the mock WifiManager.startTetheredHotspot,
which does not match null even though the actual code passes in a
null. This results in an extra failure that causes the extra error
report call.
Fix this by replacing any(class) with null, and removing the extra error
verification.
Bug: 216524590
Test: atest TetheringTest
Change-Id: I93986a999d573a186696e54793563e2be8405f39
Quang Anh Luongcommited 2025-03-15 10:42:22 +09:00
There are currently two variants of checkAndNotifyCommonError that do
the exactly the same thing, except one uses IIntResultListener and
another uses ResultReceiver. Remove the lesser-used ResultReceiver
variant and just use the IIntResultListener instead (with a
IIntResultListener wrapper for the ResultReceiver).
Bug: 216524590
Test: covered by existing tests
Change-Id: I292a96b32cd975852a52c7953b03bcb35728db24
Quang Anh Luongcommited 2025-03-14 15:27:49 +09:00
The intent is to remove the queue on the NetworkAgent side.
This queue is triggered with the same conditions as the
existing one.
Test: ConnectivityCoverageTests, CtsNetTests
Change-Id: I4bc29b10e48e13cdf3c3a8a15a7c8d15954d2457
Registration is marked by the creation of the network monitor
for a given network agent. This patch makes this fact much
more ovbious.
Test: CtsNetTests ConnectivityCoverageTests
Change-Id: I94a56b2bce6f453322b1eb91d6a6f14b31e7a95f
This is a resubmit of
I0fd90716b9f5501bdcdc7ee5165321737a0076ae
which did not account for testing of this private method
in Telephony tests.
Also make the network agent registry two way to eliminate
reordering possibilities.
Test: ConnectivityCoverageTest, CtsNetTests
Change-Id: I9ca025b1369dcb1202f906d5cff79e3d935b40da
This is a trick to help mocking registerNetworkAgent without
having to import its return type. In the near future the
return type will be changed to a non-public class, which
can't be seen in CTS.
Really this shouldn't be necessary because only Connectivity
tests should mock ConnectivityManager, but the practice is
different and other mockers need this support.
See also aosp/3538922
Test: NetworkAgentTest
Change-Id: I3ac63d95d3830a3b413f9ad12b84ac426b63dd08
This commit adds yuyanghuang@ to the OWNERS_core_networking_xts file,
specifically for APF firmware tests that verify the correct behavior of
the Wi-Fi APF interpreter.
Test: TH
Change-Id: Ifa0243f342a7844bd06f0e42ba09f16e3bf34058
Revert submission 3527440
Reason for revert: Droidmonitor created revert due to b/403261952. Will be verifying through ABTD before submission.
Reverted changes: /q/submissionid:3527440
Change-Id: Ife596c639899528778f53fef797749fa88596dd6
Revert submission 3527440
Reason for revert: Droidmonitor created revert due to b/403261952. Will be verifying through ABTD before submission.
Reverted changes: /q/submissionid:3527440
Change-Id: I31ae861d5151c9db7e559ba19db7f07c9545d422
Priyanka Advani (xWF)authored and Gerrit Code Reviewcommited 2025-03-13 10:22:16 -07:00
Adding mechanism to track interaface name to interface index, this map
would be used by BpfNetMaps for storing interface index.
Bug: 400681214
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.connectivity.InterfaceTrackerTest
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.BpfNetMapsTest
Change-Id: I2a65cac908d9c4d10714e3fe26be20322d4a1db3
Introduce Ping4 offload support for improved APFv6 multi-device testing.
Adds a decorator to restrict tests to Android B+ capable client device.
Test: m connectivity_multi_devices_snippet && atest CtsConnectivityMultiDevicesTestCases
Change-Id: I01909c1725ba471726223deef325c3f0a80b5c14
The nsd_cached_services_removal flag has been successfully rolled
out to the public stage on Pixel devices and has significantly
improved the Nearby connection success rate. Consequently, this
flag should be enabled by default with a kill switch, allowing
the feature to be deployed to all production devices.
Bug: 352629221
Test: atest ConnectivityCoverageTests NsdManagerTest
Change-Id: Ib37b94d729e4d9a8da6f3e574bf149141ebe4a56
This is to avoid applications uses Aloc address for source address which
would cause issues when there are multiple devices sharing the same
Aloc.
Bug: 396019291
Change-Id: I287007ddecd9d0fa2ac8da92f4de691e7844b259
stopTethering with a TetheringRequest should only stop tethering if
there is an existing request (pending or serving) that fuzzy-matches the
input and whose UID matches the caller (unless the caller is Settings,
which is allowed to remove any request).
If there is no existing fuzzy-matched request, return
TETHER_ERROR_UNKNOWN_REQUEST.
Bug: 216524590
Test: atest TetheringTest RequestTrackerTest TetheringManagerTest
Change-Id: Ia8a8eab78fbecd38321fd0d48734855cff16febb
Quang Anh Luongcommited 2025-03-13 12:49:08 +09:00
Legacy behavior will return success results to multiple startTethering
calls of the same type, even though the link layer can only support one
of those requests at a time (other than tethered AP + LOHS).
For B+, clean up this behavior by only allowing the amount of requests
that the link layer can concurrently support. To do this, we'll
introduce the concept of "fuzzy-matching" such that if a new request
fuzzy-matches an existing request (either pending or serving), this
indicates that the link layer cannot support the new request
concurrently, and we'll fail the new request with
TETHER_ERROR_DUPLICATE_REQUEST.
To keep track of serving requests, we'll store the request and it's
IpServer in RequestTracker when we call IpServer.enable(), and we'll
remove it (indexed by IpServer) when
1) Calling IpServer.onStop()
2) Calling IpServer.unwanted()
3) We detect an IpServer transition to AvailableState with error code
Bug: 216524590
Test: atest TetheringTest RequestTrackerTest TetheringManagerTest
Change-Id: I1e193f3595a48f806fb70fd08630a12ce2631a59
Quang Anh Luongcommited 2025-03-13 11:11:17 +09:00
This rtnl message is used with sendOneShotKernelMessage() which expects
that kernel returns an ACK. We need to set NLM_F_ACK explicitly for
that.
Bug: 379021505
Test: Manually run and no more exception with EAGAIN.
Change-Id: Iba21fedf60f5eca63eceee9362e252952bb805c1
The JNI libs that this target depends on are going to be shimmed on top
of ToT and Stable Cronet. This reduces the number of cross-repo dependencies, making that change simpler (see http://aosp/3507996).
Test: m
Bug: b:396593141
Change-Id: I5e8ab89ea0ebe6a82f006568f30961dcf2f0603e
When checking for trel services published by a BR, we need to filter the
services by their service name, since there might be other devices
publishing trel service at the same time.
Bug: 399518677
Change-Id: I56518dbe6c79b48aa048073d8556a53e1261e8bd
This reverts commit 70ede3260c.
Reason for revert: Likely culprit for b/402365566 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Change-Id: If72cc264c5e505348309c6c11dbbfd11adeaf31b
Chaitanya Cheemala (xWF)authored and Gerrit Code Reviewcommited 2025-03-11 06:05:49 -07:00
1. We don't need to assert that ThreadNetworkManager is always null
when the Thread hardware features are not present. There can be more
useful Thread features which don't require the hardware
2. The getAllThreadNetworkControllers() API has no documentation says
the returned list is guaranteed not empty.
Change-Id: Ie77110067ff670053a2125b30b2791b9f54b2582
Handa Wang
authored and
Gerrit Code Review
commited 
Treehugger Robot
authored and
Kangping Dong
commited 
Jean Chalard
authored and
Paul Hu
commited 
Quang Luong
authored and
Sandro Montanari
commited 
Stefano Duo
authored and
Yuyang Huang
authored and
Chuwei He
authored and
Sarup Dalwani
authored and
Maciej Żenczykowski
authored and
Priyanka Advani (xWF)
authored and
Jimi Chen
commited 
Junyu Lai
authored and
Yang Sun
commited 
Remi NGUYEN VAN
authored and
Chaitanya Cheemala (xWF)
authored and