Currntly, keepalive slot is released when stop() is called. Next
starting keepalive can use the same slot number while previous
keepalive is still stopping. When the previous keepalive is
stopped, the incoming as will be processed by the new keepalive.
This change release keepalive slot after the result of stopping
has returned. Thus, newly created keepalive cannot allocate the
same slot number while lower layer is still processing stop event.
This change also disable flaky assertions that are caused by
test port has been occupied by other process.
Bug: 129512753
Test: 1. atest com.android.server.ConnectivityServiceTest \
#testNattSocketKeepalives --generate-new-metrics 100
2. atest FrameworksNetTests --generate-new-metrics 10
3. simulate the fail case manually.
Change-Id: I1991627545519ee5cb408a3df3a006f710f4af7b
A mocked PackageManager caused test failures in existing tests.
Revert that for now to make tests pass again.
Bug: 114231106
Bug: 130397860
Test: atest FrameworksNetTests
Change-Id: I4f181789152438f18e6cd2d235d76fabe3872ea3
Lorenzo Colitticommited 2019-04-12 19:52:45 +09:00
This reverts commit bc571c7cc8.
Reason for revert: Rolling forward, will fix tests in same CL stack.
Bug: 114231106
Bug: 130397860
Test: FrameworksNetTests
Change-Id: Ia8a0c99b4e1fd5dff26c881715cd876618ca4321
Lorenzo Colitticommited 2019-04-12 19:52:32 +09:00
This reverts commit 4773027064.
This change does not have any topic: not reverting the other 2 commits in the original topic.
Reason for revert: broke FrameworksNetTests presubmit: b/130397860
Change-Id: Iff41d9fe97fafea44680c8d67d1ce19277548cc0
When a fully-routed VPN is running, we want to prevent normal apps
under the VPN from receiving packets originating from any local non-VPN
interfaces. This is achieved by using eBPF to create a per-UID input
interface whitelist and populate the whitelist such that all
non-bypassable apps under a VPN can only receive packets from the VPN's
TUN interface (and loopback implicitly)
This is the framework part of the change that build the whitelist.
The whitelist needs to be updated in the following cases:
* When a VPN is connected and disconnected
This will cover the change to allowBypass bit, since that can't be
changed without reconnecting.
* When a VPN's NetworkCapabilites is changed (whitelist/blacklist app changes)
* When a new app is installed
* When an existing app is removed
* When a VPN becomes fully-routed or is no longer fully-routed
New user/profile creation will automatically result in a whitelist app change
transition so it doesn't need to be handled specially here.
Due to the limitation of the kernel IPSec interacting with eBPF (sk_buf->ifindex
does not point to the virtual tunnel interface for kernel IPSec), the whitelist
will only apply to app VPNs but not legacy VPN connections, to prevent breaking
connectivity with kernel IPSec entirely.
Test: atest PermissionMonitorTest
Test: atest android.net.RouteInfoTest
Test: atest com.android.server.ConnectivityServiceTest
Test: atest HostsideVpnTests
Bug: 114231106
Change-Id: I143b03d60e46cb1b04732b4a4034f5847b4d1b1a
Since the Framework net test require jni library
libnetworkstatsfactorytestjni, but the test fails to load that library
unless *all* the dependencies of that library are explicitly listed in
jni_libs, whenever any of the dependencies changes the framework net
test will start failing and it might not be catched since the change
might not related to frameworks/base. And this smoke test is aimed to
spot those native library changes and it should be stable enough to put
in global presubmit.
Bug: 124764595
Test: FrameworksNetSmokeTests
Change-Id: Id24e7f0558b5643e4ad7393e85f1f0a2bd875615
This patch fixes a bug where if a binder dies before the linkToDeath
call, the cleanup will be performed before the entry is added to the
array. While it is safe in that quotas and tracking performs as per
normal, the RefcountedRecord may not be cleaned up.
Rethrowing this exception is safe, since the only paths that would hit
this are all on binder threads coming from applications. Further, it
seems there is only one real way of this getting hit - if the app that
called the creation died during the binder call.
Bug: 126802451
Test: Compiled, CTS tests passing
Change-Id: I6db75853da9f29e1573512e26351623f22770c5d
The tests are currently broken without this dependency.
Bug: 129902619
Test: atest FrameworksNetTests
Merged-In: Ifcfe4df81caf8ede2e4e66a76552cb3200378fa8
Change-Id: I85891485157ed86e069039dfe3092028ff703dd5
This commit reduces the flakiness of the
testOpenAndCloseUdpEncapsulationSocket by retrying up to three times.
Unfortunately, testing port-selected socket creation is racy against
other applications. This helps to handle the same race condition as done
in IpSecService#bindToRandomPort
Bug: 128024100
Test: 200x runs of testOpenAndCloseUdpEncapsulationSocket
Change-Id: I7e036ce821019dbac6c50899bd0894e89d2fe82a
In order to notify netd to swap eBPF maps before pulling the
networkStats from eBPF maps, NetworkStatsFactory need to use the
NetdServices to issue binder calls. So it need to be moved from
framework/base/core to framework/base/service since object in
framework/base/core cannot get any system services. This change is also
necessary for setting up a lock inside NetworkStatsFactory to prevent
racing between two netstats caller since the lock need to be hold before
netd trigger the map swap.
Also fix the compile problem caused by moving the NetworkStatsFactory
and the related tests. Rename the packages and the jni functions to a
more proper name.
Bug: 124764595
Bug: 128900919
Test: NetworkStatsFactoryTest
android.app.usage.cts.NetworkUsageStatsTest
android.net.cts.TrafficStatsTest
Merged-In: Ifcfe4df81caf8ede2e4e66a76552cb3200378fa8
Change-Id: Ifcfe4df81caf8ede2e4e66a76552cb3200378fa8
The common package covers tests that should be included both in CTS and
unit tests.
Test: atest FrameworksBaseTests
Bug: 129199908
Change-Id: I9c138d49ce010edde095e4bd3c47e36ca301634a
The kernel eBPF maps have a blacklist to store all the uids that doesn't
have internet permission. When an app is unintalled from the device and
it is the last package on device that uses that uid, make sure we
cleaned the uid from the map and do not add no longer used uids into the
eBPF map. This action helps reduce the number of entries stored in the
map and reduce the chance of overflow the eBPF map.
Bug: 128944261
Test: PermissionMonitorTest
Change-Id: I10dd0113d00d6cf9ca39902d9721f2591d387d4a
Add more tests to PermissionMonitor to verify the functionality related
to INTERNET permission and UPDATE_DEVIE_STATS permission. Modified some
of the class design of PermissionMonitor so that it is easier to test
the new functionalities.
Bug: 111560570
Test: PermissionMonitorTest
Change-Id: Ic5585f337db5de48e2f87bf4f01ed7d85c349827
The argument of IpPreFix#contains() has been marked as @NonNull.
So the IpPrefixTest#testContainsInetAddress should not test
contains() method wiht null object.
Bug: None
Test: atest FrameworksNetTests
atest IpPrefixTest#testContainsInetAddress
Change-Id: I2f6bee19514dc47702f64d2a2bbf02d8b7b1b407
- Restrict unprivileged apps to use
NetworkRequest.Builder#setSignalStrength.
- Remove the "throws NullPointerException" in
CaptivePortalProbeSpec constructor.
- Remove the null check in LinkProperties.
- Add annotataion into all ConnectivityManager.NetworkCallback
methods.
Change-Id: Id275cac1d6a30d7515cd7b113394f5e8a0179314
Fix: 129097486
Test: atest FrameworksNetTests
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
* 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.
Varun Anandauthored and Gerrit Code Reviewcommited 2019-03-29 00:40:53 +00:00
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
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
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
Wayne Ma
authored and
android-build-merger
commited 
Gerrit Code Review
commited 
Junyu Lai
authored and
Lorenzo Colitti
authored and
Remi NGUYEN VAN
authored and
Rubin Xu
authored and
Chenbo Feng
authored and
Treehugger Robot
authored and
Benedict Wong
authored and
Paul Hu
authored and
Xiao Ma
authored and
Luke Huang
authored and
Varun Anand
authored and
Lucas Lin
authored and
Mark Chien
authored and