The resources may have different values depending on devices, and
resources IDs may mismatch if the test was not built at the same time as
the installed module, so mock the resources to allow running the
integration tests on more builds.
Bug: 193847396
Test: atest FrameworksNetIntegrationTests
Ignore-AOSP-First: cherry-pick created
Change-Id: Ic33d897690a8ea84a78c01dc5f2b2e2c473d57df
The crash occurs when some app has more than half its limit
in requests that will need to be moved to some other default
network upon changing the preferences.
This will send the requests for this app over the limit
temporarily when creating new requests for the reevaluated
ones.
While ConnectivityService has a provision for making a
transaction-like addition/removal of requests that is meant
to avoid exactly this kind of crash with the transact()
method on PerUidCounter, the code only transacts on
mSystemNetworkRequestCounter. But these requests are counted
in the mNetworkRequestCounters, which is not part of the
transaction, causing the crash anyway.
To avoid the problem, this patch allows the request counters
to go over the max if and only if the system server is
updating the request counts for a UID other than its own.
This should allow only the case where ConnectivityService is
moving the requests over to the new per-uid default, while
keeping the exception when registering from an app (then the
calling UID is not the system server), or when the system
server registers its own requests (then the UID inside the
request is that of the system server).
A much better solution than this patch would be to completely
eliminate the transact() method by somehow unregistering the
old ones before creating the new ones.
However this would be a much bigger and difficult patch than
this, and much more dangerous, because callers depend on the
list of requests to find out the old requests to remove, so
they have to be created first.
Another possible clean solution would be to count the
requests not in the NRI constructor, but later. This would be
more error-prone though because it would be very easy to
create an NRI without counting it.
Bug: 192470012
Test: ConnectivityServiceTest. Improve tests so they catch
this case.
Original change: https://android-review.googlesource.com/c/platform/packages/modules/Connectivity/+/1781202
Merged-In: Ia482e6fbf2bf300ce6cbaca72810d394ed201b98
Change-Id: I6744d2f60d6bd664f048b532a58461c110a5b7fe
(cherry picked from commit 916aeb7b0d)
Add an option to display the no internet dialog directly instead of
showing a notification when the notification would have been high
priority (typically when the network was explicitly selected). This is
disabled by default, but allows device manufacturers to use a slightly
more disruptive UX to ensure that the user is aware that the network has
no connectivity, and can take action.
Also add an option to show the same notification as "no internet"
instead of the "partial connectivity" notification. This is also
disabled by default, but allows device manufacturers to use the "no
internet" text if they feel that "partial connectivity" text is hard
to understand for the user.
Bug: 193847396
Test: atest NetworkNotificationManagerTest
Original-Change: https://android-review.googlesource.com/1782433
Merged-In: Ib5bd74d8cf973bf70d373dd63648c178fae0ebae
Change-Id: Ib5bd74d8cf973bf70d373dd63648c178fae0ebae
If the test passes uid from another user which requires
INTERACT_ACROSS_USERS_FULL permission to bind service.
Bug: 192114565
Test: atest CtsNetTestCases:PacProxyManagerTest
Original-Change: https://android-review.googlesource.com/1755050
Merged-In: I2ddff09b4c9cda1e7c5f3566662ba9cc07fffaae
Change-Id: I2ddff09b4c9cda1e7c5f3566662ba9cc07fffaae
The scenario is as follows : an app registers a network callback,
then unregisters it and dies immediately after. In this scenario,
the system server will receive a notification of the binder death
and enqueue a call to handleRemoveNetworkRequest. If the callback
unregister message has been process first, this call would result
in unlinkToDeath being called twice on the same Binder, crashing.
This patch fixes the problem by using handleReleaseNetworkRequest
instead of Remove, which looks up the NRI in a map on the handler
thread before calling Remove, returning without doing anything if
the NRI has already been removed.
Test: ConnectivityServiceTest
Test: New test for this
Bug: 194394697
Merged-In: I82a28c37450146838410bf5a059aac295a985fca
Change-Id: Iddab205cf2754d326be816e6e8e92c2cc0b95771
(cherry picked from commit d79bd5c622)
Bug: 177931370
Test: atest tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Ignore-AOSP-First: Platform changes related to this are not in AOSP yet.
Change-Id: I6d525c4d88ba01838d51a873251593281b628898
aosp/1770606 change uid to appId when filling allowed on
restricted networks uids list. So add UserHandle.getAppId() to
ensure that uses appId for looking up the list.
Bug: 192116643
Test: atest FrameworksNetTests
Original-Change: https://android-review.googlesource.com/1773886
Merged-In: I04fe3a77464d4cb02e7d53026f8f9a10bd0829e1
Change-Id: I04fe3a77464d4cb02e7d53026f8f9a10bd0829e1
In China, "https://www.google.com" will redirect to url
"http://www.google.cn" but cleartext traffic is default disabled
for an app. So the testDownloadWithDownloadManagerDisallowed
would failed by cleartext traffic is not permitted. Thus, change
the url in the test which is reachable in China.
Bug: 192978910
Test: atest HostsideVpnTests#testDownloadWithDownloadManagerDisallowed
Original-Change: https://android-review.googlesource.com/1771008
Merged-In: I992c3240f0e133f5b00468cbe85d1545bcf786b0
Change-Id: I992c3240f0e133f5b00468cbe85d1545bcf786b0
Test: atest NsdManagerTest NsdServiceTest
Bug: 191844585
Change-Id: I3cf658498bef5755dcb01127a94fff913b6e6298
Ignore-AOSP-First: To avoid the side effect caused by automerger.
The test failed because the test generated traffic
before the unplug command really done.
The unplug command will eventually have onBattery changed
to true. If the traffic is generated before onBattery changed
to true, then the cellular stats won't be updated. And then,
when BatteryStatsService schedules a sync task to update the
stats which will get no delta because the stats on cellular
has already added to mLastModemNetworkStats. Thus, the test
will finally get failed.
Currently, the battery unplug command is executed after connecting
to cellular network and making sure wifi is disconnected which may
trigger battery stats service schedules sync tasks. If there are
too many tasks need to run, then change onBattery to true would
be later. Thus, move the unplug command to the beginning of the
test and add "dumpsys batterystats --write" which will wait for the
worker to finish the task before continuing. Thus, it can make sure
the batterystats are synced.
Also, the stats will be reset when the devices are unplugging after
the battery was last full or the level is 100, or have gone through
a significant charge. So, enable no-auto-reset to avoid the stats
getting reset during the test.
Bug: 192808200
Test: atest CtsNetTestCases:BatteryStatsManagerTest
Original-Change: https://android-review.googlesource.com/1769295
Merged-In: I08b38d9955c8cbb2d680e268c29368a4c0a7d144
Change-Id: I08b38d9955c8cbb2d680e268c29368a4c0a7d144
This CL is subject to be reverted in a few days when the prebuilt
Connectivity module is updated.
Ignore-AOSP-First: This is for sc-dev and its downstreams only
Test: android.net.NetworkProviderTest
Bug: 189074532
Change-Id: I512552400960668c0ba91a8d997d1e2747209538
Currently, to prevent from network connect-teardown-loops that
caused by inaccurate reports, e.g. the provider always provides
a better network than the offer, the NetworkOffer is considered
needed if its provider is currently serving the request. This
is because there is no accurate way to know whether the offer is
corresponding to the network that is currently serving the
request.
However, if the offer cannot even satisfies the request, consider
the offer is needed does not make any sense. Since it can
never be the one that currently serving the request, nor be
the one that might beat current satisfier.
Test: android.net.NetworkProviderTest
Bug: 189074532
Original-Change: https://android-review.googlesource.com/1731452
Merged-In: Ie3ea59f980c3767782b8e6b03e401c02f664f9bd
Change-Id: Ie3ea59f980c3767782b8e6b03e401c02f664f9bd
Due to b/192431153, PermissionMonitor only apply permission to
app id which is listed in settings. Thus, temporarily change uid
to appId.
Bug: 192116643
Test: atest ConnectivityManagerTest#testUidsAllowedOnRestricted\
Networks with system & secondary user.
Original-Change: https://android-review.googlesource.com/1770606
Merged-In: Iadec66344d88bd80170cd5441270b768cdbe0917
Change-Id: Iadec66344d88bd80170cd5441270b768cdbe0917
Bpf offload do not support VCN network yet, don't start bpf offload
if the interface is ipsec*.
Bug: 191178945
Test: atest TetheringTests
Original-Change: https://android-review.googlesource.com/1764307
Merged-In: I1ad8cededddec42f45b08aaa31d583c548d105f0
Change-Id: I1ad8cededddec42f45b08aaa31d583c548d105f0
This ensures classes are used from the service-connectivity jar, instead
of using classes from the system_server bootclasspath when there is a
name conflict.
Any developer adding a future class should do so in a subpackage of
com.android.connectivity (such as com.android.connectivity.server).
Otherwise, jarjar rules need to be added manually until b/180995093 is
fixed.
Also update current jarjar rules so that classes are jarjared to
com.android.connectivity.[original name], making it easier to find the
original source. This is consistent with the wifi module.
Bug: 193086215
Test: atest CtsNetTestCases
dexdump on service-connectivity.jar shows no classes outside of
com.android.connectivity and com.android.server
Original-Change: https://android-review.googlesource.com/1759589
Merged-In: I2aadeca32751267b74d4fd2fd93bb3e8c62e46c0
Change-Id: I2aadeca32751267b74d4fd2fd93bb3e8c62e46c0
Currently netd supports only the default value for VPN but CS
send priorty value 1 to netd. It will break the default routing
for VPN. Thus, update network preference priority value to 0 for
VPN.
Bug: 193245476
Test: atest CtsHostsideNetworkTests:HostsideVpnTests
Original-Change: https://android-review.googlesource.com/1762867
Merged-In: I197cb358e8e30355fbf675e4c623abebe7abdb7f
Change-Id: I197cb358e8e30355fbf675e4c623abebe7abdb7f
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
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
Ignore-AOSP-First: Needs cherry-picks
Change-Id: I6912db753c8b4a194aa7af92b01ca6dcfec10d8b
