NetworkScore, IOnCompleteListener should be in the Connectivity scope,
as they are supporting classes for the ConnectivityManager APIs.
Bug: 181512874
Test: m
Change-Id: I6dc40a80e0bf5f86f5625b657b01eba969d41fcf
Given that ConnectivityService is moving to a mainline module, we need
a @SystemApi for it to listen for changes in blocked status of an uid.
So, we decided to create a new API for this which can provide
ConnectivityService with more info about why an uid is blocked (which
will be useful for adding a new similar onBlockedStatusChanged callback
in CM.NetworkCallback) and also captures data saver restriction without
having out to track it separately.
Currently, NPMS does some redundant computations because we are
calculating both uid rules and blocked reasons separately. In a
follow-up change, we will compute uid rules using blocked reasons
and later possibly remove that onUidRulesChanged callback.
Bug: 176289731
Test: atest ./tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Test: atest ./tests/net/java/com/android/server/ConnectivityServiceTest.java
Test: atest ./services/tests/servicestests/src/com/android/server/net/NetworkPolicyManagerServiceTest.java
Change-Id: Ib9949b8619c6b148f73630b314c4113d76c31ec1
Merged-In: Ib9949b8619c6b148f73630b314c4113d76c31ec1
These methods are used by ConnectivityService for synchronous
calls such as getActiveNetworkInfo, isActiveNetworkMetered, etc.
These calls must call into NPMS and acquire the NPMS lock because
they are synchronous. They cannot use the stale copy of the
policy rules maintained by ConnectivityService, because if they
did, races like the following could occur:
1. App gets broadcast/callback/....
2. App calls isActiveNetworkMetered or other synchronous method.
3. ConnectivityService's copy of the rules is out of date, so the
call returns stale information that the UID is still blocked.
4. The app thinks it has no networking, and does not call the
synchronous method again until some other event occurs,
potentially much later.
Bug: 176289731
Test: passes existing tests in ConnectivityServiceTest
Change-Id: I4ad0ca60431fe3702be85332530b6e93728d55e7
Add APIs for getMultipathPreference and getRestrictBackgroundStatus.
Both are used by Connectivity to back the external
ConnectivityManager.getRestrictBackgroundStatus, and
ConnectivityManager.getMultipathPreference APIs.
Test: atest CtsNetTestCases
atest ConnectivityServiceTests
atest NetworkPolicyManagerServiceTest
Bug: 176289731
Change-Id: I8a03162b2f6691086bb64e75ffd354cdfca7f86a
This needed for OEMs that have VPN types not supported by AOSP.
Bug: 171872481
Test: new test coverage in VpnTransportInfoTest
Change-Id: Ic7529bef7f12d2c74a3be5b1a4a2d54fb0d0bfac
Given that ConnectivityService is moving to a mainline module, we need
a @SystemApi for it to listen for changes in blocked status of an uid.
So, we decided to create a new API for this which can provide
ConnectivityService with more info about why an uid is blocked (which
will be useful for adding a new similar onBlockedStatusChanged callback
in CM.NetworkCallback) and also captures data saver restriction without
having out to track it separately.
Currently, NPMS does some redundant computations because we are
calculating both uid rules and blocked reasons separately. In a
follow-up change, we will compute uid rules using blocked reasons
and later possibly remove that onUidRulesChanged callback.
Bug: 176289731
Test: atest ./tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Test: atest ./tests/net/java/com/android/server/ConnectivityServiceTest.java
Test: atest ./services/tests/servicestests/src/com/android/server/net/NetworkPolicyManagerServiceTest.java
Change-Id: Ib9949b8619c6b148f73630b314c4113d76c31ec1
VCN underlying network capabilities should be transport-dependent in
order to allow using anything other than the INTERNET capability for
VCN types that support wifi offload. Specifically, if underlying
network capabilities are not transport-dependent, and Wifi only ever
supports the INTERNET capability, the VCN is unable to utilize wifi
offload together with requiring NET_CAPABILITY_IMS or
NET_CAPABILITY_CBS, since the IMS or CBS capability would be required
for both cellular and wifi underlying networks.
Until such time as a per-transport capability set is allowed, hide
the exposedCapability pieces, and document that all underlying networks
MUST have INTERNET capability in order to be used.
Bug: 182219992
Test: atest FrameworksVcnTests
Test: atest CtsVcnTestCases
Change-Id: I50d7f1be42e0e001f1413a3d5fe8aa4b7afec223
This patch defines the API, but does not make it public
yet as there is no implementation yet.
Test: none so far
Change-Id: I854a952dfe35cc80847eb62f522b1667b8e9b8a0
As attested by numerous TODOs in the code, a new way of
representing network quality and policy is needed instead
of an int.
An int representing the quality of the network requires
all parties using it to know how all other parties are
using it, and implementation details about the decision
algorithm. For all intents and purposes, the selection
is left to individual network factories who try to
achieve a desired result while piecing together all
possible states of the system.
As the number of such cases and desires increases, this
becomes both intractable and unmaintainable. Indeed, at
this time in the codebase nobody can really predict exactly
how a given change in score will affect selection across
the board, and it is essentially impossible to figure out
the behavior of network selection by inspecting the code
because the moving parts are scattered throughout the
entire codebase.
Having an object encapsulating policy and quality values
will let us centralize the selection and make it again
possible to maintain without knowledge of all behaviors
of all network factories. It will also provide better
guarantees of respecting policy, and allow bugfixes that
were not possible before because they'd touch too many
parts of the code.
Test: FrameworksNetTests FrameworksWifiTests NetworkStackTests
Change-Id: I3185a6412b9b659798faf0c6882699e9c63cc115
PacProxyInstaller class is running a thread all the time and is
listening to intent ACTION_PAC_REFRESH so it would be better to
make it be a system service with a manager class PacProxyManager
which is obtained with getSystemService(PacProxyManager.class).
Besides, rename PacProxyInstaller to PacProxyService will
be easier to know it's the service for PacProxyManager.
ConnectivityService is going to be a mainline module and it
needs constructor of PacProxyService to be SystemApi.
However, in current design, it needs to pass a handler and
an int arguments to the constructor which would be difficult
to maintain if just expose the constructor directly.
So, define a listener for the event that the current PAC
proxy has been installed so that the handler and the int
arguments can be removed from the constructor.
Bug: 177035719
Test: FrameworksNetTests
Change-Id: I2abff75ec59a17628ef006aad348c53fadbed076
This CL changes the policy listener API to be
VcnNetworkPolicyChangeListener (it was previously
VcnNetworkPolicyListener) per API Council guidance.
This CL also requires permission NETWORK_FACTORY for removing registered
policy listeners.
Bug: 181562364
Test: atest FrameworksVcnTests
Change-Id: I026eaefa62d8f64b9180fc182a7cf0605d83bf97
Merged-In: I026eaefa62d8f64b9180fc182a7cf0605d83bf97
(cherry picked from commit a96ec13821)
Rename StringNetworkSpecifier to EthernetNetworkSpecifier (its only
production user), and make it module-lib API.
The original StringNetworkSpecifier file is actually kept to satisfy
some invalid dependencies; it will be removed separately.
This allows specifying an Ethernet interface with a non-deprecated API:
until this change the only way to do so would be to use
NetworkRequest#setSpecifier(String), which is deprecated.
Similarly, add the TestNetworkSpecifier API for TestNetworkManager, to
replace previous usage of StringNetworkSpecifier. TestNetworkManager is
module API, so TestNetworkSpecifier should be module API too. This
allows tests to request the test interface specifically, without using
the deprecated NetworkRequest#setSpecifier(String).
Bug: 179329291
Test: m
Merged-In: Iee569f5c8bbdc4bc979610e1191308281f3d4620
Change-Id: Iee569f5c8bbdc4bc979610e1191308281f3d4620
ParseException is a public API class used to support Connectivity APIs,
so it should be in the same API surface as connectivity.
Bug: 181512874
Test: m
Change-Id: Ie1213de0d0facc8f409f7b4c2553abb382e4afbf
* changes:
Support converting VcnControlPlaneIkeConfig to/from PersistableBundle
Support converting IKE Options to/from PersistableBundle
Support converting IkeConfigRequest to/from PersistableBundle
Support converting IkeAuthEapConfig to/from PersistableBundle
Support converting IkeAuthDigitalSignConfig to/from PersistableBundle
Support converting IkeAuthConfig to/from PersistableBundle
Support converting IkeSessionParams to/from PersistableBundle
This CL changes the policy listener API to be
VcnNetworkPolicyChangeListener (it was previously
VcnNetworkPolicyListener) per API Council guidance.
This CL also requires permission NETWORK_FACTORY for removing registered
policy listeners.
Bug: 181562364
Test: atest FrameworksVcnTests
Change-Id: I026eaefa62d8f64b9180fc182a7cf0605d83bf97
Rename StringNetworkSpecifier to EthernetNetworkSpecifier (its only
production user), and make it module-lib API.
The original StringNetworkSpecifier file is actually kept to satisfy
some invalid dependencies; it will be removed separately.
This allows specifying an Ethernet interface with a non-deprecated API:
until this change the only way to do so would be to use
NetworkRequest#setSpecifier(String), which is deprecated.
Similarly, add the TestNetworkSpecifier API for TestNetworkManager, to
replace previous usage of StringNetworkSpecifier. TestNetworkManager is
module API, so TestNetworkSpecifier should be module API too. This
allows tests to request the test interface specifically, without using
the deprecated NetworkRequest#setSpecifier(String).
Bug: 179329291
Test: m
Change-Id: Iee569f5c8bbdc4bc979610e1191308281f3d4620
The data class supports a ConnectivityManager API, so it should be
together with the ConnectivityManager API surface.
Bug: 181512874
Test: m
Change-Id: I5642486ea0febcb08cadcbd4cd3f0c6056deae0e
