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
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
* 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
From S, it's required to specify explicitly either FLAG_MUTABLE
or FLAG_IMMUTABLE when creating a PendingIntent. Thus, add a
mutability flag to the PendingIntent in ConnectivityServiceTest
that doesn't specify it before.
Bug: 173157160
Test: atest FrameworksNetTests
Change-Id: I755c53b90d709dfbac576dc076722476c3edee35
* 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
Currently, NetworkCapabilities's equals and hashCode methods
ignore mOwnerUID. This is confusing because it is inconsistent
with pretty much every other member of this class.
Bug: 175188445
Test: atest CtsNetTestCases:NetworkAgentTest \
CtsNetTestCases:Ikev2VpnTest \
CtsNetTestCases:VpnServiceTest HostsideVpnTests \
CtsNetTestCases:android.net.cts.ConnectivityDiagnosticsManagerTest \
ConnectivityServiceTest com.android.server.connectivity.VpnTest
Change-Id: I2348b7a35f32a931687f2d3c2fa57620a12fe06f
Connectivity service is going to become a mainline module which
will not be able to access hidden APIs. TcpKeepaliveController
is a part of CS mainline module, it uses TcpRepairWindow to
store tcp repair window info. Thus, expose TcpRepairWindow as
module-lib API to support the usage.
Bug: 172183305
Test: atest FrameworksNetTests
Change-Id: I1b6f5ae698f4b6e030a0f776aeafc774fa9f1437
Finally.
Now that mLegacy is always false, removing the support
for legacy agents, a follow-up change will remove
the member and all the associated code.
Test: FrameworksNetTests NetworkStackTests
Bug: 167544279
Change-Id: I6e2c27facdd3ecc232a0aa32bf57c33cb06f118e
