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
Merged-In: 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
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)
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
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
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
- 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
* 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
Apply their respective jarjar rules on tethering and general
connectivity tests, then merge both into the coverage tests suite.
This is necessary to ensure that classes covered by tests have names
matching classes used in code.
Also fix IpConnectivityLogTest to use the module utility instead of the
hidden BitUtils, as the test would fail after internal utils are
jarjared.
Bug: 187935317
Test: atest ConnectivityCoverageTests TetheringCoverageTests
Original-Change: https://android-review.googlesource.com/1749680
Merged-In: Ib95b58dab93f7adebc445b662a6d15db1ce0e7c2
Change-Id: Ib95b58dab93f7adebc445b662a6d15db1ce0e7c2
Certain network types, like the VCN, have underlying
networks for the purpose of data usage, but do not want to
propagate the underlying network capabilities.
Allow these networks to set underlying networks, but continue
not to propagate the capabilities.
Bug: 190620024
Test: new unit test
Original-Change: https://android-review.googlesource.com/1753619
Merged-In: I53d6080f48707ff3c37fbfbef534284ba77a7432
Change-Id: I53d6080f48707ff3c37fbfbef534284ba77a7432
Core platform API stubs are now correctly included in module_current and
system_server_current, so workarounds used to use such APIs can be
removed.
OsCompat and InetAddressCompat were only necessary because manually
adding the stubs did not resolve the problem for classes that had
public API stubs, which shadowed the module API stubs.
The manual stubs dependency was already removed in another change. Also
remove the service jar dependency on android_system_server_stubs_current
as it is already included in sdk_version system_server_current.
Bug: 183097033
Test: atest CtsNetTestCases
Original-Change: https://android-review.googlesource.com/1754889
Merged-In: Id448be03b679f832edb24f1b77f471227faf5268
Change-Id: Id448be03b679f832edb24f1b77f471227faf5268
- If Mobile data always on is OFF, mobile data preferred uids
feature does not work.
- We need to request mobile data when MDO list is not empty.
Bug: 171872461
Test: atest FrameworksNetTests
Test: atest CtsNetTestCases
Signed-off-by: Ansik <ansik.shin@samsung.com>
Original-Change: https://android-review.googlesource.com/1751023
Merged-In: Ie9d6b3e39ef16813c4be3979900d226c8f3d656d
Change-Id: Ie9d6b3e39ef16813c4be3979900d226c8f3d656d
Allow overlays to change the connectivity notification icons, and
whether the notifications are auto-cancelled.
This does not change default behavior, but is necessary to allow vendors
to adapt the notifications to their standards.
Bug: 173171709
Bug: 172048052
Test: atest NetworkNotificationManagerTest
Added test overlay, verified icon replaced
Original-Change: https://android-review.googlesource.com/1753822
Merged-In: Ibbb765a5e828b8b870cbfb81e89df2dbd2828be7
Change-Id: Ibbb765a5e828b8b870cbfb81e89df2dbd2828be7
Previously, the return condition in stop() will check if the state
is STOPPING and the reason is ERROR_INVALID_NETWORK. The condition
is too restricted so that if another event is happened after binder
died, the exception will be thrown and crash the system.
Since calling stop() twice doesn't make sense, so relax the condition
of return when the state is STOPPING.
Bug: 182586681
Test: atest FrameworksNetTests
Original-Change: https://android-review.googlesource.com/1729690
Merged-In: I2454c1c080d8954dd3785d4ac6e96fc4131fdb47
Change-Id: I2454c1c080d8954dd3785d4ac6e96fc4131fdb47
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
Ignore-AOSP-First: Need cherry-pick
Change-Id: I08bbdbcb8450b08e6208fa730137348550f9e3d2
Currently, ConnectivityService uses EVENT_REGISTER_NETWORK_LISTENER
to dispatch registering network callback with pending intent, this
is wrong since the code flow will not check if the pending intent
is duplicated. Thus, the registration will be duplicated if the
caller uses the same pending intent and register multiple times.
This change fixes the logic by using
EVENT_REGISTER_NETWORK_LISTENER_WITH_INTENT instead of
EVENT_REGISTER_NETWORK_LISTENER when dispatching register network
callback with pending intent.
Test: atest android.net.cts.ConnectivityManagerTest#testRegisterNetworkRequest_identicalPendingIntents
Test: atest android.net.cts.ConnectivityManagerTest#testRegisterNetworkCallback_identicalPendingIntents
Test: atest ConnectivityServiceTest#testNetworkCallbackMaximum
Test: 1. Use test app to file callback with same PendingIntent
2. Check dumpsys output
Bug: 189868426
Original-Change: https://android-review.googlesource.com/1727470
Merged-In: I38bdea3a026a78a6dc34b5200d43a75b3cd1ac0c
Change-Id: I38bdea3a026a78a6dc34b5200d43a75b3cd1ac0c
- Some applications are installed on external storage and they
are unavailable until exernal storage installed them
completely. And their permission need update after becoming
available. Thus, listen EXTERNAL_APPLICATIONS_AVAILABLE intent
and update those package whose is listed in chaged package
list.
- Remove user argument on buildPackageInfo() because the uid on
ApplicationInfo is based uid.
Bug: 145234989
Test: atest FrameworksNetTests
Ignore-AOSP-First: Need cherry-pick
Change-Id: Ia11ca4a7ba6fc1b87c27c0c40e36c91d9cdb322a
Multiple user's ares of mApps are not initialized in startMonitoring(),
so mApps.get(uid) of multi-user's app returns null in onPackageAdded().
As the result, permission of system uid is updated to "Network" and
any system application cannot use dedicated apn like IMS.
Using appId avoids this problem.
Bug: 168932048
Test: atest FrameworksNetTests
Signed-off-by: Sangcheol Lee <goodsc.lee@samsung.com>
Original change: https://android-review.googlesource.com/c/platform/packages/modules/Connectivity/+/1733212
Merged-In: Ib8ea2185d8056bddb2ca5a8006f83afb3cffc9f4
Change-Id: Ib8ea2185d8056bddb2ca5a8006f83afb3cffc9f4
In S ConnectivityService was changed to use getActiveRequest() to fill
EXTRA_NETWORK_REQUEST, but there is no active request in the case of
listens.
When getActiveRequest() is missing, use the first mRequest instead. This
should match previous behavior.
Bug: 191713869
Test: atest android.net.cts.ConnectivityManagerTest
Original-Change: https://android-review.googlesource.com/1748153
Merged-In: Id7343a4cc020aba16b7979b16334721c56b2839c
Change-Id: Id7343a4cc020aba16b7979b16334721c56b2839c
ConnectivityManager.setAvoidUnvalidated only works if the
config_networkAvoidBadWifi configuration is set to 0 and the
NETWORK_AVOID_BAD_WIFI setting is unset. There is no easy way
for a testing app to temporary set a test value to verify the
behavior of the API. Thus, add a mechanism to allow test app
to set a period of time to temporary unstrict the resource
configuration, i.e. Temporary simulate config_networkAvoidBadWifi
configured to 0.
Bug: 186061922
Test: atest CtsNetTestCases FrameworksNetTests
Original-Change: https://android-review.googlesource.com/1733788
Merged-In: If772078c61a9b12926f104d5dfc9c9071e844732
Change-Id: If772078c61a9b12926f104d5dfc9c9071e844732
To allow unit tests to run without platform certificates, remove
signature permission usage in ConnectivityServiceTest.
This mocks permission checks done in ConnectivityService for which the
test assumed that the permission was held, and mocks calls to
BatteryStatsManager. Calls to ActivityManagerService (through
PendingIntent) are done with shell permissions as the test uses real
PendingIntent mechanics.
Bug: 187935317
Test: atest FrameworksNetTests
Merged-In: If309d653ac2e9bbcf1b94bcee6336367289df359
Change-Id: If309d653ac2e9bbcf1b94bcee6336367289df359
Original change: https://android-review.googlesource.com/c/platform/packages/modules/Connectivity/+/1736615
(cherry picked from commit 595dda3604)
Change-Id: Idb19b0f7cb87bb4d9de7a0b1a0e4128c2d6b9c6d
When the apps moved from/to a VPN, a proxy broadcast is needed to
inform the apps that the proxy might be changed since the default
network satisfied by the apps might also changed.
Since the framework does not track the defautlt network of every
apps, thus, this is done when:
1. VPN connects/disconnects.
2. List of uids that apply to the VPN has changed.
While 1 is already covered by the current design, the CL implements
2 in order to fulfill the case that different networks have
different proxies.
Bug: 178727215
Test: atest FrameworksNetTests
Original-Change: https://android-review.googlesource.com/1717735
Merged-In: Ifa103dd66394026d752b407a1bee740c9fcdad2b
Change-Id: Ifa103dd66394026d752b407a1bee740c9fcdad2b
Updates to ConnectivityService so that the set OEM network preference
per app APIs can be tested via CTS.
Bug: 176496580
Bug: 176494815
Test: atest FrameworksNetTests
atest FrameworksNetIntegrationTests
atest CtsNetTestCasesLatestSdk
Original-Change: https://android-review.googlesource.com/1723050
Merged-In: I5a47dcece31749293f080af060218d827082eb67
Change-Id: I5a47dcece31749293f080af060218d827082eb67
Per-app network functionality assumed all apps were installed for user 0
which is not always the case. This fix will address that by checking for
the existance of an app for all users and adding it to the per-app
network preference as was originally intended. Prior, no apps were
included if they were not installed for user 0 even if they were
available for another user such as user 10 in automotive.
Bug: 189838408
Test: atest FrameworksNetTests
atest FrameworksNetIntegrationTests
atest CtsNetTestCases
Original-Change: https://android-review.googlesource.com/1723617
Merged-In: I7d75cdb02041e7a202254be2eaeca6c2b02d7c29
Change-Id: I7d75cdb02041e7a202254be2eaeca6c2b02d7c29
This CL updates TestNetworkService to fully setup test TUN
interfaces when created. Previously, the interface was only
created in netd when the Test Network was created.
Bug: 182291467
Bug: 189125789
Test: atest Ikev2VpnTest IpSecManagerTunnelTest
Change-Id: I4c1262e566517bbb03dd610f595e4d18bc4e7735
Merged-In: I4c1262e566517bbb03dd610f595e4d18bc4e7735
(cherry picked from commit 615237a818)
Currently, when a network that uses 464xlat is torn down,
NetworkCallbacks will receive onLinkPropertiesChanged after
onLost. This is confusing and incorrect.
The incorrect callback is sent because handleLinkProperties
checks that the netId of the agent still exists, not that the
NetworkAgent is still registered. This is normally correct,
because the NetworkAgent is removed from mNetworkAgentInfos and
the netId are removed from mNetworkForNetId by the same method,
disconnectAndDestroyNetwork.
In this specific case it's not correct, because the call to
handleUpdateLinkProperties is from disconnectAndDestroyNetwork
itself via nai.clatd.update and calls Nat464Xlat#stop.
No other callers of handleUpdateLinkProperties are affected
because:
- EVENT_NETWORK_PROPERTIES_CHANGED is called only by
maybeHandleNetworkAgentMessage, which first checks that the
NetworkAgent is registered.
- handlePrivateDnsSettingsChanged only looks at registered
NetworkAgents (it loops over mNetworkAgentInfos).
- handlePrivateDnsValidationUpdate, handleNat64PrefixEvent and
handleCapportApiDataUpdate call getNetworkAgentInfoForNetId,
which will correctly determine that the agent is no longer
registered, since they run on the handler thread and thus
cannot run at the same time as disconnectAndDestroyNetwork.
The existing code contains a check for the netId being current.
This is intended to ensure that an update from a NetworkAgent
cannot affect another agent with the same Network. This extra
check is not necessary, because code running on the handler
thread can never observe a NetworkAgent in mNetworkAgentInfos
unless mNetworkForNetId maps that NetworkAgent's Network to that
NetworkAgent. This is because mNetworkForNetId is updated by the
same methods as mNetworkAgentInfos, and those updates occur on
the handler thread. So all code on the handler thread will see
those two as consistent.
Bug: 176496580
Test: atest FrameworksNetTests CtsNetTestCases HostsideVpnTests
Original-Change: https://android-review.googlesource.com/1727829
Merged-In: I944f4c6ad36206bdccd85a6ea7ef71324a29c685
Change-Id: I944f4c6ad36206bdccd85a6ea7ef71324a29c685
- Add default network priority to NetworkRequestInfo.
- The default network priority value is used when issue uid
ranges rules to netd. Netd will use the priority value and uid
ranges to generate corresponding ip rules specific to the given
network preference.
Bug: 171872461
Test: atest FrameworksNetTests
Ignore-AOSP-First: Needs cherry-picks
Change-Id: I0ea71b348492aeb4784d487bed4cfd5d387426ba
- Add more tests for mobile data preferred uids.
- Also address leftover comments on implementation commit.
Bug: 171872461
Test: atest FrameworksNetTests
Ignore-AOSP-First: Needs cherry-picks
Change-Id: I63f65bffc1b8883ddfd774222e26e629d7ea1f94
