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
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 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
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
Test: atest FrameworksNetTests
Change-Id: 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
(cherry-pick from ag/14731887)
Merged-In: I6912db753c8b4a194aa7af92b01ca6dcfec10d8b
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
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
Change-Id: I53d6080f48707ff3c37fbfbef534284ba77a7432
This CL updates ConnectivityDiagnostics to report
NETWORK_VALIDATION_RESULT_SKIPPED when the platform does not validate
the reported Network. This CL also updates the behavior for
ConnectivityManager#reportNetworkConnectivity, such that it will always
generate a ConnectivityReport on the reported network. If the reported
connectivity does not match the known connectivity of this network, the
network is revalidated and a report is generated. Otherwise,
revalidation is not performed and the cached ConnectivityReport is sent
instead.
This CL also updates ConnDiags behavior for calls to
ConnectivityManager#reportNetworkConnectivity. Specifically, ConnDiags
callbacks are only notified for these calls if:
a) the call causes the Network to be re-validated, or
b) the callback registrant was the caller of
#reportNetworkConnectivity().
For b), the caller is always guaranteed to receive a ConnectivityReport
(a fresh report if the Network is re-validated, else the cached report).
Bug: 162407730
Test: atest FrameworksNetTests ConnectivityDiagnosticsManagerTest
Change-Id: I78b78919d5b0f09348dfdd5fdb37418b8c7f861f
- 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>
Change-Id: Ie9d6b3e39ef16813c4be3979900d226c8f3d656d
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
Change-Id: I38bdea3a026a78a6dc34b5200d43a75b3cd1ac0c
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
Change-Id: Ie3ea59f980c3767782b8e6b03e401c02f664f9bd
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
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
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
Change-Id: If309d653ac2e9bbcf1b94bcee6336367289df359
- 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
Merged-In: I0ea71b348492aeb4784d487bed4cfd5d387426ba
Change-Id: I0ea71b348492aeb4784d487bed4cfd5d387426ba
- Add more tests for mobile data preferred uids.
- Also address leftover comments on implementation commit.
Bug: 171872461
Test: atest FrameworksNetTests
Merged-In: I63f65bffc1b8883ddfd774222e26e629d7ea1f94
Change-Id: I63f65bffc1b8883ddfd774222e26e629d7ea1f94
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
Change-Id: I5a47dcece31749293f080af060218d827082eb67
Use shell permissions to obtain CREATE_USERS to call
ActivityManager.getCurrentUser in ConnectivityServiceTest.
This is necessary to allow the tests to run in coverage tests without
the platform certificate.
Bug: 187935317
Test: atest FrameworksNetTests:ConnectivityServiceTest
Change-Id: I5a56ffab4820d351dcdb132046698cd0d3b8bdb1
* changes:
Add CTS for NetworkAgentConfig#setSubscriberId
Add CTS for getAllNetworkStateSnapshots
Check NETWORK_SETTINGS permission for getAllNetworkStateSnapshots
This is declared in the API surface, but the implementation
does not match.
Test: atest CtsNetTestCases:android.net.cts.ConnectivityManagerTest#testGetAllNetworkStateSnapshots
Bug: 188140631
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Merged-In: I97aa69651461ebe5c323ec669372f9a61b84e6a6
Change-Id: I97aa69651461ebe5c323ec669372f9a61b84e6a6
(cherry-picked from ag/14601670)
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
Change-Id: I944f4c6ad36206bdccd85a6ea7ef71324a29c685
By design, the nascent timer will be removed after a network
satisfied first request. However, this never happens.
Because the mInactive is false when that happens, so isNascent
is never true.
Furthermore, when removing a nascent timer, the inactivity
state can never be updated since no condition in the
updateInactivityState will be met to update the state correctly.
Thus, update inactive state accordingly when adding/removing the
nascent timer.
Test: TH
Bug: 184227264
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Merged-In: I4c1521b6e0ef68ac489771a2ab6b09ef3e381577
Change-Id: I4c1521b6e0ef68ac489771a2ab6b09ef3e381577
(cherry-picked from ag/14060609)
Note that this requires removing part of a test, because
that part is testing that the a 50 bonus of the legacy
int is stronger than the validation penalty, which is
not a mechanic we want to have. When WiFi is unvalidated
and cell is unvalidated, cell should be kept in case it
validates, like is described in comments in
isNetworkPotentialSatisfier ; however this test is
checking that it *IS* reaped off if the wifi score is
strong enough. This should be incorrect, and should not
be tested, so this patch removes the check.
Test: ConnectivityServiceTest
Bug: 184834350
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Merged-In: I8966abee59fea2d9f10f082aba87df6588b72762
Change-Id: I8966abee59fea2d9f10f082aba87df6588b72762
(cherry-picked from ag/14127306)
.equals() only work on cross-process Binder instances if casted to
a Binder instance first.
Bug: 184281544
Test: ConnectivityServiceTest. CTS test for this specific issue to come
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Merged-In: I7b9e0df21a3cca59659867a75792289ddee2f1d7
Change-Id: I7b9e0df21a3cca59659867a75792289ddee2f1d7
(cherry-picked from ag/14125149)
This doesn't reactivate the test because it's not yet fixed over int
scoring.
Bug: 184834350
Test: Remove @Ignore and run testAvoidBadWifi
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Merged-In: I32477db52eb50faabc499fa68e24ba07577782aa
Change-Id: I32477db52eb50faabc499fa68e24ba07577782aa
(cherry-picked from ag/14064906)
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
Change-Id: Ifa103dd66394026d752b407a1bee740c9fcdad2b
At this stage, this is turned off. Unit tests will be
in a followup change.
Test: In a followup
Bug: 167544279
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Merged-In: I4448a3546fbc1a3dddf757982c031c5f39ba2889
Change-Id: I4448a3546fbc1a3dddf757982c031c5f39ba2889
(cherry-picked from ag/14010222 with fixes)
This exposes a mechanism for network providers to tell
the network stack that a given network must be kept up
for some specific reason. This is meant to be easier
for them than to have to file a request, in particular
because there is no guaranteed way to make sure the
request will be best matched by any given network.
Test: new test for this
Bug: 167544279
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Merged-In: I238a3ee5ee9262477a23b897e4141769dd1505d1
Change-Id: I238a3ee5ee9262477a23b897e4141769dd1505d1
(cherry-picked from ag/13929760)
The design is very simply expressed :
An offer is needed for a request if and only if that offer
might beat the satisfier for that request.
The implementation of "might beat" is NetworkRanker#mightBeat.
Test: FrameworksNetTests FrameworksWifiTests NetworkStackTests
Bug: 167544279
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Merged-In: I0fe911eef2483ecbac48c733d56283b81538690a
Change-Id: I0fe911eef2483ecbac48c733d56283b81538690a
(cherry-picked from 7b6a33bd50)
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
Change-Id: I7d75cdb02041e7a202254be2eaeca6c2b02d7c29
