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
This test is flaky due to assertNoCallback(). Because this
method expects no any callback received but the wifi network
may update its capabilities during testing and trigger
onCapabilitiesChanged() to cause test failed. Thus, these
callbacks should be ignored in the tests.
Replace the assertNoCallback to assertNoCallbackThat with
callback type specified to deflake tests.
Also align the available callback verification in the test to
avoid confusion.
Fix: 198367703
Test: atest android.net.cts.ConnectivityManagerTest\
--iterations 20
Change-Id: Ifde5e9730823c3b6f32590cc436cc4ba11d2b36e
Instead of crashing when parceling the NetworkInfo object,
crash at the time the bad call is made.
Bug: 145972387
Test: FrameworksNetTests
Change-Id: If8b5fd3d7b800c97211bcd16c9a8c5812708d4ab
Previously, the caller can only know about the transport type of
the underlying network. The information might not be enough if
the device support WiFi STA+STA.
Thus, provide an API for the caller to get the correct underlying
network.
Bug: 191918368
Test: atest FrameworksNetTests:NetworkCapabilitiesTest
Change-Id: I7752b2356770f4572f6ca4cbaecaa45c09d6d72f
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
In coverage tests this seems to randomly fail, which suggests
some delay. Have a constant for timeout and increase its value
significantly where it makes no functional difference.
Test: FrameworksNetTests
Change-Id: I035d865f01688daf3bce30c5130ce550fa84b885
"when" is not thread-safe, as it relies on global state to find which
mock was called with the method to mock in its parameters.
This causes flakes where non-test code that interacts with the mock may
be called from another thread between the contents of "when" and the
"when" method another thread, causing UnfinishedStubbingExceptions or
other test errors. In particular
ConnectivityService#getNetworkCapabilitiesInternal was seen to be
wrongly identified as a mocking site for Dependencies.
Replace all usages with doReturn().when(mock).method() syntax, which has
better thread safety since global state is not necessary to tie the
mock, mocked method and return value.
Bug: 195626111
Test: atest ConnectivityServiceTest
Change-Id: I57c5ffb3b3f799fc59c3af4ccb323fb5d6794fad
Currently, there are some test for classes that are not in
connectivity module. If the platform code has a new change
that the test depends on it, then the test cannot verify the
behavior since the change does not exist in module branch.
This change moves the test for non-module classes out of
FrameworksNetTestsLib so that it doesn't go into coverage tests.
Then add those tests to FrameworksNetTests and use a variable
to enable/disable FrameworksNetTests which could minimize merge
conflicts.
Bug: 201265286
Test: make FrameworksNetTests
Change-Id: Ia9669da2c4d79054710e7f4173bc960e3f77f45a
Fixing the indentation for dumpsys CONNECTIVITY for per app network
info. Also updated to more clearly show when the active network is
currently tagged to the "no service network" for configured apps so as
to more clearly show intent to dumpsys consumers. Finally, correctly
showing profile network preferences which weren't being shown
previously.
Prior formatting with no per-app networks:
Current per-app default networks: Per-App Network Preference:
none
Updated formatting with no per-app networks:
Current network preferences:
Default requests:
Prior formatting with active per-app networks ("none" is shown in this
case since profile network preferences weren't correctly displayed):
Current per-app default networks: Per-App Network Preference:
none
Is per-app network active:
true
Active network: 100
Tracked UIDs:
{1100000-1199999}
Updated formatting with active per-app networks:
Current network preferences:
Profile preferences:
[[ProfileNetworkPreference user=UserHandle{11} caps=[ Capabilities:
INTERNET&TRUSTED&NOT_VCN_MANAGED&ENTERPRISE Uids:
<{1100000-1199999}>]]]
OEM preferences:
OemNetworkPreferences{mNetworkMappings={android.net.cts=-1}}
Mobile data preferred UIDs:
mMobileDataPreferredUids: {1, 2, 3}
Default requests:
Request: [uid/pid:1000/1423] - Satisfier: [100] Preference order: 10
Tracked UIDs:{1100000-1199999}
Bug: 189860802
Test: adb shell dumpsys connectivity
Change-Id: I5ed4bb83e9e5a4497f5019ab4e4c0f238989a246
PerUidCounter#transact is used to adjust the request counter for
the per-app API flows. Directly adjusting the counter is not
ideal however in the per-app flows, the nris can't be removed
until they are used to create the new nris upon set.
In fact, satisfiers are the info that new nris need reference.
Without satisfiers in new nris, the avaiable callbacks would be
sent to listeners agin when assign new satisfiers. Even the new
best networks are same as previous satisfiers, but the new nris
have lost those info if calling handleRemoveNetworkRequests()
before createPerAppCallbackRequestsToRegister().
However, removing satisfiers from nris is not necessary actually
because the CS will update the best network to nri when compute
network reassignment. It doesn't need to be cleared when
calling handleRemoveNetworkRequest(). Thus, keep that info and
adjust the sequence to remove nri first. The counter is still
correct and doesn't hit limit artificially.
Bug: 201648050
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I4cbc953def7866b23c2b8ebc8deaadf0ffc3b75d
