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: I2ae43c61c9ba0e0db3202a46e63756a3ea5a6512
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
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: I70395af68b0f28e5c333333cb03a42f7633b0d5d
Chaitanya Cheemala (xWF)authored and Gerrit Code Reviewcommited 2025-03-26 03:07:07 -07:00
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
Instead of using an empty string, make the use of default capabilities
explicit by requiring "*" to be specified.
This behavior is more consistent and allows OEMs to explicitly configure
an interface without any capabilities (apart from those which are
hard-coded). (Technically, they could do so by specifying one of the
hardcoded capabilities in the config).
Test: TH
Change-Id: I1d25e5c4b302b0dbde5e1bb91fc1ed5a7b08be9d
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
1. allow OEMs to default the vendor and model name to system properties.
2. use the vendor & model name for net diag TLVs
Change-Id: I30e988ba3e9cb9f9c5dc3a096f162d5dbcdfbc11
This commit adds `config_thread_country_code_enabled` to the
overlayable.xml to allow the device to overlay this configuration.
Bug: b/402276117
Test: Set the `config_thread_country_code_enabled` to `false` in
the real Android device, then run the command
`adb shell dumpsys thread_network` to check the state of
CountryCode module.
Change-Id: I37cea57a38f5487c3a07508854adb6cfd25d50b2
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