There is pollingConnector thread which start polling connector if
TetheringManager is created earlier than TetheringService started(during
device boot up). TetheringManager won't be GCed if pollingConnector
thread do not finish its task yet.
Bug: 177265744
Bug: 191798390
Bug: 187972579
Test: atest TetheringServiceTest
Change-Id: Id8c7d10c5172e1d5de460c5311ff9c20261facef
TetheringCallbackInteranl is inner class which explicitly reference
TetheringManager object. This causes TetheringManager can't be GC. Using
static nested class which has its own lifecycle and weak reference
TetheringManager object.
Still have a leak inside Tethering that TetheringCallbackInternal is
never unregistered. Currently it rely on binder died to remove the
reference, which usually happen in kill process. If process keep alive,
the TetheringCallbackInternal would not be freed even TetheringManager is
gone. Will have follow CL to fix this.
Bug: 177265744
Bug: 191798390
Bug: 187972579
Test: 1. lunch Settings with ON/OFF tethering, dump java heap.
2. close Settings and restart Settings again, dump java heap.
3. Compare java heap between step 1 and step 2.
Change-Id: I0e2a21b7988115098a033a581cd98da8bffe2791
Upon changing the default SIM card, the radio will create a
new connection to the new subscription. If that subscription
works correctly, the stack will prefer it to the old one as
the new subscription will be marked with a Primary policy
flag it its score.
Normally, at this point the old network lingers to give apps
an opportunity to gracefully migrate their connections. But
with some radios, this may have a dramatic effect on the
performance of the new connection.
This patch introduces a flag so that devices with such radios
can be marked. In this case the stack will move to a degraded
mode and eschew the grace delay for apps and give them a hard
break instead, so that the new network can reach a good
performance immediately. Apps with existing connections will
suffer a worse experience.
If there is a request that can only be served by the old
connection, still keep it, as arguably the user still
expects their MMS be sent on the old connection, even if the
new connection doesn't work well until it's done.
Test: new test in this patch, and add relevant tests in both modes
also manually change the value of the flag and run
FrameworksNetTests and CtsNetTestCasesLatestSdk
Bug: 200226979
Change-Id: I4ace82f90e873bf06298cc689bb1d794ed5124bd
The removeDefaultNetworkActiveListener should do the
unregisteration but it's incorrectly calling
registerNetworkActivityListener into the ConnectivityService.
Bug: 199753782
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I65a2ddc82989d736316d51f5058e707f5b261a82
Add two test cases for matchesMobile and matchesMobileWildcard
Bug: 183776809
Test: FrameworksNetTests:NetworkTemplateTest
Change-Id: I14d31071655204fe6ad36c71f7f521640e01c96e
Before sForceAllNetworkTypes is removed, the network
type and meteredness will be ignored when matchesMobile
or matchesMobileWildcard is called.
After sForceAllNetworkTypes is removed, the matches
method should check the network type and the meteredness.
Thus, if the test data contains different type or it's
not metered should not be counted.
Bug: 183776809
Test: FrameworksNetTests
Change-Id: Ie7194495d26c0f5ef7a247733f43c64688626c67
It is flaky and redundant, functionality is covered in
ConnectivityManagerTest
Bug: 191856806
Test: N/A
Change-Id: I786f69f6f6cfb73e99cc5dea867024007f44d134
OEM_NETWORK_PREFERENCE_TEST prefers NOT_METERED&VALIDATED networks
then TEST networks. If the WiFi isn't validated by the time the
preference is set, then the TEST network is preferred and the test
fails. The best solution is simply to wait for the WiFi network to
validate before setting the preference.
Besides, some of the *wait* methods wait for validation and some
don't, creating confusion. Make this explicit on the
setWifiMeteredStatusAndWait method with a boolean argument, which
forces all users to make an explicit choice.
testSetOemNetworkPreferenceForTestOnlyPref is not affected, as
it does not change WiFi meteredness.
Bug: 195365654
Test: testSetOemNetworkPreferenceForTestPref
Change-Id: Icb9d7ff1ca5c3d93286ea3a79c27f15630d17ee6
Suspended network should be considered as temporary shortage of
connectivity of a connected network. Thus, it should not be
excluded from network state snapshots and causes data usage to
stop accounting or iptables rules to be removed on the interface
of the suspended network.
This change also address the naming confusion of default networks
parameter of expectNotifyNetworkStatus.
Test: atest ConnectivityServiceTest#testGetAllNetworkStateSnapshots
Bug: 196079981
Change-Id: I8096356f9a472fb1c1246fbdf3fd5f981387fb1c
- This method always reuturns false which is not able to use for
testing.
- Use test restricted network for testing instead.
Bug: 183485986
Test: atest ConnectivityManagerTest
Change-Id: If34d4f1952162f118d53be8074a96b07415a5c85
- This is a test only change.
- Remove calling startMonitoring() in setup() because this method
should be called only once, so each test needs to call
startMonitoring() if the testing function is running on it.
- Return empty list instead of null when getting installed
pacakges in setup(). This can help test to have default user
MOCK_USER1 when they call startMonitoring().
Bug: 192431153
Test: atests FrameworksNetTests
Change-Id: Id2ffb056b378873c3ba6a8bb31b7dedb56ad6d46
- Some code are used many times, it's better to make them as
common code for reducing inconsist behavior.
- Also stop using Boolean to represent network permissions and
replace them with int value. Because using Boolean for
permission comparison is really complicated and bizarre.
- Use PERMISSION_* for netd network permission directly.
Bug: 189705071
Test: atests FrameworksNetTests
Change-Id: I2a4e298b9a01f4b2874ae68e9d9539a0ab4aff4c
The point is to help with debugging flakes of this test by
clarifying the timing of these calls with respect to when
NetworkMonitor reads the settings and the values it obtains.
Test: CaptivePortalTest
Change-Id: I29ac1d8cff1f96c91be2459e9a8f34f8ba1f38e3
The test flakes with UnfinishedStubbingException, but the root cause
could not be identified. Add some logging to try to get more information
when that happens.
Bug: 195626111
Test: atest ConnectivityServiceTest
Change-Id: If12c1ea809789148ca9251386e5ee6ca6d74ff74
Some uids should be app ids, correct them for avoiding confusion
and incorrect use.
Bug: 189705071
Test: atests FrameworksNetTests
Change-Id: I4a5930e5dc63b4d901e1567f8935ad7203866c89
- This is a test only change.
- Some methods are very similar and duplicated. So merge them to
improve readability and reduce code complexity.
- Stop spying PermissionMonitor.
Bug: 189705071
Test: atests FrameworksNetTests
Change-Id: I8ec17bd2d396c4d49dd8b64be85d89d0145f4c3c
- Rename the conntrack destination port check function
- Use CollectionUtils.contains to check the denied ports
- Add tests for the streams with ftp and pptp tcp port are
not able to be offloaded
Bug: 195914327
Test: atest TetheringCoverageTests
Change-Id: I7e2591bea1f6db46271efb0c30970fb8d4efe1e4
The test may be run on S builds older than itself, in which case the
resource ID may not match. Query the resource ID dynamically instead of
using the constant.
IpSecAlgorithm is not updatable in S, which is why it can use
hidden/unstable platform resources, so the test could also be skipped
altogether on S. But considering that keeping it around is not very
costly yet, this change fixes it for running on S.
Bug: 197489543
Test: atest IpSecAlgorithmTest
Change-Id: I533eede3a360a8db9089e65e017b9d7453b35539
The correct return code to keep on processing any further TC
attached programs is 'TC_ACT_PIPE' and not 'TC_ACT_OK' (which
is terminal).
Without this the ipv6 tether offload program causes termination
of processing and the ipv6 clatd offload program never actually
handles any packets (while tethering is active).
This results in lack of bpf xlat64 offloading for tethered ipv4
traffic on an ipv6-only (cellular) network.
This in turn means incoming TCP packets get GRO'ed, do not get
bpf offloaded, and get delivered to the clat daemon, which
due to them being bigger than the mtu (due to gro) cannot
handle them and discards them.
This results in poor performance, since tcp falls back to 1 mss/mtu
sized packet per rtt.
Tested via tethering a linux laptop on an ipv6-only cellular connection
and downloading the linux kernel from kernel.org via 'wget -6' and 'wget -4'.
Before:
IPv6: over 2MB/s, observed:
5805 packets, including 4 sackOK
IPv4: under 1MB/s, observed:
9300 packets, including 8 sackOK, 387 sack 1, 501 sack 2, 2310 sack 3
After:
IPv6: over 7MB/s, observed:
16702 packets, including 4 sackOK
IPv4: over 9MB/s, observed:
32755 packets, including 2 sackOK
Test: builds, TreeHugger, see above
Bug: 195624908
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I623dacb5a37dc689cea34499c3906c11fcaf946c
This test fails on devices where physical Ethernet interfaces are
available but marked restricted, like cuttlefish.
Bug: 197462993
Test: test-only change
Change-Id: I15c991b2e43e2d5e823dcdcfbd74adfd9b2f6f08
Bypass the IPv4 TCP packets with port 21 (ftp) and 1723 (pptp) from
BPF offload because these packets need the netfilter conntrack helper.
Bug: 195914327
Test: manual test as the follows
1. Connect to ftp.slackware.com with port 21 in active mode.
2. Check the PORT command success.
Command: PORT 192,168,62,128,174,17
Response: 200 PORT command successful.
3. Download a file.
Change-Id: I8e3b8d9323eb0e572f20c74442b55d4ee95abc2f
When the avoidBadWifi configuration is false and not overridden,
a WiFi network that was validated in the past but becomes
unvalidated needs to outscore a cell network that is validated.
This is happening correctly when the stack compares two networks.
However, when the stack compares an existing network to an offer
for a cellular network, the offer was automatically considered
not to yield. This would mean the stack would be requesting cell
out of the telephony factory, only for that network to lose to
WiFi and be discarded immediately, then recreated again etc.
When there is some other reason cell should be up (such as the
"mobile always on" setting being active), this would not be
visible because the cell network would have another reason not
to be torn down.
Have offers correctly account for the current value of the
configuration and setting. This has the ranking of the offer
lose against WiFi like the actual network loses, meaning the
offer is not needed.
This also requires updating the offers whenever the value of
the setting changes.
Test: new test for this, also ConnectivityServiceTest
Bug: 195441367
Change-Id: I4fe5de98bc15bcf9bbbe25c6c7c8a7ba382f8db7
The test actually verifies multiple behaviors and mutates the
networkCapabilities. Thus, refactor the method to keep the
tests easier to follow up.
Bug: 191918212
Test: atest android.net.NetworkCapabilitiesTest
Change-Id: Ibad1a0569d26d92f94153bee323cef5a1c30d8d4
This test requires a cell network so the test will be failed if
the device does not support telephony. Add a condition to check
if the device supports telephony and skip cellular battery stats
test if telephony is not supported.
Bug: 196231205
Test: atest CtsNetTestCases:BatteryStatsManagerTest
Change-Id: I9ddc1da2a3f83f3fd2ab59059185f2f7a8d08701
