To deprecated firewallReplaceUidChain netd binder and move the
functionality to tethering (connectivity) mainline module, expose
replaceFirewallChain to support the caller outside the module.
Currently the API are still call to netd. Will replace with the
implementation inside tethering (connectivity) module.
Bug: 209935649
Test: atest CtsHostsideNetworkTests
Change-Id: If7a87548b0a3acda00a1455da4e4ff24a630ddc7
To deprecated firewallEnableChildChain netd binder and move the
functionality to tethering (connectivity) mainline module, expose
setFirewallChainEnabled to support the caller outside the module.
Currently the API are still call to netd. Will replace with the
implementation inside tethering (connectivity) module.
Bug: 209935649
Test: atest CtsHostsideNetworkTests
Change-Id: I9b64c9d12260521489a87fbeae5afbee2a8ea8f6
To deprecated firewallSetUidRule netd binder and move the functionality to
tethering (connectivity) mainline module, expose updateFirewallRule to
support the caller outside the module. Currently the API are still call
to netd. Will replace with the implementation inside tethering
(connectivity) module.
Bug: 209935649
Test: atest CtsHostsideNetworkTests
Change-Id: I0b53c999e06c2378afec0eb491815ec398c91b0b
Add a method to apply a set of network preferences to a user profile
Bug: 194332512
CTS-Coverage-Bug: 211133973
Test: CTS
Change-Id: I97730ea14e7c96922236fd77a591e5acadd875ba
Add extra field in NativeNetworkConfig to allow CS to notify
netd whether the local traffic should be excluded from the VPN
network.
Bug: 184750836
Test: atest FrameworksNetworkTests
Change-Id: If230fe7057722c80a09433673ac3cec857f7a7a5
To deprecated below netd binder interfaces and move the functionality to
tethering(connectivity) mainline module:
bandwidthAddNaughtyApp
bandwidthRemoveNaughtyApp
bandwidthAddNiceApp
bandwidthRemoveNiceApp
Expose updateMeteredNetwork{Allow, Deny}List APIs to support the caller
outside the module. Currently the two APIs are still call to INetd
binders. Once functionality is moved to mainline module, will switch to
use them.
Bug: 209935649
Test: m
Change-Id: I8df720935748c2587f91a7b760cfd5a93a0fa852
Update to ConnectivityService to use permission utils to validate the
existence of a system feature.
Bug: 210485380
Test: atest FrameworksNetTests:
com.android.server.ConnectivityServiceTest
Change-Id: Ia537cc5b37ef8d80f49f1a83ba572b3b8a9f6874
With the network selection rewrite in S, rematching a single request can
now easily be done; this can be used as an optimization in
handleRegisterNetworkRequests to avoid rematching all requests when
registering a new one.
This can be disabled by a flag that is unset by default,
REMATCH_ALL_REQUESTS_ON_REGISTER.
Test: atest ConnectivityServiceTest
Change-Id: If76f79b41ac88863974f7025624667134bea2570
This will prevent the system crash in b/194394697, and on T try to
detect the issue much earlier and crash the system at that time
together with much more expansive logs.
Bug: 194394697
Test: ConnectivityServiceTest
Change-Id: Ia4be82179160216d41bf4d88b896e4814385063a
Binders from the system server don't help, because if the process
dies there is nobody to listen to its binder deaths.
Test: ConnectivityServiceTest
Change-Id: I993cb9481edfaeb652b875be7f90166db16d0e1d
Now, VPN will set underlying networks into NetworkCapabilities
directly. So the declaredUnderlyingNetworks can also be set
directly when creating a NetworkAgentInfo.
Bug: 191918368
Test: atest FrameworksNetTests:ConnectivityServiceTest
Change-Id: I507072d00ae1eb0c391e5261ab93e359b9c4cb5c
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
Reproduction steps:
- Register a NetworkAgent but don't mark it as connected.
- Set teardownDelayMs for the NetworkAgent to 100
- Unregister the NetworkAgent then see system crashed.
Tests:
- Builds, Boots
- ConnectivityServiceTest
Change-Id: Ib8e517acb0193a2454d672612fe61fc199de46a4
Bug: 200023207
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
CS#requestRouteToHostAddress enforcing change permission doesn't
check whether the calling package belongs to calling uid. This
can be used to check whether package name exists or not without
permission. Thus, add a check to ensure calling package name and
uid are matched.
Bug: 193801134
Test: atest FrameworksNetTests CtsNetTestCases
Ignore-AOSP-First: Security fix
Change-Id: I980f1c68b5321601aa40da29e283fb4dd717d5de
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.
Original change: https://android-review.googlesource.com/c/platform/packages/modules/Connectivity/+/1781202
Merged-In: Ia482e6fbf2bf300ce6cbaca72810d394ed201b98
Change-Id: I6744d2f60d6bd664f048b532a58461c110a5b7fe
(cherry picked from commit 916aeb7b0d)
