Update to ConnectivityService.unneeded in order to support multilayered
requests.
Bug: 173432311
Bug: 171991028
Test: atest FrameworksNetTests
atest FrameworksNetIntegrationTests
atest CtsNetTestCasesLatestSdk
Change-Id: If040d61e33d86a9f9bbc7d50ead596d210a4f82c
* changes:
Add a convenience method to update a network's capabilities.
Disallow NetworkAgents from changing the owner UID.
Observe mOwnerUID in NetworkCapabilities#equals.
ConnectivityService is going to be a part of mainline module, to
prevent using @hide method in ConnectivityService, reimplement
DumpUtils#checkDumpPermission() in ConnectivityService.
Bug: 175177794
Test: atest FrameworksNetTests
Test: adb shell dumpsys connectivity
Change-Id: I1e4bc023b39b40a717a3a0fd8cd60aa2f25e9bdb
Almost all calls to ConnectivityService#updateCapabilities use
all the current data in the network, and thus call the method
like this:
updateCapabilities(nai.getCurrentScore(), nai, nai.networkCapabilities);
Introduce a convenience method to simplify this frequent use case.
Bug: 173331190
Test: passes existing ConnectivityService tests
Change-Id: I6eb6d92bd159f2575d10a929bd59f6dd1b7a4b4e
The current behaviour with regards to changing the owner UID is
bizarre and arguably incorrect. A NetworkAgent can change the
owner to whatever other app it wants, regardless of signatures,
at any time. This includes, for example, transferring ownership
to another UID and then recovering it.
Fortunately no existing NetworkAgent appears to do this:
- ClientModeImpl sets it to the UID of the app that created the
configuration. It doesn't look like it can change while the
network is connected.
- Vpn sets it to the UID of the VPN owner. That also can't change.
- Telephony does not appear to set it at all, it only sets the
administrator UIDs (and updates them whenever it gets
EVENT_CARRIER_PRIVILEGED_UIDS_CHANGED).
Disallow this now before code is written that depends on it.
Bug: 175188445
Test: modified tests in ConnectivityServiceTest
Change-Id: I638e29fda2481ec3bf4fff562ea66a73322881df
This CL updates ConnectivityService to allow the System's UID to
unregister ConnectivityDiagnostics callbacks. Preivously, only the
registrant was allowed to unregister them - this caused problems for
callbacks that were attempted to be unregistered via binderDied() when
the registrant app dies.
Bug: 159912975
Bug: 174713659
Test: manually verified
Change-Id: I20d0cad5f902708d366aa703c2893b0ea3e55052
This reduces verbose assertions and makes the test more compact.
I'm not sure whether it's actually more valuable, since the
current code, while more verbose, is probably more
straightforward to understand.
Also add a test for passing in a null underlying network (i.e.,
follow default network). This requires a minor refactoring in
ConnectivityService because the applyUnderlyingCapabilities does
not currently treat null specially.
Bug: 173331190
Test: test-only change
Change-Id: Ic5a3e16969ea9e1a529706850f148cb0d5fd8e09
- Create NetworkAgent by using the public API of NetworkAgent.
- Remove the usage of NetworkInfo.
Bug: 172183305
Test: Build pass.
Test: atest FrameworksNetTests
Test: atest CtsNetTestCasesLatestSdk
Test: atest NetworkStackIntegrationTests
Test: atest TetheringIntegrationTests
Change-Id: Icba59295861201c221587caa9df02275c4087fb8
This is essentially a straighforward move of code from Vpn to
ConnectivityService, and from VpnTest to ConnectivityServiceTest.
Bug: 173331190
Test: passes existing tests, moved tests pass
Change-Id: I76daa3abcc777e9c3ba57efb750de0e2e2f3bb74
The existing method is confusing (the argument used to be called
includeDying) and it puts the burden on the caller (which need to
understand what the parameter means).
Furthermore:
- The majority of calls are for getUsers(excludeDying=true).
- The calls for getUsers(excludeDying=false) are equivalent to
calls to getUsers()
Test: m
Test: a VpnTest ConnectivityServiceTest PermissionMonitorTest
Bug: 157921703
Change-Id: Ife767a40b7b7790ba28b5377046de822ddbf275c
Merged-In: Ife767a40b7b7790ba28b5377046de822ddbf275c
(cherry picked from commit 72eeb557e7)
Connectivity service module uses Slog which is @hide so
migrate to Log, which is public, to remove hidden API usage.
Bug: 172050541
Test: FrameworksNetTests
check log is moved from system buffer to main buffer.
Change-Id: I0dcc0e169b892cc872ed4510f699642cb81b633a
Instead, make Vpn#onUserAdded and Vpn#onUserRemoved notify CS
of UID range changes through the VPN's NetworkAgent.
After this change, ConnectivityService no longer touches the
VPN's NetworkCapabilities directly, which is a much cleaner
design.
Bug: 173331190
Test: passes existing tests in ConnectivityServiceTest
Change-Id: If2201f392cdb5f00c89a97683ad4ce6bda7b89e5
This is only used for NetworkStatsService and only called on the
handler thread, so it can be replaced by a simple scan over
mNetworkAgentInfos without having to take any locks.
Bug: 173331190
Test: passes existing tests in ConnectivityServiceTest
Change-Id: I194e0cc55603a0f59f7138f38329f505b55da132
Currently, checkConnectivityDiagnosticsPermissions takes the VPN
lock to examine the VPN's underlying networks. Use the underlying
network data that is available in ConnectivityService instead.
Bug: 173331190
Test: passes existing tests in ConnectivityServiceTest
Change-Id: Ia1c366c5e9974d4d2c4b38030e66c007d62020ff
Much of registerNetworkAgent calls internal ConnectivityService
methods which generally assume that they are not processing an
IPC and are running under the system's calling identity.
However, only the call to makeNetworkMonitor is run with caller
identity cleared. Expand the scope of clearing the caller
identity over the creation of the nai.
Bug: 173331190
Test: passes existing tests in ConnectivityServiceTest
Change-Id: Icad28601a612fb5e1ed0451ec9e2066f4e766d0e
Add support to ConnectivityService to track underlying networks
directly instead of through the Vpn class.
1. Communicate all information necessary to propagate underlying
network capabilities to ConnectivityService via NetworkAgent.
This includes:
a. Underlying networks:
- Add SystemApi for NetworkAgent to declare its underlying
networks to ConnectivityService, and use it in Vpn.
- Add a new declaredUnderlyingNetworks member to
NetworkAgentInfo and store the underlying networks in it.
Move propagation of underlying network capabilities to
mixInCapabilities, which is a natural place for it.
b. "Always metered" bit:
- Communicate this to ConnectivityService via the existing
NOT_METERED capability. Store it in a new declaredMetered
boolean in NetworkAgentInfo to separate it cleanly from
the NOT_METERED bit in the capabilities, which depends on
whether the underlying networks are metered or not. In
order to ensure that this is only ever changed when a NC
update is received from a NetworkAgent, define a new
processCapabilitiesFromAgent similar to the existing
processLinkPropertiesFromAgent.
2. Ensure that propagating underlying network capabilities does
not read the VPN's NetworkCapabilities. In order to do this,
ensure that all relevant information on underlying networks
and metering is sent to ConnectivityService at NetworkAgent
registration time. CS still calls Vpn#updateCapabilities when
a user is added/removed, but that is deleted in a future CL.
3. Slightly generalize propagating underlying network
capabilities because there may be other network types that
also have underlying networks that aren't VPNs (e.g., VCN).
- Introduce a new supportsUnderlyingNetworks() boolean method
in NetworkAgentInfo.
- Rename updateAllVpnsCapabilities to
propagateUnderlyingNetworkCapabilities.
This commit does not move the actual logic of calculating the
underlying capabilities out of Vpn.java. That can be done in a
subsequent change once CS stops calling getUnderlyingNetworks().
This commit also does not modify any of the other code in CS that
directly accesses VPNs' underlying networks.
Bug: 173331190
Test: passes existing tests in ConnectivityServiceTest
Test: CTS test in r.android.com/1511114
Test: atest CtsNetTestCases:Ikev2VpnTest HostsideVpnTests
Change-Id: I5f76cb1aa4866efed3d5c4590e931fdb0e994f8d
* changes:
Update toString() to use the correct request
Update requestsSortedById() to sort by collection
Allow a way to track the active request in an NRI
Update ConnectivityService.NetworkReassignment#toString to use either
the current satisfier's request otherwise highest priority request when
executing toString(). This is part of the mulilayered request changes.
Bug: 173336774
Bug: 171991028
Test: atest FrameworksNetTests
Change-Id: Ibed6cdd4522133164b2b919f62ecc9411943f026
Update requestsSortedById() to sort NetworkRequestInfo by their
nested collection of NetworkRequest objects vs a single request.
Before the NetworkRequestInfo with the request with the lowest
requestId would be sorted to the top. Now the NetworkRequestInfo
which contains the request with the lowest requestId will be
sorted to the top.
Bug: 173292541
Bug: 171991028
Test: atest FrameworksNetTests
Change-Id: I51e3c00d59443e37ddbf168c423d13df8d14fa64
As we are now allowing for multi-layered requests in NetworkRequestInfo
(NRI), we need a way to track which of those requests ended up being
satisfied. This also includes updates to NetworkRequestInfo itself to
support multilayared requests.
Bug: 173146509
Bug: 171991028
Test: atest FrameworksNetTests
atest FrameworksNetIntegrationTests
atest CtsNetTestCasesLatestSdk
Change-Id: I7bb5a564769c90928871fe28de05195c9cfae6b5
Change-Id: Ibf37f94b53eb2e833821553e00d76fe38bfea266
This comment is not true anymore since NetworkMonitor is not only
verifying the default network but also verifying VPN when private
DNS is enabled.
Test: Build pass.
Change-Id: Ib975aa28c84b9974a73d1baca9d5185c01b71217
BasicShellCommandHandler is used by mainline modules and the
framwork. There is a new repo that was created for putting
this kind of utility class. Move BasicShellCommandHandler for
the incoming ConnectivityService mainline and updating the
related usage.
Bug: 170598012
Test: m ; verify with adb shell cmd
Change-Id: I8a2873df6e7d8342b7a8b466bda155f74c807ee3
Merged-In: Ida30c877116090616d4bf3f87fdad835446dac84
Replace InterfaceConfiguration with InterfaceConfigurationParcel
for the incoming ConnectivityService mainline since mainline
modules could not use @hide API.
Bug: 170598012
Test: atest FrameworksNetTests
Change-Id: I17ce8741e985fd30e3c8f0c34e79564a82890dc6
ConnectivityService is going to become a mainline module which
is not able to access hidden API. Thus, replace the usage from
NMS to INetd.
Bug: 170598012
Test: atest FrameworksNetTests ConnectivityManagerLegacyTest
Change-Id: Ice1bd1effab26555917bc1766354aeaebd41ad66
Updating NetworkRequestInfo for "multilayered requests" functionality so that
requests can support a network hierarchy. I.e., requests network
with capability A first and if not available, request network with
capability B. This CL is the first step in adding that support by
updating the request object from a single request to a collection.
Bug: 171991028
Test: atest FrameworksNetTests
atest NetworkStackTests
atest FrameworksNetIntegrationTests
atest NetworkStackIntegrationTests
atest CtsNetTestCasesLatestSdk
Change-Id: I64a124802986e4cf4aa7de158c6690fdf9851cb2
ConnectivityService is going to be a mainline module, it can only
use formal APIs or @SystemApi. So use @SystemApi
hasIpv4DefaultRoute and hasIpv6DefaultRoute instead of
hasIPv4DefaultRoute and hasIPv6DefaultRoute.
Bug: 172183305
Test: atest FrameworksNetTests
Change-Id: I67e5fa234fbb6d0b9739ae3295eb0b0ea108f582
Connectivity service module is using some Context @hide APIs but
they are not able to call after CS becomes a mainline module.
Thus, replace them with similar System APIs.
Bug: 170593746
Test: atest FrameworksNetTests
Test: Manully check that receiving intent and starting activity
can work normally.
Change-Id: I0f5b53ce0da4e3fc0f927896e9a9e444048401bd
ConnectivityService mainline module cannot call the members
inside SystemNotificationChannels.java. So use the local defined
constants instead.
Bug: 172040168
Test: atest FrameworksNetTests
Test: Manual test NO_INTERNET, SIGN_IN, PARTIAL_CONNECTIVITY,
VPN_ALWAYS_ON notifications.
Change-Id: I223b207c4346e8239dee78e50dd2b0532a3e55b0
It's confusing that NetworkNotificationManager uses
NotificationManager to put up notifcation which is passed from
ConnectivityService. And that NotificationManager should be
gotten from a context with UserHandle.ALL because the
notification should notify to all users. But the future developer
may not know this and pass incorrect NotificationManager
probably. Therefore, adjust the design that
NetworkNotificationManager will get NotificationManager locally.
Bug: 170593746
Test: atest FrameworksNetTests
Change-Id: Id65c998052b7b223171c5194ea46b49d7e84729d
