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
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 0be82d4f4c)
This CL passes the correct install user when creating sessions in
StagingManager and effectively reverts ag/6901350.
Add a test to ensure b/129397974 is not regressed as described in
b/158222747#comment11.
(Cherry-picked from 838dea54ca)
Fix: 129744602
Fix: 158222747
Test: atest MultiUserRollbackTest#testStagedRollback
Merged-In: I718992240aa76898ff9e4220ea6a769ee8cd61f5
Change-Id: I718992240aa76898ff9e4220ea6a769ee8cd61f5
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)
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 8ab570d9c9)
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 dece7f3f74)
This change handles the case of split APKs. All files starting with
"NetworkStack" will be returned as split APKs.
See b/159978937#comment6. NetworkStack is changed from a single APK to
split APKs. We need this change for install to succeed.
Bug: 159978937
Test: atest NetworkStagedRollbackTest
Change-Id: I20f5fee08ea208ba4dc7711d82a1718239c647c2
It seems adb shell stop/start has a bug with taking up disk
space. For now, use a full reboot of the device for each
test step.
This will double the already extremely long test time, so the
entire PackageManagerServiceHostTests module has been moved
to postsubmit, except for tests annotated @Presubmit, of which
there are none as of this change.
Bug: 159540015
Bug: 159256824
Test: atest PackageManagerServiceHostTests
Change-Id: I67da61cb02baa572fc298e6f617d6e53ec2c4724
Since rebooting system server requires root, we had to create a new
internal test suite with root access.
Bug: 158283778
Test: StagedInstallInternalTest#
testSystemServerRestartDoesNotEffectStagedSessions
Change-Id: Id37111c0e63025aabe58cc9c8ab39b0362f1aed4
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
This class might be used by some mainline modules.
Bug: 151052811
Test: atest DnsPacketTest
Test: atest DnsResolverTest
Change-Id: I8841d91456952ded5efbf8ea221289aecc7746ad
This is a Client-only solution.
- Add to NetdClient a per-process std::atomic_boolean
similar to netIdForProcess and netIdForResolv.
- The boolean says whether the process should be
allowed Internet connectivity.
- Add an @hide method to NetUtils.java to set the boolean;
call it from the initialization code of the new
process just after forking from zygote.
- Make netdClientSocket and dnsOpenProxy check the
boolean. If the boolean is false, return EPERM from
socket calls.
Bug: 150028556
Test: atest NetworkUtilsTest
Test: atest CtsAppSecurityHostTestCases:UseProcessTest
Change-Id: If002280fbad493dfc2db3d9d505c0257d49a9056
Exempt-From-Owner-Approval: OWNERS already approved identical patchset 5
On Android different interfaces usually use different routing tables.
As a result, a change in interface should not be treated as route
update, but rather a remove and an add.
This change fixes a bug in VPN seamless handover where routes
failed to be updated when a new tunnel interface replaces the existing
one within the same network.
Bug: 158696878
Test: atest com.android.cts.net.HostsideVpnTests
Test: atest NetworkStackTests
Test: atest CtsNetTestCases
Test: atest FrameworksNetTests
Original-Change: https://android-review.googlesource.com/1331916
Merged-In: I57987233d42a0253eaee2e1ca5f28728c2354620
Change-Id: I57987233d42a0253eaee2e1ca5f28728c2354620
Test extra info sent to NetworkMonitor correctly if network
agent is created through new NetworkAgent constructor without
legacy network info taken as parameter.
Bug: 156173829
Test: atest FrameworkNetTests
Merged-In: I4f827664c528bea30cc957a0a617dd37693f4460
Change-Id: I4f827664c528bea30cc957a0a617dd37693f4460
The classes should not be picked up from frameworks/base, as they are
part of several mainline modules.
Also refine comments in DhcpResults following feedback in previous
change.
Bug: 151052811
Test: m; manual: flashed, wifi and telephony working
Test: atest NetworkStackCoverageTests
Change-Id: I7074651c6a2a7a6b11bcf13cc4bb03833d7d655f
This broke in P. Basic support was broken by a simple negation
issue with the logic that checks for the original package.
That, along with the suggestion in the bug to fix the renamed
package association means this should now work as expected,
carrying data over from a previous installed, differently named
package.
Bug: 131355130
Bug: 132749720
Bug: 111967720
Test: atest PackageManagerServiceHostTests
Change-Id: Ifc4c7af47c4b633cd27ba4a40b6baa0e27960d71
The extra info is taken into NetworkMonitor from while creating
it. The NetworkMonitor is created when a new agent is registered
but the extra info is not available at that time. Make sure the
field is set in the NetworkInfo when registering.
Bug: 156173829
Test: adb shell dumpsys network and check the apn in the extra
info shown correctly
Test: atest FrameworkNetTests
Merged-In: Ieaad8cbf1a28af3b97c7f98f74358e417fcad661
Change-Id: Ieaad8cbf1a28af3b97c7f98f74358e417fcad661
See comment#6.
Clean up rollbacks and test apps before and after running tests.
This ensure we are in a good and expected condition when running tests.
Bug: 154080003
Test: atest RollbackTest
Test: atest MultiUserRollbackTest
Test: atest NetworkStagedRollbackTest
Test: atest StagedRollbackTest
Change-Id: If10fc8865e644611f1cf6a9db9d6dca6c7f11aee
Ensure that calls to sync requests with the explicit health
check controller are always sent if the list of packages
pending health checks is empty, so that the controller can
unbind. This will allow extservices to be killed by lmkd
on low memory devices.
Test: atest PackageWatchdogTest
Test: atest NetworkStagedRollbackTest
Test: check logcat to see that the service is unbound
Bug: 156323728
Change-Id: If615a337760b2057b962284bde8565b593d82a50
