When the avoidBadWifi configuration is false and not overridden,
a WiFi network that was validated in the past but becomes
unvalidated needs to outscore a cell network that is validated.
This is happening correctly when the stack compares two networks.
However, when the stack compares an existing network to an offer
for a cellular network, the offer was automatically considered
not to yield. This would mean the stack would be requesting cell
out of the telephony factory, only for that network to lose to
WiFi and be discarded immediately, then recreated again etc.
When there is some other reason cell should be up (such as the
"mobile always on" setting being active), this would not be
visible because the cell network would have another reason not
to be torn down.
Have offers correctly account for the current value of the
configuration and setting. This has the ranking of the offer
lose against WiFi like the actual network loses, meaning the
offer is not needed.
This also requires updating the offers whenever the value of
the setting changes.
Test: new test for this, also ConnectivityServiceTest
Bug: 195441367
Change-Id: I4fe5de98bc15bcf9bbbe25c6c7c8a7ba382f8db7
The check intends to do the bit & operation. The net cap value
should be shifted against the original capabilities.
Also fix the typo in the method name.
Bug: 191918212
Test: atest FrameworksNetTests
Change-Id: I98396b2538f36fe8b29d27a544a2dfb3060bc9c5
The resolverOptions member of the ResolverParamsParcel has never
been set by AOSP code but was only used by OEMs modifying
DnsManager. Now that DnsManager is mainline code, this is no
longer possible. So the DNS resolver introduces a new
setResolverOptions IPC to allow OEMs to set the options and makes
the resolverOptions nullable.
Make DnsManager set resolverOptions to null, to ensure that when
DnsManager calls setResolverConfiguration, it does not overwrite
any options set by the OEM.
Bug: 194048056
Test: Device boots and has connectivity
Change-Id: I310a79521f5a365e50e2c65e9dd87d9b68f105d7
This reverts commit c4660c98f6a63a73df1a79c34fbbf2266a6b381e.
The reverted commit removed the POLICY_YIELD_TO_BAD_WIFI exclusive
bit from the EXTERNAL_POLICIES_MASK. The new policy calculation
is done by bitwise-or-ing with existing policy. If the
POLICY_YIELD_TO_BAD_WIFI was ever set to policy in the FullScore
, CS will not be able to remove the policy to reflect the avoid
bad wifi setting change since the result is always be true unless
the policy is updated from factories.
Eventually, the original commit is the intended design but current
design could not work well with it. Thus, revert it to keep the
control on CS now.
Bug: 195612849
Test: atest CtsNetTestCases FrameworksNetTests
Change-Id: I002e206ffd41796cb0996b9c559afed3d619b67c
Ignore-AOSP-First: Commit is only available in internal branch
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
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
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
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 flaky callstack shows that it hits the exception in the
initialization of HashSet. The mNetworkRequests is accessed in
the ConnectivityService handler thread except dump(). The
ConcurrentModificationException should not happen in the other
flow. Thus, retry to get the current requests when the dump()
hits the ConcurrentModificationException to prevent flaky test.
Bug: 188373832
Test: atest ConnectivityServiceTest#testDumpDoesNotCrash\
--iteration 100
Change-Id: I9625919faf947c9488764b92093ed8105271c927
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
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
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
Change-Id: I04fe3a77464d4cb02e7d53026f8f9a10bd0829e1
After moving all netlink-client stuff to frameworks/libs/net/common
and build it as an individual library, deprecate the netlink-client
lib and use net-utils-device-common-netlink instead.
Due to that the package name of netlink lib has changed, also update the
package name used in Tethering and ConnectivityService module.
Bug: 192535368
Test: atest TetheringTests TetheringIntegrationTests
Change-Id: Ic2078caf67a640836d98c5a2e4ca89939adcb896
ConnectivityService doesn't use it, and the NetworkAgent API
never set it. This case does not happen in pratice, so remove
the check.
Bug: 192611346
Test: atest FrameworksNetTests
Change-Id: I1f114c9b65050527378ee73bc86e4cda8868bca9
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
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.
Change-Id: Iadec66344d88bd80170cd5441270b768cdbe0917
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
