UidRange is a data class that is an implementation detail of
Connectivity. Move it to the connectivity boundary.
Remaining usages of UidRange outside of Connectivity (in VPN) should be
migrated to other classes, like Range<Integer> or UidRangeParcel.
Bug: 181512874
Test: m
Change-Id: I6f2e3685ad1c07171dd90480d1e546329de8732d
UidRange uses PER_USER_RANGE to calculate and get the userid,
but PER_USER_RANGE is a hidden API, so use getIdentifier to get
the userid instead.
Bug: 170598012
Test: atest FrameworksNetTests:UidRangeTest
Change-Id: I06ab0f2da8a33d2b718bbc3a609d3d6a5fe0a095
lucaslinauthored and Lucas Lincommited 2021-03-02 02:21:39 +00:00
UidRange will be a part of connectivity mainline module.
Mainline modules should use strongly-typed UserHandle arguments.
The method also refer to the hidden UserHandle.PER_USER_RANGE
which is not available after UidRange is moved into module.
Thus, replace the usage and remove the createForUser method that
takes userId parameter.
Bug: 170598012
Test: atest FrameworksNetTests
Change-Id: I3f33ea92c4a24342af9ec4b0367c50bb64ce6450
userId integers are not public API and code should use UserHandle
instead.
Bug: 170598012
Test: passes existing tests
Change-Id: Ic27b93ccfe6bbc97e7419293ce165fee6cd51e6d
Lorenzo Colitticommited 2021-02-16 08:06:23 +00:00
This is a partial cherry-pick of change:
I5eedb571c9d78862115dfdc5dae1cf2a35343580
for connectivity classes.
Bug: 170883422
Test: m
Merged-In: I5eedb571c9d78862115dfdc5dae1cf2a35343580
Change-Id: I7dc661863b73f4198ddb4f3a1566583d0f07db3c
Roman Kalukiewiczauthored and Remi NGUYEN VANcommited 2021-02-05 07:28:44 +00:00
This reverts commit bc571c7cc8.
Reason for revert: Rolling forward, will fix tests in same CL stack.
Bug: 114231106
Bug: 130397860
Test: FrameworksNetTests
Change-Id: Ia8a0c99b4e1fd5dff26c881715cd876618ca4321
Lorenzo Colitticommited 2019-04-12 19:52:32 +09:00
This reverts commit 4773027064.
This change does not have any topic: not reverting the other 2 commits in the original topic.
Reason for revert: broke FrameworksNetTests presubmit: b/130397860
Change-Id: Iff41d9fe97fafea44680c8d67d1ce19277548cc0
When a fully-routed VPN is running, we want to prevent normal apps
under the VPN from receiving packets originating from any local non-VPN
interfaces. This is achieved by using eBPF to create a per-UID input
interface whitelist and populate the whitelist such that all
non-bypassable apps under a VPN can only receive packets from the VPN's
TUN interface (and loopback implicitly)
This is the framework part of the change that build the whitelist.
The whitelist needs to be updated in the following cases:
* When a VPN is connected and disconnected
This will cover the change to allowBypass bit, since that can't be
changed without reconnecting.
* When a VPN's NetworkCapabilites is changed (whitelist/blacklist app changes)
* When a new app is installed
* When an existing app is removed
* When a VPN becomes fully-routed or is no longer fully-routed
New user/profile creation will automatically result in a whitelist app change
transition so it doesn't need to be handled specially here.
Due to the limitation of the kernel IPSec interacting with eBPF (sk_buf->ifindex
does not point to the virtual tunnel interface for kernel IPSec), the whitelist
will only apply to app VPNs but not legacy VPN connections, to prevent breaking
connectivity with kernel IPSec entirely.
Test: atest PermissionMonitorTest
Test: atest android.net.RouteInfoTest
Test: atest com.android.server.ConnectivityServiceTest
Test: atest HostsideVpnTests
Bug: 114231106
Change-Id: I143b03d60e46cb1b04732b4a4034f5847b4d1b1a
The only actual users of these classes are in services.jar, not
in frameworks.jar. The only reason the framework depends on them
is that the code that converts to and from stable parcelables is
currently in the framework. Move that code to services and cut
the dependency.
These classes aren't used in the networkstack app so they don't
need to be in shared. They also can't be in shared because the
classes are not in the SDK. So put the conversion functions
directly inside their only user (NetworkManagementService).
Also remove the jarjar rules that rename the classes for use by
the NetworkStack app.
This does not actually remove the dependency from the build file,
that will be done in a future CL.
Bug: 128804404
Test: builds, boots
Test: atest FrameworksNetTests android.net.cts.ConnectivityManagerTest HostsideVpnTests
Change-Id: I027d50ba56091f5558f45e6e08f32e5912b2a82a
Merged-In: I027d50ba56091f5558f45e6e08f32e5912b2a82a
Lorenzo Colitticommited 2019-03-20 08:56:24 +09:00
The only actual users of these classes are in services.jar, not
in frameworks.jar. The only reason the framework depends on them
is that the code that converts to and from stable parcelables is
currently in the framework. Move that code to services and cut
the dependency.
These classes aren't used in the networkstack app so they don't
need to be in shared. They also can't be in shared because the
classes are not in the SDK. So put the conversion functions
directly inside their only user (NetworkManagementService).
Also remove the jarjar rules that rename the classes for use by
the NetworkStack app.
This does not actually remove the dependency from the build file,
that will be done in a future CL.
Bug: 128804404
Test: builds, boots
Test: atest FrameworksNetTests android.net.cts.ConnectivityManagerTest HostsideVpnTests
Change-Id: I027d50ba56091f5558f45e6e08f32e5912b2a82a
Lorenzo Colitticommited 2019-03-20 00:49:32 +09:00
If they were null, then the Parcelable would fail to work.
Bug: 126726802
Test: manual
Change-Id: I7929ffa2f20e5de1c8e68e8263cca99496e9d014
Exempt-From-Owner-Approval: Trivial API annotations
Use stable aidl generated structure instead of UidRange
Test: runtest frameworks-net passes
Test: manual testing of UidRange related function works
Change-Id: Iaf1c10777dc1e71df2be2a57533a10257b12626b
By changing some member refs into arguments and having one of the
functions create the UID range instead of adding to mVpnUsers.
This will be useful for other layers of UID filtering like having
UIDs explicitly blocked from the VPN.
Deleted one broken line of code that cleared the status intent when
a restricted profile is removed. Other than that, this commit shouldn't
change any behaviour. If it does, that's a bug.
Bug: 26694104
Change-Id: Ieb656835d3282a8ba63cc3f12a80bfae166bcf44
This eliminates the need for the ConnectivityService.VpnCallback class.
This requires shifting VPNs to the new "network" netd API.
VpnService.protect() is modified to no longer go through ConnectivityService.
NetworkCapabilities is extended to add a transport type for VPNs and a
capability requiring a non-VPN (so the default NetworkRequest isn't satisfied
by a VPN).
bug:15409918
Change-Id: Ic4498f1961582208add6f375ad16ce376ee9eb95