sendNetworkConditionsBroadcast is removed, so
TestNetworkStackService.kt cannot override it anymore,
otherwise there will be a build break when running this
test.
Also add a comment for NETWORK_CONDITIONS_MEASURED in
AndroidManifest.xml.
Bug: 175213041
Test: atest FrameworksNetIntegrationTests
Change-Id: I7b43940dc32826c70fa82f471b35bc5cb8394aad
Merged-In: I7b43940dc32826c70fa82f471b35bc5cb8394aad
sendNetworkConditionsBroadcast is removed, so
TestNetworkStackService.kt cannot override it anymore,
otherwise there will be a build break when running this
test.
Also add a comment for NETWORK_CONDITIONS_MEASURED in
AndroidManifest.xml.
Bug: 175213041
Test: atest FrameworksNetIntegrationTests
Change-Id: I7b43940dc32826c70fa82f471b35bc5cb8394aad
Currently, when the VPN underlying network changes from a
network that is not suspended to one that is suspended (or vice
versa), some of the legacy APIs return incorrect results.
This is because the VPN's NetworkInfo can get into SUSPENDED
state even though the capabilities have the NOT_SUSPENDED
capability. This happens because the code in updateCapabilities
that checks for changes in NOT_SUSPENDED and NOT_ROAMING (which
are the capabilities that can affect the NetworkInfo state) is
only run when the capabilities change in a certain way.
Fix this by always checking for changes in these capabilities,
regardless of what else has changed.
This results in sending a lot more SUSPENDED and RESUMED
callbacks than the code sent previously. This should hopefully
not impact apps because those callback methods have never been
public API, though because they're just callbacks, it's possible
that apps found out via code inspection that the callbacks
existed and implemented them.
Bug: 172870110
Test: changes to existing tests in ConnectivityServiceTest
Change-Id: I6ec246a6a4e61f634956a165797fbb80296efd6a
Merged-In: I6ec246a6a4e61f634956a165797fbb80296efd6a
This test coverage is necessary to fix an upcoming bug in R.
Backport it from the change that added it. The non-test portion
of that change is not necessary in R because it fixes a
bug that was introduced in S.
Bug: 172870110
Test: accompanying unit test shows lots of bugs removed
Change-Id: If7eb8857474d8b4f774f5fa5db2a3112e85c9cae
Merged-In: Ibf376a6fa4b34d1c96f8506fa8abbb7595a8c272
These were added in aosp/1527378, which is impractical to
backport.
Bug: 172870110
Test: test-only change
Change-Id: Id3d12b23034b284c8f7dffb5167244e1e43987e2
Merged-In: I827543751dbf5e626a24ec02cd6f50b423f5f761
Bug: 172870110
Test: test-only change
Test: new test passes 100 times in a row
Change-Id: I210284578e38cd25b8b95235d3390d5bd66a5a70
Merged-In: I210284578e38cd25b8b95235d3390d5bd66a5a70
We currently test CONNECTIVITY_ACTION broadcasts by directly
registering BroadcastReceivers with BroadcastInterceptingContext,
and making the receivers unregister themselves when all the
broadcasts they expect have been received.
This works for current test cases, but does not work if anything
registers another receiver for CONNECTIVITY_ACTION. In that case,
when we unregister the receiver in the receiver's onReceive
method, BroadcastInterceptingContext will throw a
ConcurrentModificationException because the list of receivers is
being modified during iteration.
Fix this by adding an ExpectedBroadcast class that stores the
receiver and unregisters the receiver only when the test checks
that the broadcast was received, which happens after the receiver
runs. This is easier to use and also guarantees that the receiver
is unregistered even if the test is expecting that the broadcast
is never fired. Accordingly, remove mRegisteredReceivers and the
code that uses it; it's no longer necessary now that
ExpectedBroadcast always unregisters its receivers.
Also add a convenience expectConnectivityAction method to expect
a CONNECTIVITY_ACTION broadcast with specific contents. This
makes the test easier to read and more detailed. Convert some
existing tests to this method.
While I'm at it, fix a test that was using "mCellNetworkAgent" to
represent a wifi network.
R backport notes: added import for NetworkInfo.DetailedState.
That was added in aosp/1527378, which is impractical to backport.
Bug: 172870110
Test: test-only change
Change-Id: Ibada8b4215625e1016d9fd170526206920af76f5
Merged-In: Ibada8b4215625e1016d9fd170526206920af76f5
Current code treats these nulls as if they weren't there.
Bug: 172870110
Test: test-only change
Change-Id: Id4632e1b004c09910b4b7613f7233d2c19e2f0ac
Merged-In: Id4632e1b004c09910b4b7613f7233d2c19e2f0ac
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: 172870110
Test: test-only change
Change-Id: I319858228e8d097c0b60a107029f296385f91269
Merged-In: I319858228e8d097c0b60a107029f296385f91269
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: 172870110
Test: test-only change
Change-Id: I749ff325bc13ac96f512270b86d1f67686eec378
Merged-In: 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: 172870110
Test: test-only change
Change-Id: I49421183538ba61ca790af71e309ece36b653bf9
Merged-In: 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: 172870110
Test: test-only change
Change-Id: Icc0701cb4cea7d91f7738c1e426e94cd26686b74
Merged-In: Icc0701cb4cea7d91f7738c1e426e94cd26686b74
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.
Original-Change: https://android-review.googlesource.com/1508137
Merged-In: Ibe317b56f82d3ea100b1d78c3907dce4f2fd964d
Change-Id: Ibe317b56f82d3ea100b1d78c3907dce4f2fd964d
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: I9aeddaa3e331f609bbdba8ab0c2d6e014123f242
Merged-In: I1391bae9a0fc0298beb8fe80b5f388b492244566
MatchAllNetworkSpecifier is a subclass of NetworkSpecifer. The method
satisfiedBy should be renamed to canBeSatisfiedBy together with other
subclass of NetworkSpecifer in b/152238712.
Add annotation @Overide for the method to make sure it will not get
ignored when refactor in the future.
Bug: 154956584
Test: atest android.net.MatchAllNetworkSpecifierTest
Original-Change: https://android-review.googlesource.com/1295946
Merged-In: Ibe32fd50fae43aa635c1c0dad66eaea82011c8b7
Change-Id: Ibe32fd50fae43aa635c1c0dad66eaea82011c8b7
Network specifiers are used for 2 purposes:
- As part of network requests to specify more information on the type
of requested networks.
- On network agents to specify information about their networks.
The network specifiers of the requests and agents are matched to each
other. However, the agent network specifier may contain sensitive
information which we do not want forwarded to any app.
This CL adds an option to strip out this agent network specifier before
the network capabilities are forwarded to the app.
Bug: 161853197
Bug: 161370134
Test: atest ConnectivityServiceTest (frameworks/base/tests/net)
Test: atest frameworks/base/tests/net
Test: atest frameworks/opt/net/wifi/tests/wifitests
Test: atest frameworks/opt/telephony/tests/telephonytests
Test: atest frameworks/opt/net/ethernet/tests
Test: atest android.net.cts - some flakiness!
Test: act.py ThroughputTest
Test: act.py DataPathTest
Test: atest SingleDeviceTest (cts)
Change-Id: I38ed3ff88532ef522ab167c88d87e6e82295ffc5
Merged-In: If08d312ff814bdde1147518f923199e6349503d5
Ideally the module branch would be unbundled and contain no framework
code or framework tests. Start by disabling the tests (which are not run
in this branch anyway) as they depend on test utils that are updated in
the module projects, but cannot be kept in sync as the latest tests
verify platform behavior that does not exist in the module branch.
Test: m
Bug: 166414751
Change-Id: I96f217663b073ada40710c0c8cdcb39b775eef55
Callers don't care what language the utilities are written in
This is a partial cherry-pick of the change in the packages/Tethering,
tests/net/common, tests/net/integration, wifi/tests directories. Other
tests cannot be kept in sync as the latest versions verify platform
functionalities that do not exist in the module branch, so disabling
them is less time-consuming than always resolving merge conflicts.
Test: builds
Merged-In: Ie212144f36c50db223c05f3fcb6bad745842cb5e
Change-Id: Ie212144f36c50db223c05f3fcb6bad745842cb5e
This package is using some common utilities from
a library that used to live in the network stack.
A better home for these utilities is frameworks/libs,
so this topic moves the files ther and also changes
the package of some utilities.
See aosp/1350222 and aosp/1350182 for a detailed
description of the specific files that moved.
Test: checkbuild
Original-change: aosp/1350083
Merged-In: I76a9b7790f3997e3e6b3c2f75ba6308286457cde
Change-Id: I76a9b7790f3997e3e6b3c2f75ba6308286457cde
For non-telephony networks, this was always set to 0 before R.
In R, it is currently set to the same value as the network type.
This is incorrect because the two have different namespaces.
or example, currently, any network of type WIFI (==1) will have
a subtype of NETWORK_TYPE_GPRS (==1). Similarly, all ETHERNET
networks will have subtype NETWORK_TYPE_1XRTT, all VPN networks
will have a subtype of NETWORK_TYPE_TD_SCDMA, etd.
Bug: 161653721
Test: builds, boots
Change-Id: I07e111c1762e0021c931cefc27f193f78578748b
This change updates ConnectivityService to notify the
ConnectivityDiagnosticsHandler of app-reported connectivity before
attempting to revalidate the network. This change forces an ordering on
Connectivity Diagnostics events in the case that the reported
connectivity does not match the known connectivity for the network -
this leads to the network being revalidated and the
ConnectivityDiagnostics event onConnectivityReportAvailable. Passing the
onNetworkConnectivityReported event to the
ConnectivityDiagnosticsHandler first ensures that it is passed to
callbacks before any potential ConnectivityReports are.
Bug: 159718782
Test: android.net.cts.ConnectivityDiagnosticsManagerTest
Original-Change: https://android-review.googlesource.com/1350662
Merged-In: Ic7bc7138c54c47bbfdf56af5811709fde66f8606
Change-Id: Ic7bc7138c54c47bbfdf56af5811709fde66f8606
Check one more parameter enforceDnsUid in ResolverOptionsParcel in
DnsManagerTest.
Bug: 159587277
Test: atest
com.android.server.connectivity.DnsManagerTest#testSendDnsConfiguration
Change-Id: Ic53f42b968626294c851dac252a70769846ba427
