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
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
Change-Id: I918c8620f2975d810894c178277771764923b5a4
Test: atest FrameworksNetTests
Merged-In: I2a2ad4ec6d415423182a1856a898779203658f8b
- 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
Unfortunately, this could happen if there is a delay in updating the
network rules for the app hosting the job.
Bug: 179319857
Test: atest tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Change-Id: I60cfd5c5946a4cd0ef5ebf0c1e56b0667cc3164d
Ignore-AOSP-First: Expedited jobs are not available in AOSP yet
- 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
- 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
Ignore-AOSP-First: Needs cherry-picks
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>
Original-Change: https://android-review.googlesource.com/1756440
Merged-In: Ibaedb8fcb28591ffba1506514f2305d55712a26b
Change-Id: Ibaedb8fcb28591ffba1506514f2305d55712a26b
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
