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
TetheringService call different Settings API to check write settings
permission between R and S.
Bug: 182211575
Test: install S module to R device and both run mts tests build with S
and R.
Change-Id: I3e7f6525e9776992bd96b17c132b749b12285bbd
Merged-In: I3e7f6525e9776992bd96b17c132b749b12285bbd
This is a no-op CL which add TetheringTester and move runDhcp related
logic to it.
Test: atest EthernetTetheringTest
Change-Id: Ib1c5647b2bd5a1b27c976450d3aa265aff8f5b70
The helper method in CtsNetUtils will not restore the private
dns hostname back if the device private dns mode is not strict
mode. It does not cause function break since the host
configuration is useful only when the private dns mode is in
strict mode. But tests should restore the setting back to its
old state to prevent break other tests or erase setttings.
Test: atest android.net.cts.ConnectivityManagerTest and
check if the private dns server configuration is
changed or not after testing
Change-Id: I7c85ddac7306c7c3eeac84679d96c4cfb11bd875
The registered listeners are added into internal ArrayMap as a
reference but are not removed when the listeners are
unregistered. The actions for registration should be done in
pairs.
Test: atest FrameworksNetTests
Change-Id: Id9e674f5104d1471dd81224b6a271a8a92172e34
