Update to ConnectivityService.unneeded in order to support multilayered
requests.
Bug: 173432311
Bug: 171991028
Test: atest FrameworksNetTests
atest FrameworksNetIntegrationTests
atest CtsNetTestCasesLatestSdk
Change-Id: If040d61e33d86a9f9bbc7d50ead596d210a4f82c
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
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
The current behaviour is at least bizarre and arguably incorrect.
Add a test to document the current behaviour so we can check that
any changes we make to this behaviour are correct.
Test: test-only change
Change-Id: I345bd320eced96316d92e520f576ae06b8020d9f
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
The legacy metrics are deprecated, and CaptivePortal is planned to move
to a connectivity-specific jar which cannot reference MetricsEvents.
Bug: 171540887
Test: m
Change-Id: I409375de3844a7fedef707cf9e19a106d82a8e3a
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
