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
Merged-In: Ic4129def86949d7191d15056852718dadbd72fba
Allow ConnectivityServiceTest to change the UID by replacing
static calls to Binder.getCallingUid() with a method that can
be mocked.
Add registerNetworkCallbackAsUid as an initial way to exercise
this, and add some test coverage to the always-on lockdown test
to confirm that things are working as expected.
Bug: 173331190
Test: new unit tests
Change-Id: Ie0b32460e20e5906a0f479191e11a062f21cc608
This requires mocking lots of new things that weren't mocked
before but is otherwise fairly straightforward.
A few changes to MockVpn are needed as well:
1. Set the VPN's NetworkInfo to CONNECTED, so methods such as
isBlockingUid will work. While I'm at it, set the interface on
the LinkProperties as well to make things a bit more
realistic.
2. Constructs the VpnConfig when registering the agent, not when
the MockVpn is created. This is needed because starting and
stopping lockdown VPN calls prepare, which nulls out mConfig.
But constructing the VpnConfig when registering the agent is
more realistic anyway. The production code does that in
establish, but we can't do that in ConnectivityServiceTest
because some of the test cases don't call establish and call
registerAgent directly.
Bug: 173331190
Test: atest FrameworksNetTests
Change-Id: I827543751dbf5e626a24ec02cd6f50b423f5f761
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
Merged-In: 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
Instead of statically linking against and jarjaring
TcpKeepalivePacketData, use the new android.net.TcpKeepalivePacketData
API for S. On R, build the KeepalivePacketDataParcelable from the base
KeepalivePacketData class.
The current ClientModeImpl code that uses a statically linked
TcpKeepalivePacketData is actually broken, as since R the system_server
has been sending a @hide android.net.TcpKeepalivePacketData, and
ClientModeImpl was testing it against com.android.wifi.x.android.net.*.
To fix this on R, this change rebuilds a
TcpKeepalivePacketDataParcelable class from the packet data included in
the base KeepalivePacketData class.
Bug: 172789687
Test: atest ConnectivityManagerTest#testCreateTcpKeepalive
See associated test change
Change-Id: Ia32b4444dbf90306b2cfd37ec13d4ba4e90cd1e8
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
In preparation of future modularization of connectivity classes, a large
part of frameworks/base/services/net is planned to be moved to
packages/modules/Connectivity. However moving each class "manually"
to that git project would lose their commit history, and require many
cross-repository topics.
To facilitate the work, create frameworks/base/packages/Connectivity,
which will be used to move the classes at first, before they can all be
moved together with their history to packages/modules/Connectivity. This
mirrors the procedure used for NetworkStack, Tethering,
CaptivePortalLogin, etc. previously.
The added OWNERS file just imports owners from the previous file
location.
Bug: 171540887
Test: m
Change-Id: Ic1c0dbbe8c1f07582c04757ced0ead2fc5b10ca7
CAPTIVE_PORTAL is a CS-managed capability, and causes CS to log a wtf.
When this test is run on an eng build, this sends SIGSEGV to the test,
which is pretty difficult to debug.
Test: FrameworksNetTests NetworkStackTests
Change-Id: I72fc46a6daa4e886425b4dc967318cca9f1a5302
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
