Revert "WifiLocationTest: Add test for Wifi TransportInfo"
Revert "WifiInfo: Embed location sensitive TransportInfo"
Revert submission 13274595
Reason for revert: DroidMonitor: Potential culprit for Bug 177390648 - verifying through Forrest before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Reverted Changes:
Ibcf0c6711:WifiInfo: Embed location sensitive TransportInfo
Ic68546e2a:WifiService: Use WifiInfo for masking
Ie522d8c75:NetworkCapabilities: Embed location senstive Trans...
Iaf0fef999:WifiLocationTest: Add test for Wifi TransportInfo
I017de6d4c:ClientModeImpl: Fill info elements for connected b...
I384c9321e:WifiInfo: Add info elements for connected bssid
Change-Id: I4e96850b96dc5ea71d9bb6af2ff17343b8d09d68
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
Netd currently calls maybeCloseSockets before adding/removing users for
network. The task should be moved from netd to CS. In this way, we can
handle WiFi lingering more easily in the future.
Test: atest HostsideVpnTests
Test: atest FrameworksNetTests
Change-Id: Icf8125e8552c89da367a67f48611ed193a1a343d
Currently, ConnectivityService calls the IpConnectivityMetrics
service class directly to log default network events. This is
incompatible with ConnectivityService being in a mainline module.
Replace direct access to IIpConnectivityMetrics with public
methods in IpConnectivityLog, which is @SystemApi class.
The new methods are not yet @SystemApi, but they can be made so
if desired. Alternatively, these metrics could be deleted.
Also remove the IpConectivityMetrics service from the
service-connectivity JAR, and go back to starting it from
SystemServer.java, which is what was happening a few hours ago
before aosp/1542626 was merged.
Test: builds, boots
Test: atest FrameworksNetTests
Test: "dumpsys connmetrics" shows events, including default network events
Change-Id: I9d6147d93590363a2f8f83f39f05c03d001b4851
Extend CaptivePortalData with a member to hold the venue friendly
name. If CaptivePortalData is initialized by both the network
agent and Capport, merge the two objects to include the venue
friendly name and prioritize the venue URL from the network
agent.
Bug: 162783305
Test: atest ConnectivityServiceTest
Test: atest CtsNetTestCasesLatestSdk:CaptivePortalDataTest
Test: End-to-end test
Change-Id: I4fdf356be42237c5b6c0ae5bacfd3cec4726861b
This code is no longer used. Delete it and the tests for it.
One of the tests checks that when a restricted profile is added,
the lockdown UID rules are updated to cover that profile as well.
ConnectivityServiceTest does not currently has coverage for this,
so add it.
Bug: 173331190
Test: moved unit test from VpnTest to ConnectivityServiceTest
Change-Id: Ic350b90946870890bf031668bb5c201037b0bd15
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
Currently, when an always-on VPN is set in lockdown mode, Vpn
configures prohibit UID rules in netd directly and does not
inform ConnectivityService of the fact.
This means that ConnectivityService cannot send NetworkCallbacks
that tells apps that they are blocked or unblocked. It also means
that ConnectivityService has to take the mVpns lock and call into
Vpn to allow synchronous APIs such as getActiveNetwork to return
BLOCKED if the app is blocked.
Move all this to ConnectivityService:
- Add a setRequireVpnForUids API to ConnectivityManager, and have
that pass the routing rules to netd.
- Update VpnTest to expect calls to ConnectivityManager instead
of to netd.
- Whenever setRequireVpnForUids is called, ensure that
ConnectivityService sends onBlockedStatusChanged to the
affected callbacks.
- Update existing unit tests to check for callbacks.
- Add a way to find the VPN that applies to a given UID without
taking the VPN lock, by instead scanning all connected VPNs.
Use this as a replacement for direct access to mVpns.
For simplicity, and in order to ensure proper ordering between
the NetworkCallbacks sent for VPNs connecting and disconnecting,
process blocked UID ranges on the handler thread. This means that
when setRequireVpnForUids returns, the rule changes might not
have been applied. This shouldn't impact apps using network
connectivity, but it might mean that apps setting an always-on
package, and then immediately checking whether networking is
blocked, will see a behaviour change.
Bug: 173331190
Fix: 175670887
Test: new test coverage in ConnectivityServiceTest
Test: atest MixedDeviceOwnerTest#testAlwaysOnVpn \
MixedDeviceOwnerTest#testAlwaysOnVpnLockDown \
MixedDeviceOwnerTest#testAlwaysOnVpnAcrossReboot \
MixedDeviceOwnerTest#testAlwaysOnVpnPackageUninstalled \
MixedDeviceOwnerTest#testAlwaysOnVpnUnsupportedPackage \
MixedDeviceOwnerTest#testAlwaysOnVpnUnsupportedPackageReplaced \
MixedDeviceOwnerTest#testAlwaysOnVpnPackageLogged \
MixedProfileOwnerTest#testAlwaysOnVpn \
MixedProfileOwnerTest#testAlwaysOnVpnLockDown \
MixedProfileOwnerTest#testAlwaysOnVpnAcrossReboot \
MixedProfileOwnerTest#testAlwaysOnVpnPackageUninstalled \
MixedProfileOwnerTest#testAlwaysOnVpnUnsupportedPackage \
MixedProfileOwnerTest#testAlwaysOnVpnUnsupportedPackageReplaced \
MixedProfileOwnerTest#testAlwaysOnVpnPackageLogged \
MixedManagedProfileOwnerTest#testAlwaysOnVpn \
MixedManagedProfileOwnerTest#testAlwaysOnVpnLockDown \
MixedManagedProfileOwnerTest#testAlwaysOnVpnAcrossReboot \
MixedManagedProfileOwnerTest#testAlwaysOnVpnPackageUninstalled \
MixedManagedProfileOwnerTest#testAlwaysOnVpnUnsupportedPackage \
MixedManagedProfileOwnerTest#testAlwaysOnVpnUnsupportedPackageReplaced \
MixedManagedProfileOwnerTest#testAlwaysOnVpnPackageLogged
Test: atest FrameworksNetTests HostsideVpnTests \
CtsNetTestCases:VpnServiceTest \
CtsNetTestCases:Ikev2VpnTest
Change-Id: Iaca8a7cc343aef52706cff62a7735f338cb1b772
Currently, when network factory is under testing, but failed
without terminating the network factory. The mocked network
factory will stay registered and trigger another assertion
fail in teardown(). Thus, the test suite will only shows
the callstack that generated in teardown() instead of the
original fail. The error message is misleading and not useful
at all.
Thus, safely terminate and quit mocked network factory after
testing to prevent assertion fail in teardown().
Test: atest ConnectivityServiceTest#testMobileDataAlwaysOn
Bug: 175180558
Change-Id: I0f96332cc05221e576bd792c6cd26d9dccb4e228
Connectivity service is going to become a mainline module which
will not able to access hidden APIs. Thus, use formal API
Context#getSystemService() to get network policy service instead
of hidden API ServiceManager#getService().
Bug: 170598012
Test: atest FrameworksNetTests FrameworksNetIntegrationTests
Change-Id: I4f286264b5800b2b922f85a76ddd20d64d53000a
Use two oneway binder interfaces instead.
The interfaces post messages to handlers as was implemented before, but
provide a more strictly defined interface, with less hops between
NetworkAgent, AsyncChannel, and ConnectivityService.
The actual public interface is the NetworkAgent @SystemApi: the binder
interface is an internal implementation detail.
Test: atest FrameworksNetTests CtsNetTestCasesLatestSdk
Bug: 173574274
Merged-In: Ie364ab50f416e7821e70f4539a881eea828e1256
Change-Id: Ie364ab50f416e7821e70f4539a881eea828e1256
To make connectivity service mainline, this patch makes
MultipathPolicyTracker as a submodule of NetworkPolicyManagerService
to remove the dependencies of ConnectivityService.
Bug: 175015282
Test: FrameworksNetTests
Change-Id: I82a7c62069ffd0683deb2f5ce2f99de120a2a16f
Use two oneway binder interfaces instead.
The interfaces post messages to handlers as was implemented before, but
provide a more strictly defined interface, with less hops between
NetworkAgent, AsyncChannel, and ConnectivityService.
The actual public interface is the NetworkAgent @SystemApi: the binder
interface is an internal implementation detail.
Test: atest FrameworksNetTests CtsNetTestCasesLatestSdk
Change-Id: Ie364ab50f416e7821e70f4539a881eea828e1256
Allow ConnectivityServiceTest to change the UID by replacing
static calls to Binder.getCallingUid() with a method that can
be mocked.
Add registerNetworkCallbackAsUid as an initial way to exercise
this, and add some test coverage to the always-on lockdown test
to confirm that things are working as expected.
Bug: 173331190
Test: new unit tests
Change-Id: Ie0b32460e20e5906a0f479191e11a062f21cc608
This requires mocking lots of new things that weren't mocked
before but is otherwise fairly straightforward.
A few changes to MockVpn are needed as well:
1. Set the VPN's NetworkInfo to CONNECTED, so methods such as
isBlockingUid will work. While I'm at it, set the interface on
the LinkProperties as well to make things a bit more
realistic.
2. Constructs the VpnConfig when registering the agent, not when
the MockVpn is created. This is needed because starting and
stopping lockdown VPN calls prepare, which nulls out mConfig.
But constructing the VpnConfig when registering the agent is
more realistic anyway. The production code does that in
establish, but we can't do that in ConnectivityServiceTest
because some of the test cases don't call establish and call
registerAgent directly.
Bug: 173331190
Test: atest FrameworksNetTests
Change-Id: I827543751dbf5e626a24ec02cd6f50b423f5f761
CAPTIVE_PORTAL is a CS-managed capability, and causes CS to log a wtf.
When this test is run on an eng build, this sends SIGSEGV to the test,
which is pretty difficult to debug.
Test: FrameworksNetTests NetworkStackTests
Change-Id: I72fc46a6daa4e886425b4dc967318cca9f1a5302
