NetworkMonitor obtained LinkProperties and NetworkCapabilities via
synchronous calls to ConnectivityManager after receiving an asynchronous
notification, which is prone to races: the network could be gone before
the LinkProperties/NetworkCapabilities can be fetched.
Fix the race by passing LinkProperties/NetworkCapabilities directly to
NetworkMonitor in the asynchronous notifications.
Test: atest FrameworksNetTests NetworkStackTests
Test: booted, WiFi works
Bug: 129375892
Change-Id: I200ac7ca6ff79590b11c9be705f650c92fd3cb63
This method was removed as part of addressing API council feedback in b/129261432
Add back previous DnsResolver#query which is already being used by developers.
Bug: 129395490
Test: atest DnsResolverTest
Change-Id: Ic956db204f3940d39d42e1b11dda39e57d356fad
* changes:
Move BatteryStats and StatsCompanionService to use NetworkStatsService.
NetworkStatsService: Fix getDetailedUidStats to take VPNs into account.
Take all VPN underlying networks into account when migrating traffic for VPN uid.
This API is similar to one provided by NetworkStatsFactory with the
difference that NSS also migrates traffic from VPN UID to other apps.
Since traffic can only be migrated over NetworkStats delta, NSS
therefore maintains NetworkStats snapshot across all UIDs/ifaces/tags.
This snapshot gets updated whenever NSS records a new snapshot
(based on various hooks such as VPN updating its underlying networks,
network getting lost, etc.), or getDetailedUidStats API is invoked by
one of its callers.
Bug: 113122541
Bug: 120145746
Test: atest FrameworksNetTests
Test: manually verified that battery stats are migrating traffic off of
TUN (after patching above CL where we point BatteryStats to use this
API).
Change-Id: Ib0f0c2d4d41ee1d7a027ea9da457baaf198d649e
VPN uid.
Bug: 113122541
Bug: 120145746
Test: atest FrameworksNetTests
Test: Manually verified on device that stats from VPN UID are moved
appropriately based on its declared underlying network set.
Test: vogar --mode app_process --benchmark NetworkStatsBenchmark.java
Change-Id: I9d8d0cc58d18002c1c96f8ddff780ef8dc452d21
This problem might cause double-close fd and result in app crash
or unexpected behaviour
Bug: 129317069
Test: atest DnsResolverTest
manual test with delaying response callback/cancel
Change-Id: I223234f527edafc51d34fa6be390419c05def8d8
Currently, socketKeepalive implementation is accepting null fd
due to backward compatibility with legacy packet keepalive API.
However, due to lack of the fd, the service cannot guarantee the
port is not reused by another app if the caller release the port
for any reason.
Thus, grant the null fd access only for priviledged apps.
This commit also address some comments from aosp/918533.
Bug: 126699232
Test: atest FrameworksNetTests
Change-Id: I0baf582ff4ca8af6082c3754e8dfbcd867f39792
Currently, if the lower layer, e.g. wifi, didn't successfully
start keepalive by any reason. Due to the startedState changed
to NOT_STARTED first, the logic inside stop() will skip the
removing process and cause leak.
Thus, moving the changing of startedState to proper place first
to unblock subsequent changes first.
Bug: 123988249
Bug: 129371366
Test: atest FrameworksNetTests
Change-Id: I4bba01bacc80e1dac2023ef831b5ade5501894e4
For native services such as mediaserver and audioserver, the permission
information cannot be retrieved from getInstalledPackages. Instead, the
high level permission information is avalaible in systemConfigs. With
those permission information, netd can store the complete list of uids
that have UPDATE_DEVICE_STATS permission.
Bug: 128944261
Test: dumpsys netd trafficcontroller
Change-Id: I0331d5a3a5b927a351fcfe6689ef1ba2b993db0c
Change the INTERNET permission implementation so it only block socket
creation when non of the packages under the same uid have internet
permission. Fix the UPDATE_DEVICE_STATS permission so only the uid that
own the permission can change it.
Bug: 111560570
Test: CtsNetTestCasesUpdateStatsPermission
CtsNetTestCasesInternetPermission
Change-Id: I42385526c191d4429f486cde01293b27fcc1374b
There are 2 problems will make testPartialConnectivity flaky:
1. If we call setNetworkValid() before expectCapabilitiesWith(),
there may be a timing issue that network will become VALID before
NetworkMonitor send PARTIAL_CONNECTIVITY to ConnectivityService.
Solution:
We should set network to valid after ConnectivityService received
NETWORK_TEST_RESULT_PARTIAL_CONNECTIVITY to ensure NetworkMonitor
will send PARTIAL_CONNECTIVITY to ConnectivityService first then
send VALID.
2. When test case call explicitlySelected(true) first then call
connect(true), NetworkMonitor will report the network validation
test result twice because ConnectivityServiceTest() will trigger
notifyNetworkTested() when setAcceptPartialConnectivity() is
called, it may cause a timing that before the second test result
send to ConnectivityService, connect() already called
setNetworkInvalid. So, NET_CAPABILITY_VALIDATED will be removed
and ConnectivityService will trigger onCapabilitiesChanged()
unexpectedly.
Solution:
Don't trigger notifyNetworkTested() when
setAcceptPartialConnectivity() is called. If there is needed,
use mCm.reportNetworkConnectivity() to report the test result
instead.
Bug: 128426024
Test: 1. atest FrameworksNetTests: \
ConnectivityServiceTest#testPartialConnectivity \
--generate-new-metrics 1000
Change-Id: I7200528378201a3c7c09a78ff827b41f2741dfa1
