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 6dc6d2b96498bcca132913dbfc6338f8f9f6c697)
Cleaning up tests, so I can easily add more for restricted networking
mode.
I merged the NetworkManagementInternalTests with the
NetworkManagementServiceTests.
Test: atest NetworkManagementServiceTest
Change-Id: If8c3cc1883cfb2524eeb78e23165fc868130f0e7
On top of being a cleanup this is useful for the S Network
Selection project that will need to enrich the Network
Agent API, and as such should not have to support legacy
agents.
Test: FrameworksNetTests NetworkStackTests
Bug: 167544279
Change-Id: Id3e5f6e19829c64074cd6a52c5f950cee56b860b
ConnectivityService may not be available in a NetworkProvider
constructor, if it is created (but still unused) before
ConnectivityService starts.
As ConnectivityManager is only necessary in
declareNetworkRequestUnfulfillable, which should not be called often,
just query ConnectivityManager at that point.
This is necessary for VcnManagementService, which is started before
ConnectivityService and creates its NetworkProvider in its constructor.
Fortunately VcnManagementService does not call
declareNetworkRequestUnfulfillable at this point.
ConnectivityManager may be migrated to classic service getters that
cache "null" when the service was not available the first time it is
queried, so no system service must query it before it starts.
Bug: 171540887
Test: atest FrameworksNetTests:NetworkProviderTest
Change-Id: I8dadcd0e1360a9464192f330493e13aa69dd9fe2
The class-level @IgnoreUpTo annotation only applies with that runner.
Change-Id: I065618f2345c1d91de2fa1f2f558e5ed5b066f3e
Fixes: 174268969
Bug: 171505922
Test: atest FrameworksNetTests:android.net.OemNetworkPreferencesTest
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
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
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:
Test passing an underlying network array with null network in it.
Make testVpnNetworkActive more deterministic.
Add a test for restricted profile added/removed with VPN up.
This test is a bit brittle because it sets the underlying
networks while the VPN is undergoing validation by
NetworkMonitor. The test does attempt to disable validation,
but that's not actually possible - the only thing that's possible
is to tell NetworkMonitor to validate immediately without sending
any probes. So the underlying network change races with the
validation. I'm not sure why the test isn't flaky. It might be
because both the network change and the validation result in a
capabilities change, and the test expects "a capabilities change"
without expressing what change that should be.
Make this a bit more predictable by ensuring that the network
validates before the underlying networks are set.
This is useful because an upcoming CL will change the way
underlying network capabilities are propagated. With this test
CL, both the old and the new code pass.
Bug: 173331190
Test: test-only change
Change-Id: I319858228e8d097c0b60a107029f296385f91269
Adding @IgnoreUpTo to OemNetworkPreferencesTest so that it can run as
part of MTS.
Bug: 174268969
Bug: 171505922
Test: atest FrameworksNetTests:android.net.OemNetworkPreferencesTest
Change-Id: If7fb039c2cdb061f803c8a59e826e485e1f1c761
The method - satisfiedBy() has changed to canBeSatisfiedBy()
starting from Android R, so the method - canBeSatisfiedBy()
cannot be found when running this test on Android Q.
Ignore verifying canBeSatisfiedBy() on Android Q to fix this
problem.
Bug: 173911834
Test: Run MatchAllNetworkSpecifierTest on Android Q, R, S.
Change-Id: Ibe317b56f82d3ea100b1d78c3907dce4f2fd964d
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
* changes:
Increase test coverage for VPN info sent to NetworkStatsService.
Simplify MockVpn.
Test a VPN with an underlying network that does not yet exist.
Minor fixes to NetworkCapabilities#toString.
MockVpn is very difficult to use because it requires the test
caller keeping track of both the MockVpn object and an
accompanying TestNetworkAgentWrapper.
It's also not very realistic: for example, connect() doesn't
actually connect anything, it just makes it so that if
ConnectivityService tries to update the capabilities, the attempt
will not be ignored. Also, unlike the real code in Vpn, it
connects with empty NetworkCapabilities (in particular, with
empty UID ranges).
Make this easier to use and a bit more realistic by:
- Allowing TestNetworkAgentWrapper to take a "NetworkCapabilities
template" that will form the initial capabilities sent when the
agent registers with ConnectivityService. This allows the VPN
to register its agent with its UID ranges already set, like the
production code does.
- Providing separate methods to register the NetworkAgent and
mark it connected for cases where the test needs to make
changes to the NetworkAgent before connecting (e.g., poking
NetworkMonitor).
- Putting the TestNetworkAgentWrapper inside MockVpn and driving
it through MockVpn's methods. In order not to have too many
wrapper functions (and because we can't delegate like in
Kotlin), there's still an agent() method that returns the
TestNetworkAgentWrapper.
Bug: 173331190
Test: test-only change
Change-Id: I749ff325bc13ac96f512270b86d1f67686eec378
This CL removes four methods in MockVpn by slightly changing the
test code to leverage the actual methods implemented by the
(production) Vpn superclass.
This works because setting mInterface results in
isRunningLocked() returning true, which makes a number of methods
behave as if the VPN is connected (which is what the test
expects).
The more realistic behaviour exposes a minor bug in the treatment
of underlying networks. Add a TODO to fix it.
Bug: 173331190
Test: test-only change
Change-Id: I49421183538ba61ca790af71e309ece36b653bf9
This test checks that if a VPN declares an underlying network
that does not exist, the capabilities of that network are applied
to the VPN as soon as the network starts to exist.
Bug: 173331190
Test: test-only change
Change-Id: Icc0701cb4cea7d91f7738c1e426e94cd26686b74
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
* changes:
Remove unused variables
Return offloaded traffic when querying from TrafficStats API
Add hardware tethering traffic in testTethering test
Remove unused getTetherStats
In Android R, NetworkSpecifier#satisfiedBy() has changed to
NetworkSpecifier#canBeSatisfiedBy(), but its subclass -
MatchAllNetworkSpecifier hasn't.
In Android S, both of MatchAllNetworkSpecifier and
NetworkSpecifier has changed satisfiedBy() to canBeSatisfiedBy().
So if running the latest CTS on R device, it will verify
NetworkSpecifier#canBeSatisfiedBy() instead of
MatchAllNetworkSpecifier#satisfiedBy() and get the unexpected
result.
The fix is to separate 2 tests to verify canBeSatisfiedBy(), one
is for Android R or older version and the other is for Android
S+.
Bug: 172401624
Test: Run MatchAllNetworkSpecifierTest on Android R and S.
Change-Id: I1391bae9a0fc0298beb8fe80b5f388b492244566
Before Android R, getTetherStats were used to collect tethering
iface stats of all clients who extends ITetheringStatsProvider,
which typically contains NetdTetheringStatsProvider and
OffloadController.
However, this always returns 0 since Android R, because:
1. OffloadController implemented NetworkStatsProvider and no
longer reports stats through getTetherStats.
2. NetdTetheringStatsProvider always return 0 by design since
non-offloaded iface tethering stats are already included
in native iface stats.
This change is a no-op refactoring to remove unused
getTetherStats and update test which is not pratical.
Fix for offloaded tethering stats will be in follow-up CLs.
Test: atest FrameworksNetTests TetheringTests
Bug: 162292214
Change-Id: Icd0717c5c2807ae3bd98626b897e4b148f142815
Adding @IgnoreUpTo for NetworkCapabilitiesTest.testOemPrivate so that
this test can run on previous releases.
Bug: 172400600
Bug: 171505922
Test: atest CtsNetTestCasesLatestSdk:NetworkCapabilitiesTest
Change-Id: Ibc728c986ad6faeed78c631ca2675956b95c6ac1
Introduce a shim into DevicePolicyManagerInternal &
DevicePolicyManagerService so that NetworkStatsAccessTest would not
diverge from internal development branches.
The DevicePolicyManagerService refactoring on the internal branch
removed isActiveAdminWithPolicy in favour of isActiveDeviceOwner and
isActiveProfileOwner.
These methods are being made available in AOSP for
NetworkStatsAccessTest.
Bug: 170459325
Test: atest NetworkStatsAccessTest
Change-Id: Ic7e0898989fb8222aaba2b35436765c04eb3250c
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
Connectivity service module is using some AppOpsManager @hide
APIs but they are not able to call after CS become a
mainline module. Thus, replace them with similar System APIs.
Bug: 170593746
Test: atest FrameworksNetTests
Change-Id: I51f66b64fcc3ebdbc2fddff8371eb8d9ff134137
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
Connectivity service module is using some NotificationManager
@hide APIs but they are not able to call after CS become a
mainline module. Thus, replace them with similar System APIs.
Bug: 170593746
Test: atest FrameworksNetTests
Change-Id: I2644867cfc01d8d651c7029134294a9d44fdb471
