This will allow moving LockdownVpnTracker from the connectivity
to the VPN code. This requires moderate refactoring since it's
pretty tightly coupled to both.
In this CL:
1. Add an @hide API to tell ConnectivityService that legacy
lockdown VPN is enabled. I chose not to use the existing
setVpnRequiredForUids API because that method has specific
semantics and because it will be required long term since
it's used by non-legacy VPN types.
2. Instead of updating LockdownVpnTracker inline from the
ConnectivityService handler thread, have it listen to
NetworkCallbacks. This introduces an extra thread hop, but
most of the interactions between the lockdown VPN and CS were
via NetworkAgent, which is asynchronous anyway.
3. Add code to LegacyTypeTracker to send the extra
CONNECTIVITY_ACTION broadcast for the underlying network type
that is sent after the VPN connects. In order to do this, make
Make LockdownVpnTracker specify its underlying network
(via setUnderlyingNetworks) when it connects.
4. Reimplement LockdownVpnTracker#augmentNetworkInfo based on
information that is available in ConnectivityService.
5. Remove the code in LockdownVpnTracker that counted errors.
I think this code has not worked since lollipop, because
ConnectivityService never sees NetworkInfo objects in state
FAILED. This is because ConnectivityService only hears about
NetworkInfo objects via NetworkAgents, and LegacyVpnRunner
only registers its NetworkAgent when the connection succeeds.
Bug: 173331190
Test: passes existing tests in ConnectivityServiceTest
Change-Id: I66d18512882efd468ee0ecec61f28786a195b357
Use data that is already available in ConnectivityService
instead.
The behaviour of the new implementation is slightly different
from Q and R code when the permission check fails.
- The old code would throw a SecurityException if an app that
was not an active VPN called the method, and would return
INVALID_UID if the connection belonged to a UID that was not
subject to the VPN.
- The new code returns INVALID_UID in both cases.
This does not seem like a compatibility problem. The only case in
which the code throws SecurityException is if the app is not a
current VPN app, but the app already knows whether it is or not.
The docs don't mention that the method SecurityException, either.
Bug: 173331190
Test: atest FrameworksNetTests
Test: atest HostsideVpnTests
Change-Id: If3d031e74df33b5c97e12ebf02272faac6769d50
This currently stores the VPN type and a session name, but can be
extended in the future.
Bug: 173331190
Test: added coverage in VpnTest
Test: added coverage in ConnectivityServiceTest
Test: added coverage in NetworkAgentTest
Change-Id: I450858a9fa332c8d896dbdb4c14337d5ec23677f
This method allows internal components to track the system
default network. This differs from registerDefaultNetworkCallback
because that method sends callbacks for the default network for
the UID that called it. This may not be the system default
network, for example, when a VPN is up and applies to the UID.
Bug: 173331190
Test: new unit tests in ConnectivityServiceTest
Test: new unit tests in ConnectivityManagerTest
Test: new CTS tests in ConnectivityServiceTest
Test: new CTS tests in HostsideVpnTests in other CL in this topic
Change-Id: Id02748a2183f71b71ff2a53a580466b9dcecaa93
* changes:
[FUI07] Stop making NetworkState with NetworkInfo from external callers
[FUI06] Stop using NetworkInfo in NetworkState from external callers
Not currently setting the atttribution tag for location
permission checks. Plumb the attribution tag for all location permision
checks (so that location access is correctly attributed to individual
components within an app)
Bug: 162602799
Test: atest android.net
Test: atest com.android.server
Change-Id: Iee95f05204f51a4f8cb1f36acfb60e8cdeb156f4
Follow-up from previous patch. This change stop accessing the
constructor that needs NetworkInfo to create NetworkState, which
is no longer accessible after ConnectivityService become
mainline module. Instead, pass a legacy network type which is
dedicated for the need of the type.
Test: atest FrameworksNetTests NetworkPolicyManagerServiceTest
Bug: 174123988
Change-Id: I24157bc33e5a5819eccd6a3111d2049f531c1d43
This is achieved by:
1. Use legacy network type inside NetworkState to replace the
needs of referencing NetworkInfo.getType().
2. Let getAllNetworkState only return networks with isConnected()
equals true. This allows callers such as NPMS or NSS does not
have to reference to NetworkInfo.isConnected().
Test: atest FrameworksNetTests NetworkPolicyManagerServiceTest
Bug: 174123988
Change-Id: I1c4eb08d18ca973eb8f41d06258872eabc0006b8
* changes:
Change ConnectivityServiceTest to prepare for VPN code move.
Add to VpnManager the VPN APIs used by Settings and SystemUI.
Remove temporary hack in VpnTest.
The static validate() method an PROXY_* constants in Proxy are
used by both module and Settings. After Proxy is moving into
connectivity module, Setting will not able to access them.
Thus, move them to ProxyUtils in net shared lib.
Bug: 172183305
Test: atest FrameworksNetTests
Test: atest CtsNetTestCases:ProxyInfoTest
Change-Id: I02c88aeaeb53d62b87a42a2d8ead9b140b054650
No-op changes to make it easier to review the VPN code move.
1. Set underlying networks via MockVpn, not ConnectivityService.
2. Add a processBroadcastForVpn utility method that we can modify
without too much churn when the code is moved.
Bug: 173331190
Test: test-only change
Change-Id: I4256ca5f33034ef9d1de79857795a6ed1d644e61
Settings and SystemUI use these through raw AIDL calls.
Make them proper manager calls so we can move the implementation
without touching the callers again.
For now these still call into ConnectivityService via
IConnectivityManager. In an upcoming CL the implementation will
move to VpnManagerService.
Test: m
Bug: 173331190
Change-Id: I91528e1ad9948fbaa1fc5e37c61c5eb95f54964e
This temporary hack was necessary due to b/175883995. Now that
that bug is fixed, remove the hack.
Bug: 171529940
Test: test-only change
Change-Id: I48bd594cf3a37575f4888c1be9a1cf535de2e4d2
Currently, NetworkRequest has several types of requests (LISTEN,
TRACK_DEFAULT, REQUEST, BACKGROUND_REQUEST), and we expect more
to be added.
There are really three categories of request:
1. Requests satisfied by only one network and will keep that
network up, and thus need to be sent to NetworkProviders:
REQUEST, BACKGROUND_REQUEST.
2. Requests satisfied by only one network but will not keep that
network up: TRACK_DEFAULT
3. Requests satisfied by multiple networks and will not keep any
networks up: LISTEN.
Unfortunately the separation is not very clear. Currently, for
any valid request, either isListen() will return true or
isRequest() will return true. This makes it impossible to tell
whether a particular request should be sent to NetworkProviders,
so the current code sends TRACK_DEFAULT requests to
NetworkProviders as well. This is incorrect - a TRACK_DEFAULT
should never keep a network up, for example.
This CL attempts to clarify things by making isRequest() return
false for TRACK_DEFAULT requests and thus never sending them to
NetworkProviders. After this CL:
- isRequest will return true only for requests that attempt to
bring up or keep up a network.
- isListen will return true only for requests that match multiple
networks but do not keep any of them up.
- Neither will return true for TRACK_DEFAULT.
Test: atest ConnectivityServiceTest
Change-Id: I7aad30ade8f7ab2a179e53483d9afd8675f64a12
This is mainly used by VCN, where VCN-eligible networks might
be registered before VCN management service can fire request
to prevent the newly created network from being torndown
immediately by ConnectivityService.
Test: atest ConnectivityServiceTest#testNewNetworkLingering
atest ConnectivityServiceTest#testNewNetworkLingering_bgNetwork
atest FrameworksNetTests --rerun-until-failure 20
Bug: 175180558
Change-Id: I7768daf4cf2d8f6d8057b5107412e06104ba82e0
Linger timer mechanism will be used for both "linger" and
"nascent" states. To prevent confusion, rename the linger
timer and related functions to more generic name.
Test: TH
Bug: 175180558
Change-Id: I652f7c65c2f8bc58fb9d3316480f23a9709eccce
This is a partial cherry-pick of change:
I5eedb571c9d78862115dfdc5dae1cf2a35343580
for connectivity classes.
Bug: 170883422
Test: m
Merged-In: I5eedb571c9d78862115dfdc5dae1cf2a35343580
Change-Id: I7dc661863b73f4198ddb4f3a1566583d0f07db3c
These tests do not actually work, or at least not as designed.
What happens when they are run is that creating/connecting the
VPN throws an exception. The call to legacyRunnerReady.block()
times out after 10 seconds because the condition variable is
never opened, but the doesn't notice the timeout becasue it
doesn't check the return value of block().
There are two reasons for the VPN not coming up.
1. VpnConfig.getIntentForStatusPanel calls into PendingIntent and
ActivityManager statics, which bypass all the mocks and fail
with an appops denial. Fix this by making it a dependency.
2. The tests are broken due to the UserManager API changes
tracked in b/175883995. Fixing by adding a bit of ad-hoc code
into startLegacyVpn, with a TODO to delete it once the rest of
the UserManager setup code is fixed.
Fix these and check the return value of block(). This ensures
that if any other breakage is added the test will actually fail.
Also check that the throw route survives all the way to the
LinkProperties sent to the agent.
Bug: 173331190
Test: atest com.android.server.connectivity.VpnTest
Change-Id: Ieb7f33bce283ac5ee562a912df8edb9c930ed2b0
Updated OemNetworkPreferences to use a Map instead of an Array of Arrays
(SparseArray<List<String>>). This is for two reasons: to make the API
simpler and also prevent issues with duplicate entries for packages
mapped to more than one preference which is not supported.
Bug: 176597181
Bug: 176494815
Test: atest FrameworksNetTests
Change-Id: I85363e28b46b89ae60a85219313c2a45bd5e7dd5
For the incoming connectivity mainline, it need to compute the
intersection of a set of uids and appIds for the permission
control. As @UserIdInt values are internal implementation details
of the OS, any mainline modules should use strongly-typed
UserHandle arguments. Thus, create a new API that accepts
UserHandle and appId to get the computed uid.
Bug: 170598012
Test: atest FrameworksNetTests
Change-Id: I046546d2c5c76eac7a251e63e4234776975bf2bc
ConnectivityService is going to become a mainline module which
will not able to access hidden APIs. NetworkPolicyManagerInternal
is a internal serivce that CS can't be access after be a mainline
module. Thus, create NPM#checkUidNetworkingBlocked to replace it.
Bug: 170598012
Test: atest FrameworksNetTests
Test: atest CtsNetTestCases
Test: atest CtsHostsideNetworkTests
Test: atest FrameworksCoreTests:NetworkPolicyManagerTest
Test: atest FrameworksServicesTests:NetworkPolicyManagerServiceTest
Change-Id: I7bee37522dc5c55c255b159fda9481eff663655a
This patch addressses the mocked UserManager for the context
of the user which is created by createContextAsUser.
Bug: 171529940
Bug: 175883995
Test: FrameworksNetTests
Change-Id: Ie72d08c765ed7fb7083c0c4b7ee02a43c23d1707
Deduce the NET_CAPABILITY_NOT_VCN_MANAGED capability from other
capabilities and user intention, which includes:
1. For the requests that don't have anything besides
VCN_SUPPORTED_CAPABILITIES, add the NOT_VCN_MANAGED to
allow the callers automatically utilize VCN networks
if available.
2. For the requests that explicitly add or remove
NOT_VCN_MANAGED, do not alter them to allow user fire
request that suits their need.
Test: atest NetworkRequestTest#testBypassingVcnForNonInternetRequest
Bug: 175662146
Change-Id: I9936894b9530a22fb186cfd25cbee0fced65b72b
Nothing on the system is using registerNetworkFactory,
unregisterNetworkFactory at the moment.
registerNetworkFactory, unregisterNetworkFactory are protected by
signature permissions, so could not be used by anything outside of the
system.
Remove the two methods and the underlying support for this legacy,
deprecated mechanism.
Bug: 179229316
Test: atest FrameworksNetTests
Change-Id: I7cdc9eed67f846c8774474af038133040aeccab3
