* changes:
Address comments on aosp/1539753, aosp/1542487 and aosp/1547496.
Fix propagating underlying caps when a network disconnects.
Test for bugs with suspended VPN underlying networks.
CaptivePortalData only has 7 fields on R, not 8.
Bug: 177290955
Change-Id: I156738d07821fee43420d8af14c4bce36dd0e4a4
Test: atest CtsNetTestCasesLatestSdk:CaptivePortalDataTest on R
aosp/1513052, which generalized support for underlying networks,
broke default network switching when the network underlying a VPN
disconnects.
This is because it calls propagateUnderlyingNetworkCapabilities
in the middle of the bookkeeping operations needed when a
network is disconnected (specifically, after all satisified
requests are removed from the disconnecting network, but before
mDefaultNetworkNai is updated). This is completely incorrect
because propagateUnderlyingNetworkCapabilities can trigger a
network rematch, and running a rematch when the request data
structures are inconsistent is obviously wrong. See the test
changes in this CL for an example of the damage.
Fix this by moving propagateUnderlyingNetworkCapabilities to
before the bookeeping operations begin. It must be before
mDefaultNetworkNai is updated, because otherwise it will not know
that the default network is disconnecting, and it will not be
able to propagate capabilities to VPNs that set underlying
networks to null (i.e., to the default network). It must be
after the nai is removed from mNetworkForNetId because
otherwise it will think that the underlying network is still
connected.
Bug: 173331190
Test: accompanying unit test shows lots of bugs removed
Change-Id: Ibf376a6fa4b34d1c96f8506fa8abbb7595a8c272
This will be mainly used by VCN management service which will
need to hold the networks but preserve the backgrounded-ness
of the networks.
Test: android.net.ConnectivityManagerTest#testRequestType
Test: android.net.cts.ConnectivityManagerTest#testRequestBackgroundNetwork /
--rerun-until-failure 100
Test: ConnectivityServiceTest#testBackgroundNetworks
Test: m -j doc-comment-check-docs
Bug: 175662146
Change-Id: If9aaa87b7e71c2b695ac7b08858850e975b28bb6
This test flakes about 1% of the time on my device. This is due
to the test calling expectNetworkRejectNonSecureVpn() before the
handler thread has processed the call to setAlwaysOnVpnPackage.
Fix this by waiting for callbacks where it is possible to do so,
and by calling waitForIdle where it is not.
Test: test-only change
Change-Id: Ic5750d4fdf9e7e3654a2b6ade74da6bc5de18fb6
Code review comments have suggested that this test is too long
and difficult to understand. Split it into two tests and put some
of the common setup into setup methods and statics.
Bug: 173331190
Test: test-only change
Change-Id: I9fa888c940d7048f1ba6836a5706fbdb84b5f5c9
These fields have been recently audited, confirmed never to be
null, and annotated @NonNull. Ensure that they can never become
null by throwing exceptions in the codepaths that set them.
Also remove some null checks.
Test: atest FrameworksNetTests
Change-Id: I6ce5bb4d69a990f1c857c599b7e50e372352eb87
If IOException happens while trying to start keepalives sockets,
an invalid fd will be constructed. It will fail with
ERROR_INVALID_SOCKET if the user later calls start(). Current
design to construct the invalid fd use the hidden
ParcelFileDescriptor constructor which will not work for the
incoming ConnectivityService mainline. Thus, replace it with
the other formal API.
Bug: 170598012
Test: atest FrameworksNetTests
Change-Id: I57fd7ec2281c5e8c75481200bbde723ecf96982a
1. network cannot be null because it's final and the only caller
of the constructor passes in a fresh copy.
2. linkProperties cannot be null because:
- The only caller of the constructor passes in a fresh copy.
- The only assignment to nai.linkProperties is in
updateLinkProperties, and that dereferences newLp a few
lines before assigning it.
3. networkCapabilities cannot be null because:
- The only caller of the constructor passes in a fresh copy.
- There are no direct assignments to nai.networkCapabilities.
- All 4 assignments happen via getAndSetNetworkCapabilities:
- registerNetworkAgentInternal, updateCapabilities and
applyBackgroundChangeForRematch all pass in the return
value of mixInCapabilities, which is always non-null.
- updateNetworkInfo re-assigns the capabilities that were
already set in the object.
4. networkAgentConfig cannot be null because it's final and
the only caller of the NetworkAgentInfo constructor passes
in a fresh copy.
Address a TODO in ConnectivityService to remove a check for the
nai's capabilities being null.
Also fix a style nit pointed out by the linter.
Test: atest FrameworksNetTests
Change-Id: I2e265f1c60a73d6da0222dd6711bc53c32db06ec
This is a port of the exemption that exists in WifiPermissionsUtil.
Settings, sysui, network stack needs to be able to access all network
state regardless of location toggle. If we want to move sysui, etc to
retrieve WifiInfo via NetworkCapabilities (which is the current plan),
this exemption is essential since UI should reflect wifi state
regardless of location toggle state.
Bug: 162602799
Test: atest LocationPermissionCheckerTest
Change-Id: I49ce465eccce27bb7a860d882360436fd9ec19c6
The new venue friendly name field is not present on R-
Bug: 162783305
Change-Id: I63bd9c61d27c7d3b07826053373c9c5e38666948
Test: atest FrameworksNetTests
Makes two new SystemApis:
getRestrictedProfileParent()
canHaveRestrictedProfile()
Temporarily disables VPN Tests that rely on the old APIs until those
tests are updated (b/175883995).
Bug: 171529940
Test: atest FrameworksNetTests:com.android.server.connectivity.VpnTest
Test: Tests for UserManager SystemApis are TODO awaiting completion of new user test infrastructure (b/163890431)
(cherry picked from commit dde2e9e897)
Change-Id: I28e39400039631e7d391dc7b0d003e8a38d1f06a
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.
Bug: 173331190
Test: test-only change
Change-Id: Ibada8b4215625e1016d9fd170526206920af76f5
setCurrentProxyScriptUrl is used by ProxyTracker which is
included in connectivity service mainline module. To make
this method @SystemApi in follow-up patch, change this
from a boolean method to a void method. Moving the send or
not send broadcast logic to caller because it can know
whether it needs to send a broadcast or not.
Bug: 177035719
Test: FrameworksNetTests
Change-Id: I7c0fd20bb449463a65952cfa9fb8a42310da079c
Connectivity mainline module cannot use hidden API so
replace Slog with Log which is a public API.
Test: FrameworksNetTests
Change-Id: I8758079cf635ff4ab218df53c0f7bf6fc23ce476
Waiting for idle in testRequestsSortedByIdSortsCorrectly to give it time
to handle async operations as part of registering network callbacks.
Bug: 177376544
Test: atest FrameworksNetTests:ConnectivityServiceTest#
testRequestsSortedByIdSortsCorrectly --rerun-until-failure 200
Change-Id: I268c4607d1a4c79e79f1385f014563cea0c2f979
Generally, a manager class in Android is used to access
system services and it should be obtained from Context.
This class is a bit different from the definition of a
manager class.
API linter will detect an error if trying to expose a
class name end with Manager. ProxyTracker will create a
new instance of this class so this class needs to be
renamed to avoid API lint error.
Bug: 177035719
Test: FrameworksNetTests
Change-Id: I9185d4fb4342bd285a575f0bdd3518b758f37eb6
The first parameter of adding idle timer is an unique identity
to communicate between ConnectivityService and netd. Netd will
notify the activity change using the identity, so it's fine to
replace the legacy type with transport type since we should
deprecate the usage of legacy type.
Bug: 170598012
Test: atest FrameworksNetTests
Change-Id: Ia00606539b86872cca9a92285bd940c8a720a033
Add new capability to indicate whether a network is
managed by Virtual Carrier Network (VCN). This is needed
to identify networks between VCN managed network and
others. And this capability will be:
1. mutable
2. requestable
3. set by default for network agents and requests
4. allowed for test networks
Test: 1. atest FrameworksNetTests CtsNetTestCases
2. adb shell dumpsys connectivity
3. atest ConnectivityServiceTest#testLoseMutableAndRequestableCaps
Bug: 175662146
Change-Id: Ia5eeb3912a687164fa95d7ba5516fd73abca79ba
Changes:
i) Add a new constructor for NetworkCapabilities which accepts whether
location sensitive fields need to be parceled or not. Defalts to false
on the other constructor. This boolean should only be set on the copy of
NetworkCapabilities when sent to apps that hold location permission.
(Similar to how sensitive fields are handled in LinkProperties)
ii) Add a new makeCopy() method in the TransportInfo interface which
accepts whether location sensitive fields need to be parceled or not.
iii) Migrate the existing NetworkCapabilities owner UID masking to use
this new mechanism (instead of existing masking in ConnectivityService).
iv) Always set parcelLocationSensitiveFields to true in the NetworkAgent
surface (since that is a privileged surface from the transports to the
connectivity service)
v) Add a hasSensitiveFields() in TransportInfo interface to avoid
perfoming location permission checks for location insensitive
TrasnsportInfo.
Also, migrate to the new SdkLevel util for isAtLeastR() & isAtLeastS()
checks.
Bug: 162602799
Test: atest android.net
Test: atest com.android.server
Change-Id: Ie522d8c75a82ae521ccfd5165823d0c72642e651
Merged-In: Ie522d8c75a82ae521ccfd5165823d0c72642e651
