Rename net-module-utils-srcs to connectivity-module-utils-srcs.
This is done as the module utils are made specific to
service-connectivity to contain only classes used by
service-connectivity.
Bug: 192998401
Test: Tests prepared in next change
Change-Id: I354f4b84aa90cc12579c4db5479cf2de1dc9cf5d
- Add a new transport type for USB and a new network capability
to support automotive head unit.
- In order to pass DnsManagerTest#testTransportTypesEqual, Android.bp
needs to link to dnsresolver_aidl_interface-V8-java. That test checks
whether the TRANSPORT types defined in NetworkCapabilities are the
same as IDnsResolver.aidl.
(clean cherry-pick of change in downstream branch history, original
change ID before project move:
Iec2df09a776d779108f95098e01b7ffdf6f8867a)
Bug: 181742019
Test: atest FrameworksNetTests
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Change-Id: Ie438ec68577ebdaaf990795fa27f1169b0105411
When NetworkRequestInfo#binderDied is called in ConnectivityService,
only pass the NRI to handleRemoveNetworkRequest. This is to prevent a
potential crash when unlinkDeathRecipient is called twice for the same
NRI.
Also, as a cleanup, don't iterate mRequests in the log message on binderDied.
As per the bug, the chain of events leading to a potential crash are:
- `Connectivity.NetworkRequestInfo#binderDied()` is called for an NRI
tracking multiple `NetworkRequest` items. This can happen for a TRACK_DEFAULT
request filed by a UID on a different preference than the default, which
copies the request list.
- This in turn triggers multiple `EVENT_RELEASE_NETWORK_REQUEST` events
for the same NRI, one for reach `NetworkRequest` tracked.
- When handling `EVENT_RELEASE_NETWORK_REQUEST`, each `NetworkRequest`
that is passed in will then be used to look up the parent NRI that originally
sent it to be released.
- Therefore if an NRI was tracking three requests, it would trigger three
release network events, then each request would be used to look up the
same NRI again when handling said release event.
- Finally, `ConnectivityService.NetworkRequestInfo#unlinkDeathRecipient` is
called for the NRI in question. Using the scenario above, that means we could
call `unlinkDeathRecipient` multiple times for the same NRI if it was tracking
multiple network requests causing the associated crash.
- If `unlinkDeathRecipient` is called more than once for the same NRI, it will
cause the crash listed in this bug.
- The fix is to only call handleRemoveNetworkRequest for the NRI once. This
works since when removing the NRI, we iterate over all of its requests to
remove them. By only calling handleRemoveNetworkRequest once, it's ensured
`unlinkDeathRecipient` for this NRI as part of
`Connectivity.NetworkRequestInfo#binderDied()` is only called once and not
potentially multiple times.
Bug: 185541983
Test: atest FrameworksNetTests
Change-Id: I2a2ad4ec6d415423182a1856a898779203658f8b
- Each network preference has been assigned a priority value so
that netd can know which uid range rule has higher priority. So
remove the restriction that all network preferences are
exclusive.
- Add priority check when getting request for uid.
Bug: 171872461
Test: atest FrameworksNetTests
(cherry-pick from ag/14731887)
Merged-In: I6912db753c8b4a194aa7af92b01ca6dcfec10d8b
Change-Id: I6912db753c8b4a194aa7af92b01ca6dcfec10d8b
Replace network[Add|Remove]UidRanges to
network[Add|Remove]UidRangesParcel. The new methods are passing
NativeUidRangeConfig which contains priority value for each uid
range rules.
Bug: 171872461
Test: atest FrameworksNetTests
Test: atest HostsideVpnTests
(cherry-pick from ag/14911836)
Merged-In: I08bbdbcb8450b08e6208fa730137348550f9e3d2
Change-Id: I08bbdbcb8450b08e6208fa730137348550f9e3d2
testGetMultipathPreference assumes that wifi will auto-reconnect after
changing its metered status, but this is not necessarily the case if the
BSSID has been blocklisted after it failed validating too many times.
Call ensureWifiConnected to force wifi to reconnect before waiting for
it to become metered.
Bug: 190913510
Test: atest ConnectivityManagerTest
Change-Id: Iafe9837b97e4d654bb0f3962d48a94c1f31bbebc
qtaguid is long dead - test is thus a no-op
New test logs:
Running Tests...
x86 CtsNativeNetTestCases
-------------------------
CtsNativeNetTestCases (1 Test)
[1/1] BpfTest#bpfStructSizeTest: PASSED (0ms)
Summary
-------
x86 CtsNativeNetTestCases: Passed: 1, Failed: 0, Ignored: 0, Assumption Failed: 0,
All tests passed!
Test: atest CtsNativeNetTestCases, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I9ff784dbfda0ce981904d53eacb7bc831cbe81da
This test is required to ensure that the system is compatible
with future updates of the tethering mainline module, which
updates BPF .o files on device.
This test must already be passing on OEM devices because otherwise
the offload.o program in the Tethering mainline module would bootloop
the device.
Bug: 190519702
Test: atest CtsNativeNetTestCases, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ibaedb8fcb28591ffba1506514f2305d55712a26b
Connect can error with BUSY if the framework is busy when connect is
called. Add retries so that if this happens, the connection can succeed
after the framework stops being busy.
Also log the level of scan results when several configurations are
available, and clarify the legacy broadcast assert.
Bug: 188077861
Test: atest CtsNetTestCases
Change-Id: I99ce72bd2604489cb419ea9984643b6985728461
The internal structure backing getAllNetworks is updated after
invoking lost callbacks, so the test needs to wait for the handler
to be idle before calling getAllNetworks.
Also avoid assertions in finally clauses, as it causes confusing
error messages.
Bug: 185081944
Change-Id: I8ad5ab45a3e65b0031672e6f594b1a6d6ad5abcb
Test: atest ConnectivityServiceTest
The test relied on waitForIdle to ensure diagnostics callbacks were called,
but as this may require several iterations in the handler queue, this makes
the test unreliable.
Use mockito timeouts on the verify() calls instead.
Bug: 192651465
Change-Id: Iae1704af7ae3649eae301c6aee223ac753629d55
Test: atest ConnectivityServiceTest
Address a TODO to use WifiManager#connect to reconnect wifi, instead of
WifiManager#reconnect. #connect also clears the BSSID denylist; that
list has caused flakyness due to tests that cause the network not to
validate such as captive portal or invalid private DNS behavior tests,
causing wifi to ignore the access point in reconnect attempts.
Bug: 188077861
Test: atest CtsNetTestCasesLatestSdk
Change-Id: I5a11a802db8a4881c161e6038c1c183d2ac23a05
If config_tether_ncm_regexs is configured, load it to
tetherableUsbRegexs if ncm is used for TETHERING_USB. Load it to
tetherableNcmRegexs if ncm is used for TETHERING_NCM.
Bug: 185649441
Test: atest TetheringTests
Change-Id: I0c542560bd04e8c0a6a78d632da5a00a34d9a3fa
Before this change, usb IpServer would be created if corresponding
interface is available even there is no enable tethering attempt. And
usb IpServer only be disabled when interface is removed. Usb tethering
could not be stopped if interface is always avaialbe.
After this change, usb IpServer would be enabled and disabled according
to ACTION_USB_STATE.
Bug: 185649441
Test: atest TetheringCoverageTests
atest MtsTetheringTestLatestSdk
atest CtsTetheringTest
Change-Id: I8375e3f998d677dc658370b2553facaec0d5ff7c
- Some applications are installed on external storage and they
are unavailable until exernal storage installed them
completely. And their permission need update after becoming
available. Thus, listen EXTERNAL_APPLICATIONS_AVAILABLE intent
and update those package whose is listed in chaged package
list.
- Remove user argument on buildPackageInfo() because the uid on
ApplicationInfo is based uid.
Bug: 145234989
Test: atest FrameworksNetTests
Merged-In: Ia11ca4a7ba6fc1b87c27c0c40e36c91d9cdb322a
Change-Id: Ia11ca4a7ba6fc1b87c27c0c40e36c91d9cdb322a
Certain network types, like the VCN, have underlying
networks for the purpose of data usage, but do not want to
propagate the underlying network capabilities.
Allow these networks to set underlying networks, but continue
not to propagate the capabilities.
Bug: 190620024
Test: new unit test
Change-Id: I53d6080f48707ff3c37fbfbef534284ba77a7432
This change adds relevant tests for the migrateTun functionality in
NetworkStats.
Bug: 190620024
Test: atest NetworkStatsTest
Change-Id: I33f14f2d0f71013a594fd4c8c3914a590d30ea06
The utilities are part of com.android.internal.util, but were
historically tested as part of the services.net tests. They were then
mistakenly moved to packages/modules/Connectivity with the rest of the
networking code, but actually belong in coretests.
Bug: 187935317
Test: atest FrameworksCoreTests
Change-Id: I74702f6a4d9bed5985d2a830dacd78129a7854a8
Core platform API stubs are now correctly included in module_current and
system_server_current, so workarounds used to use such APIs can be
removed.
OsCompat and InetAddressCompat were only necessary because manually
adding the stubs did not resolve the problem for classes that had
public API stubs, which shadowed the module API stubs.
The manual stubs dependency was already removed in another change. Also
remove the service jar dependency on android_system_server_stubs_current
as it is already included in sdk_version system_server_current.
Bug: 183097033
Test: atest CtsNetTestCases
Change-Id: Id448be03b679f832edb24f1b77f471227faf5268
This CL updates ConnectivityDiagnosticsManagerTest to expect
NETWORK_VALIDATION_RESULT_SKIPPED for its TestNetworks. The tests also
expect a ConnectivityReport to be sent for all calls to
ConnectivityManager#reportNetworkConnectivity.
Bug: 162407730
Test: atest ConnectivityDiagnosticsManagerTest
Change-Id: I525ea22a38c54a6b5b969a70301852e7af12849c
This CL updates ConnectivityDiagnostics to report
NETWORK_VALIDATION_RESULT_SKIPPED when the platform does not validate
the reported Network. This CL also updates the behavior for
ConnectivityManager#reportNetworkConnectivity, such that it will always
generate a ConnectivityReport on the reported network. If the reported
connectivity does not match the known connectivity of this network, the
network is revalidated and a report is generated. Otherwise,
revalidation is not performed and the cached ConnectivityReport is sent
instead.
This CL also updates ConnDiags behavior for calls to
ConnectivityManager#reportNetworkConnectivity. Specifically, ConnDiags
callbacks are only notified for these calls if:
a) the call causes the Network to be re-validated, or
b) the callback registrant was the caller of
#reportNetworkConnectivity().
For b), the caller is always guaranteed to receive a ConnectivityReport
(a fresh report if the Network is re-validated, else the cached report).
Bug: 162407730
Test: atest FrameworksNetTests ConnectivityDiagnosticsManagerTest
Change-Id: I78b78919d5b0f09348dfdd5fdb37418b8c7f861f
