Previously, non VPNs would not be created when updateVpnUids()
is called inside handleRegisterNetworkAgent. Because the network
is not created, netd would refuse to set the UIDs with an error.
Now that networks are created immediately with the
QUEUE_NETWORK_AGENT_EVENTS_IN_SYSTEM_SERVER flag,
the network is created and netd does set the UID for any
network as if they were a VPN. This results in the UID having
the wrong default network, which in turns prevents it from
accessing Internet.
Test: new test in this patch
Bug: 408717088
Flag: EXEMPT bugfix
Change-Id: If68ea7d60919c0c7e177480f6167196381e00f35
When updating errorprone to 2.27.0, it finds new issues that cause the build to fail.
Flag: EXEMPT refactor
Bug: 253827323
Test: RUN_ERROR_PRONE=true m javac-check
Change-Id: I9c70d64e1f1e43be3bc1d9af8413548d10c8d490
TextStrings was kept for backwards compatibility when the code was used
outside of Android, but is not necessary in the Android version as only
TextEntries are used.
Test: atest
Flag: EXEMPT refactor
Change-Id: If70fe1512570dd55019eac06cfce91639fd04b11
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
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
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
Jean Chalard
authored and
Android (Google) Code Review
commited 
Cole Faust
commited 
Xiao Ma
commited 
Remi NGUYEN VAN
authored and
Treehugger Robot
authored and
Paul Hu
commited 
Automerger Merge Worker
commited 
Gerrit Code Review
commited 
Patrick Rohr
authored and
Motomu Utsumi
commited 
Chris Desir
authored and
Chaitanya Cheemala (xWF)
authored and
Sarup Dalwani
authored and