This commit increases the timeout for the
ApfIntegrationTest#testReadWriteProgram() test case from 15 minutes to
20 minutes. This change ensures that the test does not timeout on slower
devices.
Bug: 407721406
Flag: EXEMPT bug fix
Test: TH
Change-Id: I8c2b5d36aebc2f2fa66f2d72cccd88bf74f50b68
ApfIntegrationTest includes test cases that require turning off the
screen and waiting before sending packets. On devices with low power
standby capabilities, such as Android TVs, the packets sent by these CTS
test cases can be blocked. To prevent this interference, this commit
temporarily disables the low power standby policy during test execution.
Bug: 407698167
Flag: EXEMPT bug fix
Test: manually test on TV and Phone
Change-Id: I7312626b4d1939847e5bf5267da5e81dab241a64
And integrate into EthernetManager. So it can make proper use of
PacketBuilderUtils.
Test: TH
Flag: EXEMPT mainline
Bug: 1000001
Change-Id: Ifbca38e6efde68e015c69bf919d079d1605310d1
When MdnsMultinetworkSocketClient stops using a socket (when
isSocketActive starts returning false), the packet handler should be
removed from that socket. The code only removed it from the
mSocketPacketHandlers map without clearing it from the socket.
This caused packets to be handled potentially many times, affecting
performance.
Bug: 406623719
Bug: 408324621
Test: atest
Flag: EXEMPT bugfix
Change-Id: I3d1117a4b847f3b95a01fc8a5997a53655ef608a
Address the TODO to allow tagging sockets, which was done before the
code was imported to the Android codebase.
Also remove the comment in MdnsSocket, as the tagging is already done by
setting the thread tag, and tagSocket in the original code actually did
nothing for DatagramSockets.
The option is unset in the Android repository, so this code is unused
there.
Test: atest
Flag: EXEMPT unused in Android repo
Change-Id: Ifccc4ec2f0b63bf2caabe1d9ef4f57f08731a2b1
The lost callback should be skipped if the service has not been
previously notified. Otherwise, the listener could inadvertently
initiate the service removal process for the incorrect service.
Bug: 387910548
Test: atest ConnectivityCoverageTests NsdManagerTest
Flag: EXEMPT legacy flag nsd_optimized_expired_service_removal
Change-Id: I7fdf31f0b15f19becc10fcb35c7b1f47dcc38c27
This commit introduces a new feature to optimize the removal of
expired services. After the query is sent, a task is scheduled
with a 2-second delay to wait for responses. During this delay,
if a service response is received, the service information is
updated, and the service is removed from the removal list. After
the delay, services that are expired, have sent a query, and for
which the query time was 2 seconds ago are removed, and listeners
are notified.
Bug: 387910548
Test: atest ConnectivityCoverageTests NsdManagerTest
Flag: EXEMPT legacy flag nsd_optimized_expired_service_removal
Change-Id: I498747839664eed8fe5b73a6f6d002deb9167271
Update MdnsServiceCache to enhance its ability to retrieve
responses and manage expired services effectively. Introduce an
argument `excludeExpiredServices` to control whether expired
services should be excluded when retrieving responses. And add a
new method `markExpiredServices` to mark services as expired
based on their TTL and current time.
Bug: 387910548
Test: atest ConnectivityCoverageTests NsdManagerTest
Flag: EXEMPT legacy flag nsd_optimized_expired_service_removal
Change-Id: Ifa30fbe75a72ea400a69ab258d67381a54faf9b5
Updated the MdnsServiceCache to maintain the first query time
after the last update of cached services, allowing for more
accurate expired service management.
Bug: 387910548
Test: atest ConnectivityCoverageTests NsdManagerTest
Flag: EXEMPT legacy flag nsd_optimized_expired_service_removal
Change-Id: I6da0691ece239b3b2e5dc5198a656cf21b30e953
MdnsResponseDecoder flushed all address records when receiving an
address record with the the cache-flush bit is set. However as per
RFC6762 10.2, only records with a matching rrtype should be
flushed, which means that AAAA records should not be flushed when an A
record is received, and vice-versa.
Fix the logic and include a default-on flag to allow turning it off if
needed.
Test: atest
Flag: EXEMPT bugfix
Bug: 407698496
Change-Id: I6142f9996362dd7c16b4e80c8019f0cb1caef174
This is a stopgap to palliate a bad interaction between
ConnectivityService and JobScheduler.
To help developers find request leaks and protect against OOMs
in the system server, ConnectivityService is enforncing a maximum
number of network requests/callbacks per UID. It has a higher
value for system UIDs because some system components need to
file requests on behalf of apps, most prominently JobScheduler.
The count is increased on entry in ConnectivityService, on the
Binder thread ; this is when CS can throw TooManyRequestsException
to the caller, it could not do that later when the request is
actually registered on the handler thread.
Conversely it only decreases the count on the handler thread,
because until then it doesn't know whether the request was
actually registered, and it can't look at that data structure on
the Binder thread.
This leads to a slightly confusing result where a UID can register
a request immediately after it unregisters one, and it will receive
TooManyRequestsException, because the unregister hasn't been
processed yet and the count not decremented yet.
This is arguably a bug, but if your app is treading on that last
request, you almost certainly had a leak anyway, and you should
not be trying to play with the exact count of requests either.
The remaining case is when an app would unregister and register
requests again in a tight loop, but there is no valid use case for
that, right ? Right !?
Enter JobScheduler. Because the limit for system UIDs is 250
requests but there can be more than 250 UIDs (especially on
devices with multiple users), JobScheduler has its own limit of
requests (which is set to 125). It has heuristics to choose which
are the most important 125 UIDs to file requests for.
When the request count exceeds 125, or when something
happens that may change which are the most important 125
UIDs, JobScheduler will re-evaluate which are the most important
ones. Upon doing this, it will unregister all requests and file
again the important ones in a tight loop. At worst, it will
therefore remove 125 requests and add 125 requests again,
taking up at most all 250 requests allowed for system UIDs ;
if the system server has any other request outstanding (and
it does), it may hit the issue where CS doesn't know yet that
requests have been unregistered, and crashes and hilarity ensue.
To palliate the issue above, this patch increases the allowed
request count for system UIDs by 125. This immediately should
fix the issue where all 250 requests are taken up by JobScheduler.
For a long-term fix, we should instead make at least one of the
following fixes :
- Have JobScheduler be smarter, and make sure it only unregisters
the requests that it no longer needs instead of all of them.
- Make CS only throw when the requests are really full, by using
some combination of locking, making the caller wait or similar.
- Have a separate pool of requests for JobScheduler that is
dimensioned so it knows it can file all the necessary requests
and no longer has to limit itself, and simplify the JS code.
Flag: EXEMPT bugfix
Bug: 391114053
Test: ConnectivityServiceTest
Change-Id: I4c4702e2d0c5d03eb5f3d6fe0f1578a210b188e8
This commit enhances the stability of the APFv{4,6} multi-device tests by addressing several sources of flakiness and improving the test setup and validation.
Specifically, this commit:
* Increased sleep time in the test setup. This ensures APF is activated before each test, preventing unexpected behavior.
* Added sleep time in `ApfV4Test` to ensure APF remains enabled and is not disabled due to high throughput scenarios.
* Changed the validation order to first check received packets and then APF counters. This helps to more easily identify the root cause of test failures.
* Changed the Ethernet destination address from multicast to unicast in `ApfV6Test` to prevent packets from being filtered due to DTIM skip.
* Removed the `test_broadcast_arp_request_offload()` test, which was flaky due to DTIM skip and is adequately covered by the `test_unicast_arp_request_offload()` test.
Bug: 406570694
Flag: TEST_ONLY
Test: atest CtsConnectivityMultiDevicesTestCases:ApfV4Test
Test: atest CtsConnectivityMultiDevicesTestCases:ApfV6Test
Test: run cts -m CtsConnectivityMultiDevicesTestCases --skip-preconditions -t ApfV4Test --shard-count 2
Test: run cts -m CtsConnectivityMultiDevicesTestCases --skip-preconditions -t ApfV6Test --shard-count 2
Change-Id: I053509459078d0bd94e16a6bf7349b948f930e6c
Jimi Chenauthored and Yuyang Huangcommited 2025-04-02 04:31:01 -07:00
This exercise tests the flow from WifiP2pManager APIs to the
network callbacks fired by the ConnectivityService, on a
single device.
This change also makes utilities under
com.google.snippet.connectivity into a java library so they
can be reused by other modules.
Flag: TEST_ONLY
Test: m CtsTetheringTest && atest \
CtsTetheringTest:android.tethering.cts.TetheringWifiP2pTest
Bug: 406172997
Change-Id: I32095316a5deadee7acba94c318fee666cd1303d
When using MdnsSocketClient (unused in the platform, may be used as a
library), allow guessing the Network of incoming packets based on their
source address.
This is flawed as there may be races between LinkProperties updates,
interfaces going up/down, and packets being received, and the source
address can not always be mapped 1:1 to an interface prefix, but it
should improve the situation for legacy code that currently assumes the
Network is the last one that was used for sending, which is often wrong.
Test: atest
Flag: EXEMPT: dead code in Android repo
Change-Id: I885c741d3d40b1b128a06b6d7a7aff8e0551ffea
This is hardcoded to true, and there is no use-case for setting it to
false.
Test: atest
Flag: EXEMPT refactor
Change-Id: I1c1b8f8ac4015adfa9900012c576312b5193433a
TetheringManagerTest may fail on T devices in rare cases due to hostapd
hanging. Log the hostapd callstack upon failure in #testStopAllTethering
so we can analyze it the next time the failure happens.
Flag: EXEMPT test-only change
Bug: 299687365
Test: atest TetheringManagerTest
Change-Id: I59ce9dc98be7eb3689dae4863078360534edc802
Quang Anh Luongcommited 2025-04-01 16:49:26 +09:00
Move utility method responseMatchesOptions() to MdnsUtils, where
it can be used by other mDNS classes.
Bug: 387910548
Test: atest ConnectivityCoverageTests NsdManagerTest
Change-Id: Idecd5e7d4c2c4dcf108c42e07a7befd97b68b5a7
Revert submission 3561690-revert-3538339-SNUWWZJNJZ
Reason for revert: NewAPI error will be fixed by separate CL
Reverted changes: /q/submissionid:3561690-revert-3538339-SNUWWZJNJZ
Change-Id: Ia7367e9332f4d376bd0be4c03c095ee00de9177a
The EthernetConfigParser was adding the transportType on top of the
TRANSPORT_ETHERNET of DEFAULT_CAPABILITIES, causing multiple transport
types to be added.
This was causing an IllegalStateException when trying to set the
NetworkSpecifier within the EthernetNetworkFactory.
This only applies for when isAtLeastB && capabilitiesString.equals("*")
is true (as the parsed capability is equal to DEFAULT_CAPABILITIES).
Flag: TEST_ONLY
Bug: 405172885
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.ethernet.EthernetTrackerTest
Change-Id: I6678a52ddc87b8ad66c602c68335f3e2073d7231
Chris Desirauthored and Patrick Rohrcommited 2025-03-26 15:51:04 -07:00
Revert submission 3538339
Reason for revert: Likely culprit for b/406432012 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Reverted changes: /q/submissionid:3538339
Change-Id: I61b02f2b1b667e9a41b677f8062e8e96aac09f6e
QUIC stack running on the app process will call this API and register
QUIC UDP socket and UDP payload that can close QUIC connection.
When the app loses network access (e.g. due to freezer or firewall
chain), ConnectivityService 1)destroys the registered UDP socket by
sending a SOCK_DESTROY netlink message and 2)sends the registered UDP
payload to the server. This prevents unnecessary modem wakeups caused
by packets from the server after the apps lose network access.
Additionally, to close QUIC connection for apps that crash or are
killed, ConnectivityService sends the registered UDP payload when it
receives a socket destroy diag message for the registered socket.
Bug: 311792075
Test: CSDestroySocketTest CtsNetTestCases
Change-Id: I6cd727bd8bb0fe1d17360edfa395f73d24da6920
Maciej Żenczykowski
authored and
Android (Google) Code Review
commited 
Patrick Rohr
commited 
Yuyang Huang
commited 
Treehugger Robot
authored and
Remi NGUYEN VAN
commited 
Jean Chalard
authored and
Xiao Ma
authored and
Paul Hu
commited 
Tomasz Wasilczyk
commited 
Jimi Chen
authored and
Junyu Lai
commited 
Quang Luong
authored and
Automerger Merge Worker
commited 
Gerrit Code Review
commited 
Motomu Utsumi
commited 
Chris Desir
authored and
Chaitanya Cheemala (xWF)
authored and