Renamed from ensureValid, this is an easier to understand name.
It is also a lot clearer when requestable capabilities also
have to be listenable.
Also move the 2 functions together.
Test: FrameworksNetTests
Change-Id: I685f924a3720846d740837a4a0fee3d88a26725a
* changes:
Prevent native_init from starting TrafficController
Remove libutils dependency from libservice-connectivity
Merge libtraffic_controller_jni into libservice-connectivity
[NETD-TC#15] Make ConnectivityService and PermissionMonitor calls BpfNetMaps on T
calls BpfNetMaps on T
Since TrafficController moves to mainline module for T, so some netd binder
interfaces revelant to BPF are going to deprecated. Provide JNI APIs to
call TrafficController inside mainline module for T.
Bug: 209935649
Test: atest CtsHostsideNetworkTests
Change-Id: Ib3b43cf2840e02806395af9f1e019ca6fccd032e
For now, all entry points reject this. Followup changes
will allow the supported use cases.
Test: new unit tests and CTS for this in this patch
Change-Id: I7262811a2e46336d3bb63c80886fc0578a36da94
NetworkAgents send NetworkCapabilities to ConnectivityService but
there are limits to what exactly they can send. Going forward,
some of these checks will have to happen on the handler thread,
which is already the case when an agent updates its capabilities,
but not upon registration.
This patches moves the sanitization on the handler thread, after
the network monitor is created for a network agent.
Before this patch, upon registration of a new agent, the binder
thread would copy and sanitize the capabilities, then store them
in nai.networkCapabilities. It would store the original caps from
the agent in the NAI, mix in what is known from the network info,
process the LinkProperties, and then proceed to create the
network monitor, but not yet store the NAI in the internal
structures because its registration is not finalized, so other
methods should not see it yet. After the monitor is created in
the network stack process, the NAI is stored in the internal
structures which publishes it for all methods to see. After
that is done, the NAI calls to the network monitor to warn it
that it's registered, what its capabilities are, and that it's
time to start validation if applicable.
With this patch, the validation no longer happens on the binder
thread. Instead, the binder thread stores the capabilities and
link properties as is, before sanitization, in the NAI. This is
fine because no other method can access these until the
registration completes upon notification that the monitor has
been created ; this agent is only stored in the network monitor
callbacks in a self-destructing object precisely to make sure
that's the case.
When the monitor is created and CS receives notification of the
same, it will sanitize the capabilities before adding the NAI
to the internal structures, to protect the invariant that the
un-sanitized capabilities inside the NAI can't ever be seen by
any other method. After that's done, it will call to the
monitor to start validation as usual.
Test: FrameworksNetTests CtsNetTestsCases
Change-Id: I7d43ef0e25955e0349903b4801b9dfd8c3c92586
The code cannot work before T because before T the tethering
module can only load BPF programs/maps into /sys/fs/tethering/bpf
and the system server cannot access that directory.
Additionally, this is causing unit tests to fail on pre-T devices
because on those devices the seccomp filter blocks the bpf
syscall from apps (including Java tests).
Test: revert aosp/1907693 and atest FrameworksNetTests:ConnectivityServiceTest
Change-Id: I6c398031dffb840da1d723b11ea4d0845ad6c6f2
New events to handle adding and removing of DSCP QoS policies.
Async indication sends status back to client if the policy
has been added, failed, or if the policy limit has been
reached.
Bug: 202871011
Change-Id: I7988d22ae625ad0dd415927d2943de4a749e6fb8
This CL should be reverted before T sdk finalized.
This API is temporary added for the NetworkStatsFactory which is platform
code but will be moved into connectivity (tethering) mainline module.
Bug: 209935649
Test: atest CtsHostsideNetworkTests
Change-Id: I5894450f3089b2ea105722a18ddf8f1eed1c28a0
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
