In ConnectivityService, updateLinkProperties calls NetworkStats
even though the ip address or interface name has not changed and
only the tcp buffer size has changed. This is noisy and could
be problematic when RAT change occurs frequently, since when
RAT changes tcp buffer size configuration also changes.
This CL also fixes a wrong nullability annotation where the oldLp
of updateLinkProperties could be null when updateNetworkInfo
is called.
Test: atest ConnectivityServiceTest#testStatsIfacesChanged
Fix: 232048480
Change-Id: Ic226eb4a8aa1f38cba293510813f1cb55f0ea658
This patch removes the 8-second unvalidated prompt timer
and replaces it with a 20-second timer that does the
same thing in addition to signalling the stack that the
concerned network has now undergone evaluation once.
Test: FrameworksNetTests
Change-Id: I806f2bdfbf35243fa7cdb1cd1f0a5d549cfcd9c8
These timestamps will be useful for debugging issues where
debuggers need to know what happened to long-lived networks,
where logcat doesn't span long enough.
These timestamps are also likely to be useful in the future,
in particular for metrics.
Test: FrameworksNetTests
Change-Id: I8f46ce92e2ab301fa32e18e714a43a4130719199
Currently, NetworkAgentInfo#satisfies determines whether a
network exists (and should satisfy requests) based on
|created|, not |everConnected|. This is theoretically incorrect
because networks in CONNECTING state or similar must never
satisfy requests or call callbacks.
This cannot happen for requests. New requests are only added to
networks by NetworkAgentInfo#addRequest, which is only called by
computeNetworkReassignment via updateSatisfiersForRematchRequest,
which skips any network with everConnected = false. It can
potentially happen to listens though.
Also, this cannot ever happen for physical networks, because for
physical networks, created is set at the same time as
everConnected, the first time they enter CONNECTED state.
In theory, this can happen for VPNs since ag/988402 , which
changed the code to create VPN networks as soon as they enter
CONNECTING state. That CL added the everConnected boolean to
NetworkAgentInfo but did not update the satisfies and
satisfiesImmutableCapabilitiesOf checks to use everConnected.
In practice, even for VPNs this is very unlikely, since VPNs
advance from CONNECTING to CONNECTED essentially immediately.
Even if they didn't, sending callbacks before they enter
CONNECTED state would be incorrect because the app receiving
the callback would have no way of knowing that the network is
actually not yet connected.
With this change, some checks for everConnected become spurious,
because a network with everConnected=false cannot satisfy either
requests or listens. Remove these checks.
Test: extensively tested by existing ConnectivityServiceTest
Change-Id: I024bb2b85bc57228d53e69a7707c7ce7ac756259
Lorenzo Colitticommited 2022-08-24 15:34:44 +09:00
This reverts commit daf5cb64cc.
Reason for revert: dumpstate has the same information
Bug: 243313712
Change-Id: Ie8283cd942bff6ef9dbb66e5926bf650bd56997f
This is a no-op refactoring which uses common PerUidCounter
from the static library and delete the private implementation
inside ConnectivityService. This refactoring includes:
1. Make a private implementation that inherite PerUidCounter
to convert and rethrow exception to maintain backward
compatibility.
2. Adjust per-uid max limit argument in the counter constructor
since the private implementation is already buggy.
3. Use the getter in PerUidCounter for the existing tests.
Test: testNetworkCallbackMaximum
testProfileNetworkPrefCountsRequestsCorrectlyOnSet
testRequestCountLimits
Bug: 235771502
Change-Id: I5c49edab18774acf819828201041c9931fabccc4
Follow up from aosp/1781202 and aosp/1821293, creating nris
before removing old nris had been proven not necessary for
per-app API flow. Hence, the per-uid counter hack for system
uid that allows counter temporary go over limit does not
actually be used in the production code.
In other words, this CL is a no-op refactoring.
Test: testRequestCountLimits
Bug: 235771502
Change-Id: I8f71c6e4506fbec60cb503731aee64ab022b4634
This is a no-op refactoring. This will be useful to
mutate a member of the NC before sending it to the app.
Test: ConnectivityServiceTest
Change-Id: I1cf472bd7626d5ee2b163078a695c4a52ac39085
Chalard Jeanauthored and Paul Hucommited 2022-08-04 06:45:39 +00:00
To make sure anyone using the capabilities originally from
the agent have to know what they're dealing with, make the
member private and make accessors that spell out explicitly
the important parts.
This is the last step towards addressing the leftover
comment from aosp/1958906.
Bug: 238139913
Test: FrameworksNetTests CtsNetTestCases
Change-Id: I9fc1986c59726212acfc2ad921745c8bbc424035
Chalard Jeanauthored and Paul Hucommited 2022-08-04 06:45:39 +00:00
These are no longer useful. Also, NAI no longer needs to
be comparable, and it should no longer be – comparing 2
NAIs only make sense in the context of a specific request.
Bug: 238139913
Test: ConnectivityServiceTest IpConnectivityMetricsTest
Change-Id: I6967ad6f08380213c29f3d47d6422f8bbea1946c
Chalard Jeanauthored and Paul Hucommited 2022-08-04 06:45:39 +00:00
Unused arguments, non-final members, unannotated members, typos.
This doesn't try to remove all warnings, but just opportunistically
fixes some.
Bug: 238139913
Test: ConnectivityServiceTest
Change-Id: Ia5e905a0244cfb5f72c06d0c0be3458c42b27a52
Chalard Jeanauthored and Paul Hucommited 2022-08-04 06:45:39 +00:00
These objects have a non-trivial lifetime, as they will be
stored while the NetworkMonitor (which lives in another
process) starts. Agents that live in the system server will
still have a reference to the passed arguments and might
want to keep and mutate them for their own purposes. To
avoid bad surprises, ConnectivityService should copy these
objects before the function returns.
This patch should not cause any additional copies, because
the copies that used to happen after the monitor has started
are now not necessary and are removed.
Bug: 238139913
Test: FrameworksNetTests
Change-Id: I1cdd14e7a247dc01a3d73f528c3f3d77bd103be5
Chalard Jeanauthored and Paul Hucommited 2022-08-04 06:45:39 +00:00
Once moving NetworkMonitorUtils to frameworks/libs/net is done, we can
remove the connectivity-module-utils-srcs filegroup from connectivity
module, instead import it from net-utils-device-common lib.
Bug: 238960524
Test: atest ConnectivityCoverageTests
Change-Id: Ic1464a4c32d7c22ca7916e8f298ff1a09b71ce46
Following CLs will switch previous codepath (JNI) and new codepath
(Java) for bpf map operations based on this flag.
Bug: 217624062
Test: atest BpfNetMapsTest
Change-Id: I74f10d5c97390993acea110f6528ef8980bb2aa4
This will move to NetworkAgentInfo. The caps argument is always
the same and can be removed, while the nai argument will become
'this'. The authenticator will need to be passed.
This is a second step towards addressing the leftover
comment from aosp/1958906.
Bug: 238139913
Test: FrameworksNetTests CtsNetTestCases
Change-Id: Ife5e91de15d0571f1251d2cd6f1b3ecc256572c6
Chalard Jeanauthored and Paul Hucommited 2022-07-27 10:45:26 +00:00
This is a first step towards addressing the leftover
comment from aosp/1958906.
Bug: 238139913
Test: FrameworksNetTests CtsNetTestCases
Change-Id: I46c5dfebfc12c4db71f7c9c6624b8d6cdf0bf3b5
Chalard Jeanauthored and Paul Hucommited 2022-07-27 10:31:30 +00:00
"{@see" aren't rendered properly. Replace them with "See {@link"
or @see depending on the usage.
Bug: 238753273
Test: make doc-comment-check-docs ; Check the doc result
Change-Id: I70cb2f36e7c5fa8102b5949054df5184d755202c
Currently (T+), BPF program and map status are only dumped on demand.
$ adb shell dumpsys connectivity trafficcontroller
The information can be useful for issue debugging, especially on Data
Usage and NetworkPolicyManagerService. It should be logged in bugreport
dumpsys connectivity section as Android S (which is handled by netd).
Bug: 237954856
Test: adb bugreport
Change-Id: Ic02a58ff2ebdbf375d9df0917e8218ab8faa96da