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
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
Now that faulty Telephony tests have been disabled temporarily
to allow for this bugfix, this can be reverted.
This reverts commit 653d5f1ef4.
Test: FrameworksTelephonyTests CtsNetTestCases
Change-Id: If6b1541981803dc84de57b48adb13d40c9997fa0
* changes:
Revert "Return the registry in registerNetworkAgent."
Revert "Unify registration and NM assignment in NAI"
Revert "Add a queue system server-side for NetworkAgent"
Pechetty Sravani (xWF)authored and Gerrit Code Reviewcommited 2025-03-17 02:23:26 -07:00
Revert submission 3535182
Reason for revert: <Droidmonitor created revert due to b/404070202.Will be verified through ABTD for standard investigation.>
Reverted changes: /q/submissionid:3535182
Change-Id: I2febd2ee7227d487d9cd69dcabd9c04f888fd2de
Revert submission 3535182
Reason for revert: <Droidmonitor created revert due to b/404070202.Will be verified through ABTD for standard investigation.>
Reverted changes: /q/submissionid:3535182
Change-Id: I65fdaaacb56c8ef227eaf1a0193efe8d332d6473
Revert submission 3535182
Reason for revert: <Droidmonitor created revert due to b/404070202.Will be verified through ABTD for standard investigation.>
Reverted changes: /q/submissionid:3535182
Change-Id: Id48ef1cf44911cb291bcd8db349934751297718b
Pechetty Sravani (xWF)authored and Gerrit Code Reviewcommited 2025-03-17 00:48:05 -07: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
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
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
Also make the network agent registry two way to eliminate
reordering possibilities.
Test: ConnectivityCoverageTest, CtsNetTests
Change-Id: I0fd90716b9f5501bdcdc7ee5165321737a0076ae
This is needed by tethering local network feature, given that
the IpServer needs to setup forwarding after native network
creation and before signaling network availability.
Test: atest CtsNetTestCases:android.net.cts.NetworkAgentTest \
ConnectivityCoverageTests:android.net.EthernetTetheringTest \
ConnectivityCoverageTests:android.net.connectivity.com.android.server.ConnectivityServiceTest \
--update-device
Bug: 349487600
Change-Id: I2bc2ec355e01be661b587406bd127dff11665047
PendingIntent.send will throw CanceledException when the intent
can't be sent, because it was canceled or some other reason. In
some, but not all of these cases, it will still call onSendFinished
after the send is done. This means there is no way to be sure
to do something exactly once after the intent is sent.
Unfortunately, ConnectivityService must keep a wakelock until
sent is finished, and wakelocks must be released exactly once.
Too bad.
The simplest solution is to create a specialized listener object
that can manage the lifecycle of the wakelock. This allows
very localized code, easy review and checking, cheap thread
safety, and not creating multiple locks. It also avoids the
ConnectivityService class implementing OnFinished itself,
which is arguably not very readable considering how big
the class is.
Test: new test that crashes the system without the patch
Fixes: 390043283
Change-Id: Ice528eddaedb4d663098eb2bb0ae7183dafbc073
These optimizations are already launched to all public Pixel
devices and were in in 25Q2 beta releases as well. Enable them
by default on all supported releases. The appcompat risk is very
low (these changes are difficult even for an app to detect if
it's looking for them), the user benefits are substantial, and
there is a kill switch if any unforeseen issues do occur.
Bug: 327038794
Test: both codepaths are covered by existing tests
Change-Id: I42c7ceb71ef02d078bf4563744cb11afd412f267
Lorenzo Colitticommited 2025-02-26 04:24:58 +09:00
Junyu Lai
commited 
Chalard Jean
commited 
Motomu Utsumi
commited 
Chaitanya Cheemala (xWF)
commited 
Sarup Dalwani
commited 
Treehugger Robot
authored and
Gerrit Code Review
commited 
ESWAR MAGATAPALLI (xWF)
authored and
Maciej Żenczykowski
commited 
Satish Yalla
commited 
Lorenzo Colitti
authored and
Pechetty Sravani (xWF)
authored and