Fixing the indentation for dumpsys CONNECTIVITY for per app network
info. Also updated to more clearly show when the active network is
currently tagged to the "no service network" for configured apps so as
to more clearly show intent to dumpsys consumers. Finally, correctly
showing profile network preferences which weren't being shown
previously.
Prior formatting with no per-app networks:
Current per-app default networks: Per-App Network Preference:
none
Updated formatting with no per-app networks:
Current network preferences:
Default requests:
Prior formatting with active per-app networks ("none" is shown in this
case since profile network preferences weren't correctly displayed):
Current per-app default networks: Per-App Network Preference:
none
Is per-app network active:
true
Active network: 100
Tracked UIDs:
{1100000-1199999}
Updated formatting with active per-app networks:
Current network preferences:
Profile preferences:
[[ProfileNetworkPreference user=UserHandle{11} caps=[ Capabilities:
INTERNET&TRUSTED&NOT_VCN_MANAGED&ENTERPRISE Uids:
<{1100000-1199999}>]]]
OEM preferences:
OemNetworkPreferences{mNetworkMappings={android.net.cts=-1}}
Mobile data preferred UIDs:
mMobileDataPreferredUids: {1, 2, 3}
Default requests:
Request: [uid/pid:1000/1423] - Satisfier: [100] Preference order: 10
Tracked UIDs:{1100000-1199999}
Bug: 189860802
Test: adb shell dumpsys connectivity
Change-Id: I5ed4bb83e9e5a4497f5019ab4e4c0f238989a246
PerUidCounter#transact is used to adjust the request counter for
the per-app API flows. Directly adjusting the counter is not
ideal however in the per-app flows, the nris can't be removed
until they are used to create the new nris upon set.
In fact, satisfiers are the info that new nris need reference.
Without satisfiers in new nris, the avaiable callbacks would be
sent to listeners agin when assign new satisfiers. Even the new
best networks are same as previous satisfiers, but the new nris
have lost those info if calling handleRemoveNetworkRequests()
before createPerAppCallbackRequestsToRegister().
However, removing satisfiers from nris is not necessary actually
because the CS will update the best network to nri when compute
network reassignment. It doesn't need to be cleared when
calling handleRemoveNetworkRequest(). Thus, keep that info and
adjust the sequence to remove nri first. The counter is still
correct and doesn't hit limit artificially.
Bug: 201648050
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I4cbc953def7866b23c2b8ebc8deaadf0ffc3b75d
updateNetworkInfo is called with the argument in a message,
which is initialized with `this` in NetworkAgentRegistry.
That means it's technically possible that CS calls
tearDownUnneededNetwork, calling nai.disconnect() and
queuing up a message to call this, but before it's done
the NA calls sendNetworkInfo with DISCONNECTED, which
never looks up the agent from the map. Throwing a
ServiceSpecificException and resulting in a System crash.
Bug: 196423147
Change-Id: Ia52f2b794f32c263200c14b8dc2eb6b184bff5ff
unregisterNetworkProvider is being called from binderDied()
and handleUnregisterNetworkProvider() at the same time. This results
in NoSuchElementException being thrown.
Check than noi can be removed from network offers before unregistering
death link.
Bug: 196423150
Change-Id: If5bd5f2894fa0509a89340efdc85180c54e72e0e
Upon changing the default SIM card, the radio will create a
new connection to the new subscription. If that subscription
works correctly, the stack will prefer it to the old one as
the new subscription will be marked with a Primary policy
flag it its score.
Normally, at this point the old network lingers to give apps
an opportunity to gracefully migrate their connections. But
with some radios, this may have a dramatic effect on the
performance of the new connection.
This patch introduces a flag so that devices with such radios
can be marked. In this case the stack will move to a degraded
mode and eschew the grace delay for apps and give them a hard
break instead, so that the new network can reach a good
performance immediately. Apps with existing connections will
suffer a worse experience.
If there is a request that can only be served by the old
connection, still keep it, as arguably the user still
expects their MMS be sent on the old connection, even if the
new connection doesn't work well until it's done.
Test: new test in this patch, and add relevant tests in both modes
also manually change the value of the flag and run
FrameworksNetTests and CtsNetTestCasesLatestSdk
Bug: 200226979
Change-Id: I4ace82f90e873bf06298cc689bb1d794ed5124bd
Suspended network should be considered as temporary shortage of
connectivity of a connected network. Thus, it should not be
excluded from network state snapshots and causes data usage to
stop accounting or iptables rules to be removed on the interface
of the suspended network.
This change also address the naming confusion of default networks
parameter of expectNotifyNetworkStatus.
Test: atest ConnectivityServiceTest#testGetAllNetworkStateSnapshots
Bug: 196079981
Change-Id: I8096356f9a472fb1c1246fbdf3fd5f981387fb1c
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 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
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
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 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
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
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
- 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
