Destroy platform managed sockets on the removed IP address based on NetworkAgent update.
Bug: 373280981
Bug: 331139818
Flag: android.net.platform.flags.connectivity_service_destroy_socket
Test: atest ConnectivityCoverageTests
Test: device test
Change-Id: I6a1d2d0c25c130c2747d66bee203b0408e2fa0da
Keeping a map from IP addresses to the list of NetworkAgentInfos that have
that IP address in their LinkProperties.
Bug: 373280981
Bug: 331139818i
Flag: android.net.platform.flags.connectivity_service_destroy_socket
Test: atest ConnectivityCoverageTests
Test: device test
Change-Id: I1e39ce00d8bc49252df8088efc768804ae9ee0a8
PermissionMonitor#startMonitoring() was renamed to initialize().
Update comments and local variables accordingly.
Flag: EXEMPT refactor
Test: TH
Bug: 410731080
Change-Id: I840b5172e1ebc761cade0e6082fec0cab7fe9a3b
As a follow-up to ag/33089478 and ag/33101784, the intent
receiving and dispatching logic was refactored and centralized
within the newly introduced BroadcastReceiveHelper.
However, due to the potential risks associated with this
refactoring, a kill switch is being added specifically for the
PermissionMonitor refactoring. This will allow for reverting
to the previous implementation (potentially involving code
duplication) to mitigate risks if issues arise.
Flag: EXEMPT flagged with a kill switch
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.connectivity.PermissionMonitorTest \
ConnectivityCoverageTests:android.net.connectivity.com.android.server.ConnectivityServiceTest \
--update-device
Bug: 410731080
Change-Id: I7889ef457d841c750da60a80e50ed6208c45448f
For maintaining constrained data satellite opt-in apps, this is
needed for tracking apps installed on the storage.
Flag: EXEMPT flagged with a kill switch
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.connectivity.SatelliteAccessControllerTest \
--update-device
Bug: 410731080
Change-Id: I2a686a5a37747de97dcee6b78f66965cb4fd9942
When LinkProperties are updated after a private DNS configuration
is set in updateNetworkInfo(), particularly when private DNS mode
is set to opportunistic and the VPN server uses its own DNS
servers, this can cause the private DNS to use the underlying
network for TLS handshaking, potentially leading to a leak.
To fix this, adjusting the order of operations—setting the private
DNS configuration before updating LinkProperties should resolve
the issue. This ensures that private DNS validation occurs after
the VPN's network configuration is fully applied.
Bug: 274867806
Test: atest ConnectivityCoverageTests
Flag: EXEMPT legacy flag early_link_properties_update_for_vpn
Change-Id: If684b51e6522a8284d5baee8db0d2f767405d359
This feature will be controlled by the caller.
Cronet calls the register/unregisterQuicConnectionClosePayload APIs only
when the Chromium experiment flag is enabled
(http://crrev.com/c/6421621/).
This CL also updates testRegisterQuicConnectionClosePayload
to be skipped on U or older releases since FIREWALL_CHAIN_BACKGROUND is
supported on V or higher releases.
Flag: EXEMPT guarded by chromium flag
Bug: 311792075
Test: TH
Change-Id: Ib008e63c585cfe8775b25783cd55b0873bb5e2f0
This is needed for tracking the applications which opted-in to
use the constrained data satellite network as its default by
adding the following property to the <application> tag of its
manifest:
<property
android:name="android.telephony.PROPERTY_SATELLITE_DATA_OPTIMIZED"
android:value="<package name>" />
Flag: EXEMPT flagged with a kill switch
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.connectivity.SatelliteAccessControllerTest \
--update-device
Bug: 410731080
Change-Id: I00c0ce5e0d7aac1192272e79a19fbab4e3a5e6f1
* changes:
Add light-weight DefferedBroadcastReceiver for handling broadcast events
Move user intent reception out of SatelliteAccessController
Move user/package intent reception out of PermissionMonitor
Jean Chalardauthored and Android (Google) Code Reviewcommited 2025-04-23 21:50:19 -07:00
The PackageManager#getInstallPackagesAsUser method is time
consuming (30~200ms) and blocks boot time while it executes.
This change moves the getInstallPackagesAsUser
method from PermissionMonitor. This is a performance-focused
refactoring to allow for efficient sharing of package enumeration
results in subsequent changes, avoiding redundant time-consuming
operations.
Flag: EXEMPT refactor
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.connectivity.SatelliteAccessControllerTest \
ConnectivityCoverageTests: android.net.connectivity.com.android.server.ConnectivityServiceTest
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.connectivity.PermissionMonitorTest \
ConnectivityCoverageTests:android.net.connectivity.com.android.server.connectivity.BroadcastReceiveHelperTest \
--update-device
Bug: 410731080
Change-Id: I3929fa28ff9419329622f3abdf10336289730607
This is a no-op refactoring that moves the reception of
user-related intents in SatelliteAccessController to
ConnectivityService.
It then dispatches these events to the SatelliteAccessController.
Flag: EXEMPT refactor
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.connectivity.SatelliteAccessControllerTest \
ConnectivityCoverageTests:android.net.connectivity.com.android.server.ConnectivityServiceTest
Bug: 410731080
Change-Id: I9ace3ed09a161446dc92d40bc0d400e32051de32
This is a no-op refactoring that moves the reception of
package and user-related intents in PermissionMonitor to
BroadcastReceiveHelper.
It then dispatches these events to the PermissionMonitor.
This change is necessary to centralize intent receivers
from other subclasses to ConnectivityService in
subsequent modifications.
This reverts the design change introduced in aosp/2183343, which
had PermissionMonitor listening to user change events instead
of ConnectivityService.
Flag: EXEMPT refactor
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.connectivity.PermissionMonitorTest \
ConnectivityCoverageTests:android.net.connectivity.com.android.server.ConnectivityServiceTest \
ConnectivityCoverageTests:android.net.connectivity.com.android.server.connectivity.BroadcastReceiveHelperTest \
--update-device
Bug: 410731080
Change-Id: Ic79afc18a6e8603ddf8d48a1f78cf8d98f2447ae
- Also verify the netd operations that add and remove UID ranges.
- Don't set the network to keep connected, since that is not
representative of what happens on a real device.
Test: test-only change
Bug: 410731080
Flag: TEST_ONLY
Change-Id: Ib4305748b5f1627546b7a63fb9596308b14155e0
Lorenzo Colitticommited 2025-04-23 12:03:57 +09:00
This adds two new shell commands to ConnectivityService that sets
a given UID to fall back to a given transport type if there is no
system default network. The syntax is:
cmd connectivity set-debug-fallback-network-for-uid <uid> <transport>
cmd connectivity clear-debug-fallback-network-for-uid <uid>
This works only on debug builds and should be used only for
manual testing.
Test: none yet
Bug: 410731080
Flag: TEST_ONLY
Change-Id: I9e0ac0713dbb95e59b22faa7cd45bdc8c1070f08
Lorenzo Colitticommited 2025-04-22 22:46:34 +09:00
This makes the code clearer, and also fixes a bug: currently, a
TRACK_DEFAULT request in a multilayer request can cause a network
to remain needed. This is incorrect: only requests should be able
to keep a network up.
This prevents satellite networking from disconnecting when the
default network reappears (see changes in unit test).
This CL removes the code before the loop that special-cases
non-multilayer listens because it is not very useful. Any
non-multilayer listen will either:
- Immediately return false, if it's the active request, or:
- Cause the code to continue (because it's not the active
request), and because mRequests only has one element, will
hit the "return false" statement after the loop.
Flag: EXEMPT bug fix
Test: covered by existing tests
Change-Id: I7295ce469335af924aa20b7976cc4a9136ef5d61
Lorenzo Colitticommited 2025-04-22 22:02:40 +09:00
There are currently 6 or 7 contructors, and some code duplication.
Reduce this to one constructor per use case (callback-based;
PendingIntent based; internal), and use a private constructor to
reduce code duplication.
Bug: 410731080
Flag: EXEMPT refactor
Test: refactor covered by existing tests
Change-Id: I49337374990d646bf5526354cceeea83f3b9c980
Lorenzo Colitticommited 2025-04-22 22:02:33 +09:00
Rename the variable and add a comment to make the code clearer.
Bug: 410731080
Flag: EXEMPT refactor
Test: covered by existing tests
Change-Id: Ia5ff9754b070951948cb3edcfbe11934a2dc13ff
Lorenzo Colitticommited 2025-04-21 13:33:36 +09:00
On V+, ConnectivityService uses uid blocking state in BpfMap instead of
asking NetworkPolicyManager.
But, there was one behavior difference because NetworkPolicyManager
considers the network is always not blocked for apps without Internet
permission.
To ensure backward compatibility, the
NETWORK_BLOCKED_WITHOUT_INTERNET_PERMISSION flag was introduced in
aosp/3076606, aosp/3088285.
This CL updates enforceMeteredApnPolicy to respect this flag for
backward compatibility.
Test: CSEnforceMeteredApnPolicy
Bug: 404428733
Bug: 370383309
Flag: EXEMPT bugfix
Change-Id: I631f4f840818e1d40f20fccae1ec1a2cbbb6a166
1. Add a utility method to create per-app fallback requests.
The new method only has one caller, but another caller will be
added in an upcoming CL.
2. Extract code from removeDefaultNetworkRequestsForPreference to
a more generic method that takes a predicate and that will be
used elsewhere.
Bug: 410731080
Flag: EXEMPT refactor
Test: refactor covered by existing tests
Change-Id: I13facc0f3fff1d4e76d5e8117cfcc182aa049d29
Lorenzo Colitticommited 2025-04-21 11:20:24 +09:00
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
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
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
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
Currently, apps targeting V can see thread local network.
This change introduces a mechanism to make existing
apps unable to see non-thread local networks to ensure minimal
impact on existing devices and applications while adopting this
behavior. Apps targeting B+ Sdk and run on V+ devices can see
non-thread local networks.
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.CSLocalAgentTests \
--update-device
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server --update-device
(on next/trunk_staging release config)
Bug: 349487600
Change-Id: I6aa43cebc20a9017c2d8a8a90ebb1d53040a27bb
...and if the feature is not killed.
For devices on V and below, this feature should be subject
to a rollout. That rollout should be done in mainline beta
if possible at all, meaning the flags can be defined later.
If beta isn't possible after all, a legacy rollout can happen
starting in M2025-06 too.
Test: manual
Change-Id: I941762bf759ce25b4bd1f908e971ceaf4f49f671
Now that the faulty test is fixed,
This reverts commit 0141d82c2d.
Test: ConnectivityCoverageTests CtsNetTestCases FrameworksTelephonyTests
Change-Id: Ic9fee5bb7efb8ca4c05d7c9e600236186d094080
Now that the faulty test is fixed,
This reverts commit 19dcc447c4.
Test: ConnectivityCoverageTests CtsNetTestCases FrameworksTelephonyTests
Change-Id: I30fa35cef1729e6ecd4140c52fabfa2da1a9bb4b
Now that the faulty test is fixed,
This reverts commit 09bc78fda7.
Test: ConnectivityCoverageTests CtsNetTestCases FrameworksTelephonyTests
Change-Id: If52cc211b7859c0add07c16f171a6ce342ccca97
Sewook Seo
commited 
Junyu Lai
commited 
Ying Xu
commited 
Jimi Chen
authored and
Android (Google) Code Review
commited 
Paul Hu
authored and
Treehugger Robot
authored and
Motomu Utsumi
commited 
Chalard Jean
commited 
Lorenzo Colitti
commited 
Chaitanya Cheemala (xWF)
commited 
Sarup Dalwani
commited 
Gerrit Code Review
commited 
ESWAR MAGATAPALLI (xWF)
authored and