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
(a) this function returns a constant
(b) this function is utterly misnamed/documented:
an ipv4 mapped address is (like any ipv6 address) 128 bits long
(c) there's not even a guarantee the address is v4 mapped
when it is called
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I35bd84d28feca080152fd0c3d8e7b22835698b38
Maciej Żenczykowskicommited 2025-03-19 22:03:50 -07:00
Revert submission 3548747
Reason for revert: Droidmonitor created revert due to b/404956859. Will be verified through ABTD for standard investigation.
Reverted changes: /q/submissionid:3548747
Change-Id: I0c0b2724666cf6dfddbe3633fd50454f003ed133
Revert submission 3548747
Reason for revert: Droidmonitor created revert due to b/404956859. Will be verified through ABTD for standard investigation.
Reverted changes: /q/submissionid:3548747
Change-Id: I44affb742ca066406e93fc75056b4d3d1298eadb
Revert submission 3548747
Reason for revert: Droidmonitor created revert due to b/404956859. Will be verified through ABTD for standard investigation.
Reverted changes: /q/submissionid:3548747
Change-Id: Ic4226f2f1a20965f80b554967568a4450e460da2
Satish Yallaauthored and Gerrit Code Reviewcommited 2025-03-19 20:18:37 -07:00
This relands aosp/2623893 now that the underlying timing
issues have been fixed. It also addresses the two outstanding
comments that had not been fixed. It conditions it on the
"queue in system server" feature.
Currently, various codepaths in ConnectivityService disconnect
networks using NetworkAgentInfo#disconnect. This posts a message
to the NetworkAgent to disconnect and also posts a message to
ConnectivityService to call disconnectAndDestroyNetwork, which
performs all cleanup in ConnectivityService. These two messages
race and the order is non-deterministic.
Instead, always disconnect using disconnectAndDestroyNetwork,
and have disconnectAndDestroyNetwork post the message to the
agent to disconnect.
This fixes a bug where if wifi uses unregisterAfterReplacement
twice in quick succession, when the third agent connects it
doesn't work because the interface is still being used by the
second network.
Bug: 286649301
Test: covered by existing tests
Change-Id: Ib1d77da39232c02060a7a7c016ffd3a969e2356d
Lorenzo Colittiauthored and Chalard Jeancommited 2025-03-19 21:03:23 +09:00
This CL provides convenience methods to iterate over all
networks.
- forEachNetworkAgentInfo takes a consumer and runs it on all
networks in mNetworkAgentInfos. The consumer is allowed to
remove any number of networks. This is needed because some
loops over mNetworkAgentInfos result in disconnecting networks,
which removes them from the set.
- anyNetworkAgentInfo takes a predicate and returns true iff it
returns true on any element in mNetworkAgentInfos. The
predicate is not allowed to modify the set in any way.
Bug: 288149251
Test: simple refactor, covered by existing unit tests
Change-Id: I5d8b38503895d33abc2d96daaa1c96372befce64
As ConnectivityService is ready to accept messages about a network
agent, it should process messages immediately and before messages
from other agents are processed.
This is because of minute ordering issues between the agent process,
ConnectivityService and the network stack. In particular, as the agent
is created, ConnectivityService requests the NetworkMonitor from the
network stack ; while this is happening, the process creating the
agent may have sent a bunch of other messages... including, but not
limited to, disconnects or creation of other agents.
The operative case is the case where a disconnect is in the queue.
agent1.register
→ CS creates the monitor for agent 1
agent1.unregisterAfterReplacement
→ CS enqueues in agent1 pending creation of the monitor
agent2.register
→ CS creates the monitor for agent 2
monitor for agent 1 is created
→ CS posts a message to complete agent 1 creation
monitor for agent 2 is created
→ CS posts a message to complete agent 2 creation
agent 1 creation completes
→ CS re-posts the unregisterAfterReplacement message
agent 2 creation completes
...and this is where things fail, because unregistering agent 1
isn't processed yet. If they use the same interface (which is
a common use case for unregisterAfterReplacement) then this
creation will fail.
To address this, this patch will process all agent1 messages
synchronously as the creation completes. It will solve the case
above, and it passes all tests for early network creation.
However, it is worth noting that this is not actually correct,
because it does not guarantee that all messages are processed
in order. Namely, two agents have separate queues and
therefore if they send interleaved messages while CS is
waiting for the NetworkMonitor to be created, the order of
these messages will be lost. e.g.
agent1.register
agent2.register
agent1.unregisterAfterReplacement
The case above SHOULD fail if the agents have the same
interface, but with this patch it will likely succeed because
the call to agent1.unregisterAfterReplacement will be received
while the two NetworkMonitor are being created, and then
be processed as agent1 finishes registration.
The correct change, therefore, would really enqueue all
messages when *any* agent (of the same process at least)
is being created. However, it is arguable whether it's worth
building that change over this one, and it is even arguable
whether the behavior of this here change might not be
better, insofar as two agent messages are generally
unrelated to each other except for unregistering.
Test: CtsNetTestCases ConnectivityCoverageTests
Change-Id: Idf75e4e96c67a456cf0979a79321603b46e8c99c
Now that the system server has a queue doing this job,
the queue on the network agent side can be removed.
Test: ConnectivityCoverageTests, CtsNetTestCases
Change-Id: Idf0435f447cfdd28d829a867d1085771837c6f9b
* changes:
Reapply "Add a queue system server-side for NetworkAgent"
Reapply "Unify registration and NM assignment in NAI"
Reapply "Return the registry in registerNetworkAgent."
Jean Chalardauthored and Gerrit Code Reviewcommited 2025-03-18 03:19:07 -07:00
Now that faulty Telephony tests have been disabled temporarily
to allow for this bugfix, this can be reverted.
This reverts commit a5ec9b4112.
Test: FrameworksTelephonyTests CtsNetTestCases
Change-Id: I71abf9d02bdd34a4de80157a3f42bdfee6f6617e
Now that faulty Telephony tests have been disabled temporarily
to allow for this bugfix, this can be reverted.
This reverts commit 30fcf820f9.
Test: FrameworksTelephonyTests CtsNetTestCases
Change-Id: I57f25f5e6481106255df0ab69558e351eb938f68
Chalard Jean
commited 
Junyu Lai
authored and
Android (Google) Code Review
commited 
Lorenzo Colitti
commited 
Treehugger Robot
authored and
Motomu Utsumi
commited 
Chaitanya Cheemala (xWF)
commited 
Sarup Dalwani
commited 
Gerrit Code Review
commited 
ESWAR MAGATAPALLI (xWF)
authored and
Maciej Żenczykowski
commited 
Satish Yalla
commited