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
(cherry picked from commit 5b90ebaf4d9edefcd9648b46cd0226f882169476)
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
(cherry picked from commit 55229beb747b9e7b8a0f392d855a1b3342df8646)
These were added in aosp/1527378, which is impractical to
backport.
Bug: 172870110
Test: test-only change
Change-Id: Id3d12b23034b284c8f7dffb5167244e1e43987e2
Merged-In: I827543751dbf5e626a24ec02cd6f50b423f5f761
(cherry picked from commit 4c36cb764a6ffbc81acdbf2297cde010a7396f8b)
Bug: 172870110
Test: test-only change
Test: new test passes 100 times in a row
Change-Id: I210284578e38cd25b8b95235d3390d5bd66a5a70
Merged-In: I210284578e38cd25b8b95235d3390d5bd66a5a70
(cherry picked from commit a9aca9744745b7fc8b3d2a1235096982ad8ec8b6)
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
(cherry picked from commit d39cfb8de7ce7a789afd2c9e8ac3ca18fb8186ba)
Current code treats these nulls as if they weren't there.
Bug: 172870110
Test: test-only change
Change-Id: Id4632e1b004c09910b4b7613f7233d2c19e2f0ac
Merged-In: Id4632e1b004c09910b4b7613f7233d2c19e2f0ac
(cherry picked from commit eccd26239024ca2a401e354fb16b855fa72f9923)
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
(cherry picked from commit 0b53357c1a74300319a61890201e56916864309c)
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
(cherry picked from commit a083cb1ffed7a851f2748463a31904fc4c6b625d)
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
(cherry picked from commit 9ededd8476680d40b0b0d5b21e3a4bc0d743adae)
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
(cherry picked from commit a21b2252e0b0eccd482b3b69e67b8911b94dba73)
Previously, the phone ID was appended to the broadcast in DCT and sent
to ConnectivityManager. Instead of sending both as an action, send the
phone ID as an extra instead to make the action a protected broadcast.
Test: manually verify a SecurityException when action provision is sent
Test: atest DcTrackerTest
Bug: 172459128
Change-Id: Ic4129def86949d7191d15056852718dadbd72fba
Merged-In: Ic4129def86949d7191d15056852718dadbd72fba
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
Merged-In: I20d0cad5f902708d366aa703c2893b0ea3e55052
(cherry picked from commit 4787c9bc59556ffb62d3b9d6c894af017d985280)
This change updates the VPN state when IKEv2 sessions fail, and when
configuration errors occur.
Bug: 162289824
Test: Manual testing with IKEv2/PSK
Change-Id: I2e8c6f421d2898f97b0ac422b2276edf9ef923f1
Merged-In: I2e8c6f421d2898f97b0ac422b2276edf9ef923f1
(cherry picked from commit 0be82d4f4cb215e05ca62df80f6a9e652d1d1aa9)
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
Currently, if SIM is inserted but IMSI is not available, such
as SIM PIN locked state. Information of such SIM will still
be available but IMSI is not. Which makes
NetworkStatsSubscriptionMonitor failed to store IMSI locally
for later RAT type query. Hence, NETWORK_TYPE_UNKNOWN is
always returned for such SIM.
Skip the registration until the IMSI is available. This is safe
since there will be another onSubscriptionsChanged event when
that happens.
Test: enable SIM PIN and manually test
Test: atest NetworkStatsSubscriptionsMonitorTest#testSubscriberIdUnavailable
Test: ./out/host/linux-x86/bin/statsd_testdrive 10082
Bug: 160941101
Merged-In: I408379b3c432d9e62e0837d6b4f6551cc7838e29
Change-Id: I408379b3c432d9e62e0837d6b4f6551cc7838e29
(cherry-picked from ag/12400327)
The semantics of FileDescriptor in AIDL are that the callee must close
the file descriptor it receives manually.
Fix: 157789860
Bug: 155136951
Test: treehugger
Change-Id: Ice9fc9abe2959a84ad138a95c900dff676653665
Merged-In: Ice9fc9abe2959a84ad138a95c900dff676653665
(cherry picked from commit db8ae41da255caad7640fc2c1b58d16aafb0e62b)
This adds code to resolve the endpoint in the legacy VPN
runner if it was specified as a hostname, and enables the
previously added test that was disabled because this was
broken until this patch. See the linked bug for details.
This patch uses the async DNS API to do the resolution.
This lets the resolution be fully cancellable, though the
code is more complex than with the non-interruptible
getByName.
Test: VpnTest and in particular VpnTest#testStartRacoon
Fixes the test meant to test this
Also manual testing that resolution of a real
hostname works as expected, that failure to resolve
returns correctly, and that cancellation/interruption
will unblock the thread and terminate immediately.
Bug: 158974172
Change-Id: I90bec6d85706fa9b2f9a01f81701138a54347005
Merged-In: I96691f6091c43377f23a00621242ed034fcb0444
(cherry picked from commit 8ab570d9c9eb5e52b2c038818e3e4d1d3b98fda0)
The legacy VPN has, among many parameters, a host to connect to.
This host can be specified as a numeric address, or as a hostname.
When it's a name, resolution is required. Currently, name
resolution is performed by the native VPN daemons racoon and
mtpd. When a hostname is used, the framework does not know the
IP address of the VPN server and does not add a throw route for
the VPN server IP address. On older kernels this does not matter
because the legacy PPP kernel code binds the PPP socket to the
right network, but on newer devices that use the upstream PPP
code, this does not work. See b/133797637.
This patch instruments the legacy VPN code so that it can be
run in tests, and uses this instrumentation to simulate passing
a configuration that contains a host, and verifies that the
arguments passed to the mptd and racoon daemons receive the
expected server address, and that the expected throw route is
correctly installed.
It then adds two tests : one specifying the server as a numeric
address, and one as a hostname. As the resolution is currently
broken, the latter of these tests is added disabled, and the
followup fix to the issue enables it.
This test is basic and very targeted, but it's what we need right
now. Also there are plans to remove this entire code path in S, so
the test being ad-hoc is not much of a problem.
Test: this
Bug: 158974172
Change-Id: I96f4bbb9b109e3e5813d083bed1989d88fb156b8
Merged-In: I3c4a94181bd71df68121fa0f71669fa4fa588bdd
(cherry picked from commit dece7f3f74cb67f2a046f3a2a9757b559abc2aac)
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
Probe DNS servers to see they support DNS-over-TLS. Use system
CAs to verify whether the certificates sent by DNS servers are
trusted or not. An error is thrown to cause the probe failed if
DNS servers send untrusted certificates.
Unlike the DnsResolver which doesn't verify the certificates
in opportunistic mode, all of the DoT probes from NetworkDiagnostics
check certificates.
DoT probes apply to the DNS servers gotten from LinkProperties
and the DoT servers gotten from PrivateDnsConfig whatever private
DNS mode is.
A common example in DNS strict mode:
. DNS TLS dst{8.8.8.8} hostname{dns.google} src{192.168.43.2:48436} qtype{1} qname{815149-android-ds.metric.gstatic.com}: SUCCEEDED: 1/1 NOERROR (432ms)
F DNS TLS dst{192.168.43.144} hostname{}: FAILED: java.net.ConnectException: failed to connect to /192.168.43.144 (port 853) from /192.168.43.2 (port 41770) after 2500ms: isConnected failed: ECONNREFUSED (Connection refused) (172ms)
. DNS TLS dst{8.8.4.4} hostname{dns.google} src{192.168.43.2:37598} qtype{1} qname{759312-android-ds.metric.gstatic.com}: SUCCEEDED: 1/1 NOERROR (427ms)
An example when the CA is not trusted:
F DNS TLS dst{8.8.8.8} hostname{dns.google}: FAILED: javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found. (16ms)
An example when TCP/TLS handshake timeout:
F DNS TLS dst{8.8.8.8} hostname{dns.google}: FAILED: java.net.SocketTimeoutException: failed to connect to /8.8.8.8 (port 853) from /192.168.2.108 (port 45680) after 2500ms (2514ms)
Bug: 132925257
Bug: 118369977
Test: atest FrameworksNetTests
Original-Change: https://android-review.googlesource.com/1011670
Merged-In: I1b54abed0e931ca4b8a97149459cde54da1c3d6f
Change-Id: I1b54abed0e931ca4b8a97149459cde54da1c3d6f
ConnectivityService puts up some notifications with pending
intents, but these pending intents are mutable that content can
be changed by someone. So make these pending intents to be
immutable.
Some OEMs have their own Settings package. Thus, need to get the
current using Settings package name instead of just use default
name "com.android.settings".
Bug: 154928507
Test: atest FrameworksNetTests
Change-Id: I02e3277358623400aa03dc8996af3d7c46a8ce76
This class might be used by some mainline modules.
Bug: 151052811
Test: atest DnsPacketTest
Test: atest DnsResolverTest
Change-Id: I8841d91456952ded5efbf8ea221289aecc7746ad
