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
Connectivity service is going to become a mainline module which
will not able to access hidden APIs. NetworkPolicyManagerInternal
is a internal serivce that CS can't be access after be a mainline
module. Thus, replace NPMI#isUidNetworkingBlocked() to similar
method NPMS#isUidNetworkingBlocked() and create new API
NPM#isUidNetworkingBlocked() to support CS usage.
Bug: 170598012
Test: atest FrameworksNetTests
Test: atest FrameworksCoreTests:NetworkPolicyManagerTest
Test: atest FrameworksServicesTests:NetworkPolicyManagerServiceTest
Test: atest CtsNetTestCases
Test: atest CtsHostsideNetworkTests
Change-Id: Ic3427c71c395de787320f303c9513874b4d64f98
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 reverts commit b36c519c4c.
Reason for revert: After discussion, we prefer to add a field in NetworkCapabilities instead. Sorry for inconvenience.
Change-Id: I2e8840a797df9d1594f2b8b576bcd45beb184fca
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
As part of modularization of ConnectivityService and expansion of the
Tethering module scope, move service-connectivity.jar into the tethering
APEX, and load it from there.
This rolls forward the change. The original topic was reverted because
of a bad merged-in clause; this is fixed and re-verified in this topic.
Bug: 171540887
Test: m, device boots and connectivity
Change-Id: I293b09c0dc04c6ccafa30cd0f1a63efe32283604
Revert submission 1532910-connectivity_jar_in_apex
Reason for revert: Breaks boot tests: b/176969905
Reverted Changes:
Ie41a5b569:Set setCurrentProxyScriptUrl as public
Id7b6a4664:Move service-connectivity to the tethering APEX
Ia7cb83834:Add service-connectivity to tethering APEX
Change-Id: I1c369dd8a6527513f8fc1a5cacde59d78d104c7e
Switch to using IDnsResolver#registerEventListener and
INetdEventListener directly.
Test: atest FrameworksNetTests
Test: atest CtsNetTestCases
Change-Id: I72a6b4457a2c22fdbe8c9b25ea92903db3f6fc91
This was the last place in CS that fetched underlying networks
from Vpn. Therefore, delete Vpn#getUnderlyingNetworks, which is
no longer used.
Bug: 173331190
Test: new tests in ConnectivityServiceTest added in previous CL
Change-Id: Iec22ff636de0c02193576fe2e2d36b8bc7380457
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
