Modify Vpn#getNetId() to Vpn#getNetwork() and uses NETID_UNSET
when getNetwork() returns null in ConnectivityServiceTest.
Bug: 182963397
Test: atest FrameworksNetTests
Change-Id: I69d449705b1dc541287c72af8dc7705dc4733109
Also make getTransportName non-static so it can access the module
resources.
Also fix a duplicate comment in a resource file.
Bug: 183097033
Test: atest FrameworksNetTests
Test: connected to Wi-Fi with no Internet, observed notification
Change-Id: Ic0d24d36af0b87153d527083f8964ddc6cd78482
These properties are necessary to figure out the maximum
score of a network.
Test: FrameworksNetTests
Change-Id: I48dce20ad4a80597039393dca607e8da829b2a61
UidRange is used in a shared way between ConnectivityService
and VPN through the use of NetworkCapabilities. UidRange will
be part of the ConnectivityService mainline but Vpn.java will
stay in the framework. We need a way to replace the APIs using
UidRange, or to make UidRange system API. The only really
relevant surface here is NetworkCapabilities#{setUids, getUids}.
The need for UidRange could be replaced by an integer Range, so
replace the usage of UidRange by a integer Range in
NetworkCapabilities#{setUids, getUids} and update the relevant
callers.
Bug: 172183305
Test: atest FrameworksNetTests CtsNetTestCasesLatestSdk
Change-Id: I4e5aec6ef1ea02e038fcd7ed117a3b67b69c5cb9
This reverts commit d88174dafd.
Reason for revert: The issue causing the build breakage has been fixed
Change-Id: I03fa406551b51aaa4d4d9255cf1a53f9b4bcc1bd
Merged-In: Ib9949b8619c6b148f73630b314c4113d76c31ec1
Revert "Add shims for NetworkRequest"
Revert submission 1626206-replaceUidRange
Reason for revert: Breaking build - b/183106405
Reverted Changes:
I0b79c73e8:Add shims for NetworkRequest
I4bc0daf5a:Replace the usage of UidRange
I4e5aec6ef:Replace the usage of UidRange
I107c329d4:Expose uids related APIs in NetworkRequest and Net...
Change-Id: I6290429db1c8e787f8138b55b98fd92a74ac6402
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
Use ServiceConnectivityResources instead.
Start by creating resources in the ServiceConnectivityResources package
to match the internal configuration, and common overlays.
Bug: 182125649
Test: device boots, has connectivity
Change-Id: I77a3efca2cd644f9828db1ed5d3cae8070fb8363
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
Add more connectivity module settings and update all references
to ConnectivitySettingsManager.
Bug: 182538166
Test: atest FrameworksNetTests
Change-Id: Ie96fbd0996ed3acb37099b6270bf3d4c2e558e9a
UidRange is used in a shared way between ConnectivityService
and VPN through the use of NetworkCapabilities. UidRange will
be part of the ConnectivityService mainline but Vpn.java will
stay in the framework. We need a way to replace the APIs using
UidRange, or to make UidRange system API. The only really
relevant surface here is NetworkCapabilities#{setUids, getUids}.
The need for UidRange could be replaced by an integer Range, so
replace the usage of UidRange by a integer Range in
NetworkCapabilities#{setUids, getUids} and update the relevant
callers.
Bug: 172183305
Test: atest FrameworksNetTests CtsNetTestCasesLatestSdk
Change-Id: I4e5aec6ef1ea02e038fcd7ed117a3b67b69c5cb9
TCP_DEFAULT_INIT_RWND setting has never been set before, CS
always read the tcp receive window size from
net.tcp.default_init_rwnd then set to net.tcp_def_init_rwnd.
Thus, remove the unnecessary setting from CS, and the property
doesn't need to set either. Because aosp/1639922 migrate the
properties, the default value has been set to kernel already.
Bug: 182538166
Test: atest FrameworksNetTests
Change-Id: I13e175ab4dea72446af7df4a25e307e5934fa813
* changes:
Remove per-user preference when the user is removed
Expose the enterprise per-profile networking API.
Implement setNetworkPreferenceForUser.
Public API for per-profile network preference.
Add tests for setNetworkPreferenceForUser
This is done by:
1. In requestNetwork, provide a basic permission check.
2. rematchNetworksAndRequests: no change, since non listen
requests will be automatically processed to track
best satisfying network.
3. applyNetworkReassignment: no change, since non-request
will not be sent to factories.
Test: atest ConnectivityServiceTest#testRegisterBestMatchingNetworkCallback_noIssueToFactory
Test: atest ConnectivityServiceTest#testRegisterBestMatchingNetworkCallback_trackBestNetwork
Bug: 175662146
Change-Id: I8cf4ab334df6812d84cdda160e9b72b6f54062af
Context is more useful than ContentResolver, it can provide more
information if we want to change the behavior in the future.
Bug: 172183305
Test: atest FrameworksNetTests
Change-Id: I5702c7d74b862a76558b94f1abe2c6df9eb7f097
Merged-In: I5702c7d74b862a76558b94f1abe2c6df9eb7f097
Context is more useful than ContentResolver, it can provide more
information if we want to change the behavior in the future.
Bug: 172183305
Test: atest FrameworksNetTests
Change-Id: I5702c7d74b862a76558b94f1abe2c6df9eb7f097
networkAttributes is a legacy configuration that is now only used to
configure which legacy type networks are supported, and what the restore
timer is for that network type, for the deprecated
startUsingNetworkFeature API.
Use a dedicated resource for the restore timers, and build supported
legacy network types using hasSystemFeature for wifi, wifi p2p,
bluetooth, proxy types, and TelephonyManager.isDataCapable for the
mobile types.
Bug: 146206136
Test: atest FrameworksNetTests
Change-Id: I3a771d3de6c5e912f18d2834e3a50af797ac4991
