Previously, the phone ID was appended to the broadcast in DCT and sent
to ConnectivityManager. Instead of sending both as an action, send the
phone ID as an extra instead to make the action a protected broadcast.
Test: manually verify a SecurityException when action provision is sent
Test: atest DcTrackerTest
Bug: 172459128
Change-Id: Ic4129def86949d7191d15056852718dadbd72fba
getActiveNetworkQuotaInfo has never been in API surface since it
was introduced. It became essentially functionless since android O,
so there should be no usage dependency upon the hidden method,
In order to support ConnectivityService mainline, remove the
useless function to prevent necessary dependency.
Bug: 172183305
Test: atest FrameworksNetTests
Change-Id: Ia685b3260256d465ef614b2f577d13344074c787
This is consistent with NattKeepalivePacketData, which is also a
subclass of KeepalivePacketData.
TcpKeepalivePacketData is already used by the wifi module, but
statically linked.
Bug: 172789687
Test: m
Change-Id: I6aee1ae205987521bea4a3838bbece279ffa0e37
Currently, ConnectivityService assumes that only VPNs can have
underlying networks. Make the code decide this based only on the
return value of NetworkAgentInfo#supportsUnderlyingNetworks.
This allows non-VPN network types to support underlying networks
in the future.
This requires storing the original agent's capabilities in
NetworkAgentInfo so that applyUnderlyingCapabilities can mix in
the underlying network capabilities without overwriting the
capabilities of the network itself. Currently, the only
information that applyUnderlyingCapabilities takes from the
original agent's capabilities are the metered bit (stored in
NetworkAgentInfo#declaredMetered) and the transports (assumed to
be exactly {TRANSPORT_VPN}. Store the full capabilities instead.
This is more state than needed but it ensures that we do not need
to make any changes if in the future we want to propagate new
types of information from the underlying networks.
This should have no impact on current use cases (i.e., VPNs).
There is a change in ordering: in disconnectAndDestroyNetwork,
the new code propagates underlying network capabilities before
removing the network from LegacyTypeTracker, instead of after.
This is done to simplify the new code. When the new code
propagates underlying network capabilities in response to a
change for a particular network (e.g., connect, disconnect,
capabilities change), it only considers networks that have the
changed network as underlying. Because determining the
underlying networks requires knowing the default network,
the new code runs before the default network is changed and
LegacyTypeTracker is updated.
This shouldn't have app implications because the connectivity
broadcasts sent by LegacyTypeTracker and the callbacks cannot be
ordered, since they run on separate threads with unpredictable
delays. The capability change callbacks resulting from
propagation of underlying network capabilities were already
sent before the rematch, so the callbacks themselves are not
reordered in any way.
Bug: 173331190
Test: atest FrameworksNetTests \
CtsNetTestCases:NetworkAgentTest \
CtsNetTestCases:Ikev2VpnTest \
CtsNetTestCases:VpnServiceTest \
CtsNetTestCases:android.net.cts.ConnectivityDiagnosticsManagerTest \
HostsideVpnTests com.android.server.connectivity.VpnTest
Change-Id: Ic5353a928a3a3541dcf953c35f47277c5e295db8
* changes:
Remove support for legacy network agents
Remove deprecated constructors for NetworkAgent
Migrate NetworkAgentWrapper to the new NA API
Cleanup TestNetworkService
ConnectivityService is using
PackageManager#getApplicationInfoAsUser() to get application
info but this API is not able to call after CS becomes a
mainline module. Thus, replace it with formal API.
Bug: 170593746
Test: atest FrameworksNetTests
Test: atest CtsNetTestCasesLegacyApi22
Change-Id: Idd1269aa50e234801583097bb6f40b099bab8fba
ConnectivityService is going to become a mainline module which
cannot access hidden APIs. Thus, replace the VPN uid range
controlling APIs from NMS to INetd directly.
Bug: 170598012
Test: atest FrameworksNetTests
Test: atest HostsideVpnTests
Test: manually test to connect to VPN and check the uid range
Change-Id: Ie6656ef36f54c2f14d5a2899e763a29b70a30f5d
* 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
UserManager#getUsers() is a hidden API, use getUserHandles() to
get user id instead in PermissionMonitor.
Bug: 171529940
Test: atest FrameworksNetTests
Change-Id: Ic304627688de8e49505a95ebc99628b2e0eafab9
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
Very small cleanup where arguments to TestNetworkAgent should
have the same order as the callee. Also remove an unused member.
Test: FrameworksNetTests NetworkStackTests
Change-Id: I9da16bc81be8524e227a7f7e83760882bc4d77e5
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
