Currently, queryUserAccess talks to netd via FwmarkServer.
Doing this from the module would require exposing queryUserAccess
as an NDK API or reimplementing FwmarkClient.
Because queryUserAccess really only uses information that comes
from ConnectivityService/PermissionMonitor anyway, just use that
information without calling to net.
Test: atest HostsideVpnTests
Bug: 171540887
Merged-In: If855de1ea3e1fd2ed30f2795d9b4acfcf969a2dc
Change-Id: If855de1ea3e1fd2ed30f2795d9b4acfcf969a2dc
This is similar to onBlockedStatusChanged(Network, boolean) but
it allows the callback holder to know the exact reason why
networking was blocked. It is useful to privileged system
components such as JobScheduler that are able to ignore some
blocked reasons but not others.
Also add a new BLOCKED_REASON_LOCKDOWN_VPN that is used when
networking is blocked because an always-on VPN is in
lockdown mode.
Also move BLOCKED_METERED_REASON_MASK to ConnectivityManager.
This is necessary because ConnectivityService must ensure that
the blocked status callbacks are correctly sent when meteredness
changes (e.g., a UID that is blocked on metered networks will
become unblocked on a network that becomes unmetered). In order
to do this it needs to know which reasons apply only on metered
networks.
Bug: 165835257
Test: unit tests in subsequent CLs in the stack
Change-Id: I647db4f5a01280be220288e73ffa85c15bec9370
- Add @VisibleForTesting & @Nullable for Vpn#getNetwork().
- Remove null check in caller side(test) of Vpn#getNetwork()
because if the code is working properly, it can never be null.
Bug: 182963397
Test: atest FrameworksNetTests
Change-Id: Ic52864003fbebd9f4e95d43fefc2e168437b0122
Merged-In: Ic52864003fbebd9f4e95d43fefc2e168437b0122
(cherry-picked from ag/13946573)
Modify Vpn#getNetId() to Vpn#getNetwork() and uses NETID_UNSET
when getNetwork() returns null in ConnectivityServiceTest.
Bug: 182963397
Test: atest FrameworksNetTests
Change-Id: I69d449705b1dc541287c72af8dc7705dc4733109
Merged-In: I69d449705b1dc541287c72af8dc7705dc4733109
(cherry-picked from ag/13927650)
Register network callback for all networks and record
NetworkCapabilities for every networks. Once onDnsEvent is
triggered, use the netId it passes in to find the corresponding
NetworkCapabilities instead of using netId to create a Network
object(hidden API) then get the NetworkCapabilities by
ConnectivityManager#getNetworkCapabilities.
Bug: 182963397
Test: m
Test: atest IpConnectivityMetricsTest
Test: atest NetdEventListenerServiceTest
Change-Id: I91d68ca33253831b78def1ddeb074ba944a5d6ad
Merged-In: I91d68ca33253831b78def1ddeb074ba944a5d6ad
(cherry-picked from ag/13959432)
These constants will now be including all the reasons for why an
uid's network access can be blocked, instead of only the
restrictions that could be imposed by NPMS.
Bug: 183473548
Test: atest ./tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Merged-In: I4c544415e12adf442fd2415c371b1b70a39c3aa4
Change-Id: I6dcea43fbefa9eac8b5a971b822a5be5422a54b4
This is to be used by privileged components (e.g., JobScheduler)
to request callbacks about the state of other UIDs on the system.
Bug: 165835257
Test: new unit test coverage
Change-Id: I29f155710394e58c14fcef488db6271d8d83033a
When registerDefaultNetworkCallback is called by an app that has
NETWORK_SETTINGS, the UID of the app is forgotten and the request
that is filed has an empty UID set. This results in that request
matching networks that have UID ranges that do not include it,
e.g., VPNs.
Fix this by ensuring that the UID ranges are properly set.
Bug: 165835257
Test: updated specific tests for this bug
Change-Id: I90bf79573342c144d1cfbc2f61a3155fdd5b1fa7
Currently, if a process with NETWORK_SETTINGS registers a default
network callback, its uid will be ignored and replaced with an
empty list of UIDs. This means it will incorrectly match VPNs
with any UID range.
Add a test for this bug to make it easier to review the upcoming
change that fixes it.
Bug: 165835257
Test: test-only change
Change-Id: If58524b01fdd60045fb7236d17dedf31fb563f99
* changes:
TransportInfo: Add a generic redaction mechanism
Revert "Revert "Expose uids related APIs in NetworkRequest and N..."
Revert^2 "Replace the usage of UidRange"
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
Merged-In: Ic0d24d36af0b87153d527083f8964ddc6cd78482
ag/13210542 switched from using reset() on mResources to using
clearInvocations(). This ensures that only the previous calls are
reset, and that the mock continues to behave according to what
was specified in setUp.
Test: 183097033
Test: test-only change
Merged-In: I35d28c8df341dbbac2774026c6ca749e296c0482
Change-Id: Ieef982d2df50db3014f35f58a77674939ebe0d43
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
Merged-In: I77a3efca2cd644f9828db1ed5d3cae8070fb8363
This replaces the existing mechanism for redacting location sensitive
fields with a more extensible mechanism. Currently supported redactions
are for the following permissions:
i. ACCESS_FINE_LOCATION
ii. LOCAL_MAC_ADDRESS
iii. NETWORK_SETTINGS
Also, removed WifiInfo from ConnectivityServiceTest to reduce cross
dependencies on wifi code.
Bug: 156867433
Bug: 162602799
Test: atest android.net
Test: atest com.android.server
Change-Id: I2bb980c624667a55c1383f13ab71b9b97ed6eeab
These properties are necessary to figure out the maximum
score of a network.
Test: FrameworksNetTests
Change-Id: I48dce20ad4a80597039393dca607e8da829b2a61
1b5c01b06f
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: I0f679fb5fb8f4fe26461ca4912ca1fdfe7f43c9e
Merged-In: I4e5aec6ef1ea02e038fcd7ed117a3b67b69c5cb9
This reverts commit 133410313f.
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
This needed for OEMs that have VPN types not supported by AOSP.
Bug: 171872481
Test: new test coverage in VpnTransportInfoTest
Change-Id: Ic7529bef7f12d2c74a3be5b1a4a2d54fb0d0bfac
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
