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
BasicShellCommandHandler is used by mainline modules and the
framwork. There is a new repo that was created for putting
this kind of utility class. Move BasicShellCommandHandler for
the incoming ConnectivityService mainline and updating the
related usage.
Bug: 170598012
Test: m ; verify with adb shell cmd
Change-Id: I8a2873df6e7d8342b7a8b466bda155f74c807ee3
Merged-In: Ida30c877116090616d4bf3f87fdad835446dac84
1. The current code only prints the array of administrator UIDs
if it's empty. This is clearly an oversight. Print it only if
it's non-empty.
2. Only print requestor UID and package name if they are set.
This makes output shorter in the common case that they are
unset.
3. Reorder the output at the end: group all UIDs together, and
place SSID and private DNS broken bit after that.
4. Make the private DNS broken indication a single word instead
of a sentence. This saves space and makes it easier to write
regexps.
New format:
... SignalStrength: -72 OwnerUid: 1000 AdminUids: [1000] SSID: ...
... Uid: 1000 RequestorUid: 1000 RequestorPkg: android ...
Test: manual
Change-Id: I2f5ccc1d9e4af6ddacc4d193185a17723822972b
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
ConnectivityService is going to become a mainline module which
is not able to access hidden API. Thus, replace the usage from
NMS to INetd.
Bug: 170598012
Test: atest FrameworksNetTests ConnectivityManagerLegacyTest
Change-Id: Ice1bd1effab26555917bc1766354aeaebd41ad66
Updating comments for network preferences to better clarify that
preferences which include more than one network type will then rely on
scoring to determine which of those networks are chosen.
Bug: 171795464
Test: atest FrameworksNetTests
Change-Id: I9eb5683f2cd69281bbee9fb70028d45f07720914
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
Updating NetworkRequestInfo for "multilayered requests" functionality so that
requests can support a network hierarchy. I.e., requests network
with capability A first and if not available, request network with
capability B. This CL is the first step in adding that support by
updating the request object from a single request to a collection.
Bug: 171991028
Test: atest FrameworksNetTests
atest NetworkStackTests
atest FrameworksNetIntegrationTests
atest NetworkStackIntegrationTests
atest CtsNetTestCasesLatestSdk
Change-Id: I64a124802986e4cf4aa7de158c6690fdf9851cb2
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
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Merged-In: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
Change-Id: I54e5ecd11e76ca1de3c5893e3a98b0108e735413
ConnectivityService is going to be a mainline module, it can only
use formal APIs or @SystemApi. So use @SystemApi
hasIpv4DefaultRoute and hasIpv6DefaultRoute instead of
hasIPv4DefaultRoute and hasIPv6DefaultRoute.
Bug: 172183305
Test: atest FrameworksNetTests
Change-Id: I67e5fa234fbb6d0b9739ae3295eb0b0ea108f582
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
ConnectivityService mainline module cannot call the members
inside SystemNotificationChannels.java. So use the local defined
constants instead.
Bug: 172040168
Test: atest FrameworksNetTests
Test: Manual test NO_INTERNET, SIGN_IN, PARTIAL_CONNECTIVITY,
VPN_ALWAYS_ON notifications.
Change-Id: I223b207c4346e8239dee78e50dd2b0532a3e55b0
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
