The test failed because the test generated traffic
before the unplug command really done.
The unplug command will eventually have onBattery changed
to true. If the traffic is generated before onBattery changed
to true, then the cellular stats won't be updated. And then,
when BatteryStatsService schedules a sync task to update the
stats which will get no delta because the stats on cellular
has already added to mLastModemNetworkStats. Thus, the test
will finally get failed.
Currently, the battery unplug command is executed after connecting
to cellular network and making sure wifi is disconnected which may
trigger battery stats service schedules sync tasks. If there are
too many tasks need to run, then change onBattery to true would
be later. Thus, move the unplug command to the beginning of the
test and add "dumpsys batterystats --write" which will wait for the
worker to finish the task before continuing. Thus, it can make sure
the batterystats are synced.
Also, the stats will be reset when the devices are unplugging after
the battery was last full or the level is 100, or have gone through
a significant charge. So, enable no-auto-reset to avoid the stats
getting reset during the test.
Bug: 192808200
Test: atest CtsNetTestCases:BatteryStatsManagerTest
Change-Id: I08b38d9955c8cbb2d680e268c29368a4c0a7d144
Due to b/192431153, PermissionMonitor only apply permission to
app id which is listed in settings. Thus, temporarily change uid
to appId.
Bug: 192116643
Test: atest ConnectivityManagerTest#testUidsAllowedOnRestricted\
Networks with system & secondary user.
Change-Id: Iadec66344d88bd80170cd5441270b768cdbe0917
Tests may be flaky due to the usage for assertNoCallback().
The method expects no any callback received. Based on the usage,
tests expect to not to receive certain callback, such as
onAvailable(). The network may update its linkproperties during
the test and trigger onLinkPropertiesChanged(). These callbacks
are ignorable in the tests. They should not fail the tests.
Replace the assertNoCallback to new assertNoCallbackThat with
callback type specified to deflake tests.
Bug: 192239030
Test: atest android.net.cts.ConnectivityManagerTest\
--iterations 20
Change-Id: I1643c1ff15215c07e174dbcb664cfac2a38d5840
CtsNetUtils.toggleWifi() expects to receive a CONNECTIVITY_ACTION
broadcast after disconnecting from wifi if wifi is enabled.
The wifi may be connected but not validated since wifi just
turns back to connected from the previous test. In this case,
the system default netwok will not be wifi, so there is no
CONNECTIVITY_ACTION broadcast after disconnecting wifi. It
should ensure the wifi is system default network first before
proceeding with other verifications.
Bug: 192213759
Test: atest CtsNetTestCases --iterations 20
Change-Id: I82f0634883362e35b88854aae28e61b75a3cd7cc
Recent runs have been passing in mainline-postsubmit.
Non-mainline presubmit will be added later, after it has been passing
consistently for some time.
Bug: 187935317
Change-Id: I20e3d6f11458f00ff75f32419b964c97635995b1
Test: TH needs to test
In order to make ConnectivityService the mainline module in ANDROID 12,
The earliest ConnectivityService API getActiveNetworkForUid was exposed.
But after that public api getActiveNetworkForUid and all callers
(Outside the module) has been deleted or replaced in android 12
version. So we should delete the public API in AOSP to keep the APIs
of Android 12 & AOSP consistent and also avoid using it again in AOSP.
The commit is equivalent to ag/14029494, but done in a different repo.
Bug: 183465229
Test: atest ConnectivityControllerTest
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Change-Id: I50a39d6391c88bbb914a63fdb17bae6851591c01
Stop using the stopgap TRANSPORT_USB from NetworkCapabilitiesUtil, which
is being removed.
Bug: 184158327
Test: atest NetworkCapabilitiesTest
Change-Id: I6bbb35d39ff67d6f53b389689dc9f1067e64f962
There is a new transport type - TRANSPORT_USB(8) in Android S,
so when the test tries to add this new transport type in older
Android version, it cannot pass the transport type validation and
make test fail.
(clean cherry-pick of change in downstream branch history)
Original change ID before project move:
I38816173b04ea198d99f64f45e9271ac2641e4ac
Bug: 184158327
Test: run CtsNetTestCasesLatestSdk on Android R & Q
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Change-Id: Ib0368241771d287c09c0e4463f91122533f85a27
Instead of jarjaring the whole com.android.internal.util package, apply
the jarjar rules per-class. Jarjaring the whole package causes problems
in tests, as for example ConnectivityServiceTest depends on Vpn that
uses other internal utils as hidden API, and these should not be
jarjared.
Also avoid jarjaring INetdUnsolicitedEventListener which is used by
NetdEventListenerServiceTest, and ensure KeepalivePacketDataUtilTest
expects the right package name in toString.
Generally the problems appear because ConnectivityCoverageTests also
includes tests for classes that are not part of the connectivity module,
and use hidden APIs that refer to classes that should not be jarjared.
Some of the tests could be excluded from the coverage suite instead, but
keeping them is helpful for future modularization efforts.
Test: Build service-connectivity, dexdump classes and verify jarjared
atest ConnectivityCoverageTests
Change-Id: Id6b7e6833d49fa03d9442d7c1c3e4dc16fb48dfc
BatteryStatsManager did not exist on Q, so it cannot and should not be
tested there.
Bug: 193586822
Test: atest CtsNetTestCasesLatestSdk on Q
Change-Id: Ia9bef7c3438c25e1a4cb403b27cb0084bbd4f824
Tests using CtsNetUtils.TestNetworkCallback would generally assume that
waitForAvailable would return a non-null Network if onAvailable was
called after it was registered. However this is not true if a network
was available, then lost before waitForAvailable is called. This
can typically happen if wifi was disconnected just before calling
ensureWifiConnected (so wifi is being toggled).
In case onUnavailable was called, always wait for the next onAvailable
callback, so that waitForAvailable always waits for a network to be
available. So:
Old behavior:
1) registerNetworkCallback called
2) onAvailable called
3) onLost called
4) waitForAvailable called -> returns null immediately
5) onAvailable called -> unused
New behavior:
1) registerNetworkCallback called
2) onAvailable called
3) onLost called
4) waitForAvailable called -> blocks
5) onAvailable called -> waitForAvailable returns the network
Bug: 190913510
Test: atest CtsNetTestCases
Change-Id: I6bde82ad787371ecffd6caa950b52d90a29ab20b
Bpf offload do not support VCN network yet, don't start bpf offload
if the interface is ipsec*.
Bug: 191178945
Test: atest TetheringTests
Change-Id: I1ad8cededddec42f45b08aaa31d583c548d105f0
This is fixing post-FIN state (by disabling offload post-FIN).
Once the tcp state enters half-closing tcp state (fin wait,
close wait), delete the offload rules.
From this commit, we have done the short term solution for conntrack
tcp timeout issue. Here is what we have done so far.
- Stop updating tcp timeout to avoid updating wrong tcp state
timeout.
- Update the ESTABLISHED timeout
nf_conntrack_tcp_timeout_established (432000) after adding
bidirectional rules.
- Delete the tcp rules when the tcp state has left
"established".
Here is the long term solution and need to be addressed in follow up
commits.
- Parse the tcp state from netlink conntrack event.
- Build a mapping to trace the tcp state of the tcp conntrack event.
- Update tcp state timeout for {ESTABLISHED (432000), FIN_WAIT (120),
CLOSE_WAIT (60)}.
Bug: 190783768
Bug: 192804833
Test: atest TetheringCoverageTests
Manual test:
1. Browse on tethered device
2. Check conntrack tcp state is established.
$ cat /proc/net/nf_conntrack
ipv4 2 tcp 6 431995 ESTABLISHED src=192.168.207.9
dst=140.112.8.116 sport=50697 dport=443 ..
3. Check offload rules are added via dumpsys.
Upstream:
tcp .. 192.168.207.9:50697 -> 14(rmnet0) 10.224.1.247:50697
-> 140.112.8.116:443 ..
Downstream:
tcp .. 140.112.8.116:443 -> 30(30) 10.224.1.247:50697
-> 192.168.207.9:50697 ..
4. Stop browsing for a few seconds.
5. Check conntrack tcp state is half-closed.
$ cat /proc/net/nf_conntrack
ipv4 2 tcp 6 116 TIME_WAIT src=192.168.207.9
dst=140.112.8.116 sport=50697 dport=443 ..
5. Check offload rules are removed via dumpsys.
Upstream:
(not found)
Downstream:
(not found)
Change-Id: I07e27230bf8952acd7828d1f605167758b3bc490
Needed because a payload data packet may have gone through
non-offload path, before we added offload rules, and that this
may result in in-kernel conntrack state being in ESTABLISHED
but pending ACK (ie. UNACKED) state. But the in-kernel conntrack
might never see the ACK because we just added offload rules.
As such after adding the rules we need to force the timeout back
to the normal ESTABLISHED timeout of 5 days.
Issue: the timeout is set to unacknowledged 300s (countdwon to 298s)
$ adb shell cat /proc/net/nf_conntrack
ipv4 2 tcp 6 298 ESTABLISHED src=192.168.244.128
dst=140.112.8.116 sport=45694 dport=443 ..
Test: atest TetheringCoverageTests
Manual check:
$ adb shell cat /proc/net/nf_conntrack
ipv4 2 tcp 6 431988 ESTABLISHED src=192.168.40.162
dst=140.112.8.116 sport=40774 dport=443 ..
Bug: 190783768
Bug: 192804833
Change-Id: I8c34e85e26c9d976e5e2b85473db75ff46d8abd4
This is a preparation for only update the tcp timeout while
adding rules. Also add slack time for updating UDP timeout
interval.
Bug: 190783768
Bug: 192804833
Test: atest TetheringCoverageTests
Change-Id: I3151b531e6581e257f3cfa39ad2fcf1650358b3d
This ensures classes are used from the service-connectivity jar, instead
of using classes from the system_server bootclasspath when there is a
name conflict.
Any developer adding a future class should do so in a subpackage of
com.android.connectivity (such as com.android.connectivity.server).
Otherwise, jarjar rules need to be added manually until b/180995093 is
fixed.
Also update current jarjar rules so that classes are jarjared to
com.android.connectivity.[original name], making it easier to find the
original source. This is consistent with the wifi module.
Bug: 193086215
Test: atest CtsNetTestCases
dexdump on service-connectivity.jar shows no classes outside of
com.android.connectivity and com.android.server
Change-Id: I2aadeca32751267b74d4fd2fd93bb3e8c62e46c0
Currently netd supports only the default value for VPN but CS
send priorty value 1 to netd. It will break the default routing
for VPN. Thus, update network preference priority value to 0 for
VPN.
Bug: 193245476
Test: atest CtsHostsideNetworkTests:HostsideVpnTests
Change-Id: I197cb358e8e30355fbf675e4c623abebe7abdb7f
The hypothesis here is that some other thread is using
the mock between the call to when() and the call to
.thenReturn() a few lines above the failure. It's not
clear this is really the reason, but using this syntax
is safer anyway, so whether it fixes the issue or not
this is a good change.
Test: m FrameworksNetTests
Change-Id: I501d2ec8e794c67a53d7c84e290e4cc63481472d
- Remove ipv4MappedAddressBytesToIpv4Address because it can be covered
by parseIPv4Address.
- Remove IllegalArgumentException from parseIPv4Address because it has
never happened
- Reverse the order of upstream and downstream timeout refreshing in
refreshAllConntrackTimeouts for readability because both source and
destination of the downstream are opposite direction to the
upstream.
Bug: 190783768
Bug: 192804833
Test: atest TetheringCoverageTests
Change-Id: I6a1e44777a4357dd3847c2e2bb1fc6c3cf01617c
Internal utils are generally jarjared by connectivity jarjar rules, but
ArrayUtils is not actually statically linked into the tests, so this
makes the ConnectivityCoverageTests fail. FrameworksNetTests has been
fine because it does not use jarjar, but does not exercise updated code
because of that.
Remove usage of the hidden utility, as there are reasonable alternatives
with non-hidden APIs that avoid other breakages long-term.
Bug: 187935317
Test: atest ConnectivityCoverageTests:ConnectivityServiceTest
Change-Id: I8ed85b941c3d1028771a5ac33196b1509a95789d
