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)
Catch exception of unregisterNetworkCallback to
avoid reset operations afterwards being skipped by it.
Change-Id: Idb1161abfd143fb1305982338007dac169d372b5
Bug: 195364778
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
Needed because an invalid file descriptor should notify the caller to
stop using the object.
Bug: 190523685
Test: atest BpfMaptest
Change-Id: I70fb08b54b1c0caa4be4e3f07b59bf4f2397f39d
Instead, use a dedicated MockConnection class.
This should improve performance of the test, and works around failures
where mockito crashes when creating mocks when openConnection is called.
The failures are believed to be a bug in mockito-extended, but are not
likely to be fixed soon.
Bug: 185083316
Test: atest FrameworksNetIntegrationTests
Change-Id: I32deaaaaa5ce9876611314c8e8b9d8bdd6325df0
Using jarjar on intermediate libraries causes issues when they are
combined with other libraries that use different jarjar rules, as the
resulting binary may contain multiple incompatible copies of the
classes. Instead, jarjar should be used on the final artifact, after
combining the libraries.
Ensure NetworkStackJarJarRules is not applied on intermediate libraries
like TetheringIntegrationTestsLib, but instead apply it on
TetheringIntegrationTests or CtsTetheringTest.
Bug: 192535368
Test: atest TetheringCoverageTests TetheringIntegrationTests \
CtsTetheringTest
Change-Id: I248a533651984de81f676336c0e74e3788610bbb
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
Wifi is not guaranteed to connect by just disabling airplane mode
or turning on wifi. Use ensureWifiConnected in the test to force
the test to reconnect to its access point.
Bug: 194413134
Change-Id: I82540a3c6fa1d50ffa39e925bdb3d214876e2083
Test: atest ConnectivityManagerTest
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
- 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
