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
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
Change-Id: Ib5bd74d8cf973bf70d373dd63648c178fae0ebae
DisplayMetrics are used in some downstream branches and need to be
mocked. This avoids merge conflicts in NetworkNotificationManagerTest.
Partial cherry-pick of change IDs:
I35d28c8df341dbbac2774026c6ca749e296c0482
I1aeed1c79e4a829d8829eb08224f9b21fafc50fe
Test: atest NetworkNotificationManagerTest
Bug: 176239013
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Change-Id: I118ec1af615aef36293bf0b480389f766122ccab
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.
Change-Id: Ia482e6fbf2bf300ce6cbaca72810d394ed201b98
- This is a no-op refactor for reducing duplicated code.
- Add a global NetdMonitor which can use for every test.
- Statically import INetd permissions.
Bug: 189705071
Test: atests FrameworksNetTests
Change-Id: I78f4b46cce16ea7e25b67cf2e9470cb09f1c3e75
Ignore-AOSP-First: It's a part of security patches.
Bug: 191382886
Test: atest FrameworksNetTests:VpnTest
Change-Id: Ie9c0c626f404efe0dd6dc79ca891639bc224090a
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)
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
Change-Id: I82a28c37450146838410bf5a059aac295a985fca
Test: atest NsdManagerTest NsdServiceTest
Bug: 191844585
Change-Id: I3cf658498bef5755dcb01127a94fff913b6e6298
Ignore-AOSP-First: To avoid the side effect caused by automerger.
Instead of jarjaring the whole com.android.internal.util package, apply
the jarjar rules per-class. Jarjaring the whole package causes problems
in tests, as for example ConnectivityServiceTest depends on Vpn that
uses other internal utils as hidden API, and these should not be
jarjared.
Also avoid jarjaring INetdUnsolicitedEventListener which is used by
NetdEventListenerServiceTest, and ensure KeepalivePacketDataUtilTest
expects the right package name in toString.
Generally the problems appear because ConnectivityCoverageTests also
includes tests for classes that are not part of the connectivity module,
and use hidden APIs that refer to classes that should not be jarjared.
Some of the tests could be excluded from the coverage suite instead, but
keeping them is helpful for future modularization efforts.
Test: Build service-connectivity, dexdump classes and verify jarjared
atest ConnectivityCoverageTests
Change-Id: Id6b7e6833d49fa03d9442d7c1c3e4dc16fb48dfc
The hypothesis here is that some other thread is using
the mock between the call to when() and the call to
.thenReturn() a few lines above the failure. It's not
clear this is really the reason, but using this syntax
is safer anyway, so whether it fixes the issue or not
this is a good change.
Test: m FrameworksNetTests
Change-Id: I501d2ec8e794c67a53d7c84e290e4cc63481472d
Internal utils are generally jarjared by connectivity jarjar rules, but
ArrayUtils is not actually statically linked into the tests, so this
makes the ConnectivityCoverageTests fail. FrameworksNetTests has been
fine because it does not use jarjar, but does not exercise updated code
because of that.
Remove usage of the hidden utility, as there are reasonable alternatives
with non-hidden APIs that avoid other breakages long-term.
Bug: 187935317
Test: atest ConnectivityCoverageTests:ConnectivityServiceTest
Change-Id: I8ed85b941c3d1028771a5ac33196b1509a95789d
This CL updates ConnectivityService to do null checks on received
parameters when registering and unregistering ConnectivityDiagnostics
callbacks (and also when simulating Data Stalls).
Bug: 181583568
Test: atest ConnectivityServiceTest ConnectivityDiagnosticsManagerTest
Change-Id: I7f297f10bf8d379a5d33ca5e11ca1e12132ba3a5
- 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
- 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
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
* changes:
Apply jarjar rules on coverage tests
Re-skip connectivity unit tests before S
Move ConnectivityCoverageTests to general-tests
Fix ConnectivityManagerTest initialization on Q
Move test_mainline_modules to AndroidTest.xml
Add ConnectivityCoverageTests to postsubmit
Add connectivity coverage tests
Make tests compatible with mockito-extended
Fix KeepalivePacketDataUtilTest crash on eng build
Update connectivity TEST_MAPPING
Replace all FIRST_SDK_INT usage in Connectivity because it has
been renamed to DEVICE_INITIAL_SDK_INT.
Bug: 184735771
Test: m CtsNetTestCases
Merged-In: I2f155592b08cdbf259a00b035cacb37ca9847e72
(clean cherry-pick)
Change-Id: I2f155592b08cdbf259a00b035cacb37ca9847e72
