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
Addressing feedback from previous change "Adding stacked link addresses
to local_net_access map" and adding more test cases for impact of
stacked link properties on local network prefixes.
Bug: 369815823
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.BpfNetMapsTest
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.CSLocalNetworkProtectionTest
Change-Id: I4d32d86d3e083a1a14b845583fd80a7a4b18ae5f
Starts L2capNetworkProvider in ConnectivityService. Alternatively, this
could be moved to ConnectivityServiceInitializer instead in a follow up.
When L2capNetworkProvider is created, it starts a handler thread, so
makeL2capNetworkProvider must return null in tests as otherwise the
thread leaks.
Test: atest NetworkReservationTest
Change-Id: I35c14815b1a71f0739c1bf63ad466763d611434c
Iterating over stacked link address to ensure correct mapping for
interface to local network ip prefixes.
Bug: 369815823
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.BpfNetMapsTest
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.CSLocalNetworkProtectionTest
Change-Id: I3b2ed906caf43584ffb0e8041f9302c760099f7b
Whenever ip interface is updated, we are updating local network
addresses. These may include dns servers that are needed to be excluded from
restrictions.
Bug : 393354879
Test: Manually and atest
ConnectivityCoverageTests:android.net.connectivity.com.android.server.CSBpfNetMapsTest
Change-Id: Id4ebb33ab7de84ac1c81d485e599779c460bacdc
Whenever LinkProperties is added/modified/removes, we are updating local
network prefixes for the modified interface/addresses. These prefixes
are used by BPF egress and ingress cgroup hooks to disallow local
network packets if the calling application do not have required
permission.
Bug: 369815823
Test: Manually tested
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.BpfNetMapsTest
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.CSLocalNetworkProtectionTest
Change-Id: Ie592ecb948ae05a0a73f47d0573560eb705f6bcf
nri must be tracked for sending blocked status if
shouldTrackUidsForBlockedStatusCallbacks() && nri.mMessenger != null
is true. See trackUidAndMaybePostCurrentBlockedReason.
nri for pendingIntent which has null mMessenger and nonNull
mPendingIntent does not needed to be tracked since blocked status change
does not trigger anything.
Bug: 394732798
Test: testRegisterNetworkCallback_withPendingIntent
Change-Id: Ie97984c241e55cb1350438af4d5f1daf579e0830
The missing permission check means that an unauthorized app could
have registered a network offer to intercept all NetworkRequests (by
trivially guessing an existing provider ID) which would have leaked
information about other apps on the system.
This adds a NETWORK_FACTORY or MAINLINE_NETWORK_STACK permission check
to offerNetwork per the API annotations in ConnectivityManager.
Test networks can be offered when holding the MANAGE_TEST_NETWORKS
permission which is consistent with similar APIs in this class.
There can be no legitimate use of this API a) offerNetwork is @hide
and only exposed via NetworkProvider, and b) it requires getting a
provider ID by calling registerNetworkProvider which correctly enforces
permissions.
unofferNetwork does not currently require any permissions. Again, this
is consistent with the API annotations in ConnectivityManager.
Test: TH
Change-Id: If71ce012f927a34c647d36b5eaf3723de2c01879
Resrvation requests are not currently supported in multilayer requests.
While they are not inherently incompatible, it is unclear how the two
concepts would / should interact, so this CL explicitly prohibits this
situation.
This is a follow up to a comment in aosp/3403183.
Test: TH
Change-Id: Ia5a2cc1780409e3f2d423f244be04fbedf6bbb63
A NetworkOffer can be updated by registering a new set of capabilities
and score using an already registered NetworkOfferCallback object.
Since reserved offers are guaranteed to never send more than a single
onReserved() callback, they cannot support updating the capabilities
(not to mention that the reservationId is also part of the
capabilities).
This change changes NetworkOffer migration to only allow reserved offers
to update their NetworkScore. If a reserved offer tries to update its
capabilities, the existing offer is removed and the new offer is
silently rejected. This change does not affect regular offers (with
RES_ID_UNSET) nor blanket offers (with RES_ID_MATCH_ALL_RESERVATIONS).
Test: CSNetworkReservationTest
Change-Id: I872a1dbda209098f08391a7543b9446e1f50d4f0
reserveNetwork allows a requestor to initiate the creation of a network
that requires the system to preallocate resources which can then be
advertised by the requestor on or off device in order to help create the
network.
For example, this API will be used to reserve a IP over L2cap server
network, which requires the system to first create a
BluetoothServerSocket and reserve a PSM (i.e. port). This information is
passed back to the requestor via onReserved() callback and subsequently
advertised via a BLE advertisement. The network is established as soon
as the client connects to the advertised PSM, which will trigger a call
to onAvailable(), just like a regular NetworkRequest.
onReserved() callbacks are exclusive to the reserveNetwork API and are
sent when an NetworkOffer is registered that matches the reservation ID
of an existing request. A reserved offer always follows the reservation
request as it is created in direct response. onReserved() can only be
called once. If for some reason the reservation gets cancelled by the
system (i.e. the NetworkOffer is retracted) or cannot be fulfilled,
onUnavailable() is called. It is up to the app to file a new
NetworkRequest when this happens.
An onReserved() callback is not queued, because
a) it cannot be called more than once for the same reservation,
b) it must always be the first callback, and
c) it only gets cancelled by onUnavailable().
This change does not handle NetworkOffer migrations, such as updating
the score, properly. This must be addressed before the feature can ship
as the yieldToBadWifi logic can update the score on all NetworkOffers.
API-Coverage-Bug: 372936361
Test: Very basic CSNetworkReservationTest; more to follow.
Change-Id: I9b349d469830bf28e006cf403c605574371db267
onReserved() is called in response to a successful Network reservation
with the NetworkCapabilities of the reserved network. onReserved is
called at most once. If the reservation is released, onUnavailable is
called.
Test: TH
API-Coverage-Bug: 372936361
Change-Id: Idcef572ab9d07981799efc349206aadb620e0e69
This API is designed to set the UID of the app that is allowed to
perform network traffic for captive protal login, communication will
bypass network access restrictions such as VPNs and private DNS settings
when a portal page is launched by Android Custom Tabs and bind the
upcoming traffic to that portal network.
Bug: 373773542
Test: atest ConnectivityCoverageTests
Change-Id: I9992671634b8e88f5a647455811a6157fb15a44b
Patrick Rohrauthored and Xiao Macommited 2024-12-11 20:27:10 +09:00
The values are only read during startup so moving these to a boot
namespace. This will ensure that the values are committed to logs only
after a boot.
The boot namespace is already provisioned, but going forward the
string constants for the namespace do not need to be defined in the
DeviceConfig module.
Test: atest ConnectivityCoverageTests:\
android.net.connectivity.com.android.server.CSNetworkActivityTest
Test: Manually using shell commands. E.g.:
adb shell device_config put tethering_boot \
cellular_data_inactivity_timeout 4
Bug: 377759682
Change-Id: Icd4bd3da288e5dfde620d779bd0708319da90be9
Satish Yalla
commited 
Gerrit Code Review
commited 
Chalard Jean
commited 
Lorenzo Colitti
authored and
Pechetty Sravani (xWF)
authored and
Sarup Dalwani
commited 
Chaitanya Cheemala (xWF)
authored and
Treehugger Robot
authored and
Junyu Lai
commited 
Motomu Utsumi
authored and
Jacque Li
authored and
Neha Raj
commited 
Patrick Rohr
commited 
Xiao Ma
commited 
Suprabh Shukla
commited