* 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
Chalard Jeanauthored and Gerrit Code Reviewcommited 2021-03-17 05:48:18 +00:00
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
Also unify the listener for Oem settings, which have
never been released as public API (it is slated to be
released in S).
Test: FrameworksNetTests
Change-Id: I84ba363dd0ec03871c37b1c3a31e5557d9aa12e7
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
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
lucaslinauthored and Lucas Lincommited 2021-03-16 09:26:57 +00:00
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
- Expose PRIVATE_DNS_MODE_OFF, PRIVATE_DNS_MODE_OPPORTUNISTIC and
PRIVATE_DNS_MODE_PROVIDER_HOSTNAME for external users.
- Since PRIVATE_DNS_DEFAULT_MODE_FALLBACK might be changed from
release to release, so it cannot be exposed as a system API.
Remove PRIVATE_DNS_DEFAULT_MODE_FALLBACK and have a new API -
getPrivateDnsMode() for users to get the private DNS mode instead.
Bug: 172183305
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I02a1e91b4eafb5f5df3eada1c07b99849a050c3c
Merged-In: I02a1e91b4eafb5f5df3eada1c07b99849a050c3c
Existing NetworkCallback users will get NetworkCapabilities with
location sensitive data removed (except for ownerUid which will be
added for existing apps for backwards compatibility). Apps
have to opt-in to receive location sensitive data.
Note: This was chosen because WifiInfo is the only TransportInfo tha
has location sensitive info & that was added only in Android 12. If we
choose to default to true, all existings apps retrieving
NetworkCapabilities for wifi networks will be blamed for location access
unnecessarily.
Changes:
i) Add a flag in NetworkCallback creation to retrieve
NetworkCapabilities with location sensitive info in their callback.
(More flags are being planned for NetworkCallback for throttling
callback frequency, etc)
ii) For NetworkCapabilities.getOwnerUid(), we will continue to send the
data for apps targeting older SDK (since this is an existing field and
the new flag defaults location sensitive data to off).
Bug: 156867433
Test: atest android.net
Test: atest com.android.server
Change-Id: If70b5ea6f5c8885f0c353c8df08a826d55fe7f7a
- Add a new API to get the network ID range of IPSec tunnel
interface.
- Use the new API in IpSecServiceTest to make sure the result is
the same. Follow-up commit will change the logic in
IpSecService#reserveNetId(), the modified test can ensure the
correctness of the new change.
Bug: 172183305
Test: atest FrameworksNetTests:IpSecServiceTest
Change-Id: Ic605e48941fc9d6482cdcd01a8adcdc9b6d586a6
Preconditions.checkNotNull is deprecated to be replaced by
Objects.requireNonNull, and other methods can easily be replaced by
inline checks.
Preconditions is an internal API class that should not be used by
unbundled jars.
Bug: 177046265
Test: m
Change-Id: If14a75439ff332c927dc4114ae0eecb89f53c6c7
INVALID_RESOURCE_ID is a hidden API so its usage should be avoided.
The current usage is for an unused parameter, so just use a literal instead.
Bug: 182451544
Change-Id: I066d9c34f735434adee4ee72e8a7fe1ceb900c3c
Test: m
Currently, ConnectivityService has getAllNetworkState but it is
not ideal to expose as system API since the plan is to get rid
of NetworkState. Thus, create a new one that returns
NetworkStateSnapshot to fulfill the needs.
Note the original getAllNetworkState cannot be deleted now since
it has @UnsupportedAppUsage annotation.
Test: atest FrameworksNetTests
Bug: 174123988
Change-Id: Icddd434552b0e9ecbc8299e7242ec88cf3145aca
Connectivity is becoming a mainline module in S and
ConnectivityManager#enforceChangePermission is using
Settings#checkAndNoteChangeNetworkStateOperation for performing a
strict and comprehensive check of whether a calling package is
allowed to change the state of network. However, Mainline modules
are not allowed to use non-formal APIs, fortunately CS is the
only caller of this ConnectivityManager#enforceChangePermission.
Thus, implement the Settings API on ConnectivityService and remove
the ConnectivityManager#enforceChangePermission and
Settings#checkAndNoteChangeNetworkStateOperation.
Bug: 178565313
Test: atest FrameworksNetTests
Change-Id: I6f03398c1735b89470ad5bdbe3a036929daeb53c
Merged-In: I6f03398c1735b89470ad5bdbe3a036929daeb53c
paulhuauthored and Paul Hucommited 2021-02-23 08:35:38 +00:00
1. Stop using ConnectivityManager for VPNs in VpnDialogs.
2. Delete updateLockdownVpn, since all callers have been migrated
to calling VpnManager directly.
3. Delete the call to VpnManager in factoryReset, since the only
caller (ResetNetworkConfirm) has been updated to call into
VpnManager directly.
4. Delete getVpnManager, since it is now unused.
This reverts commit a3c05095ab.
Reason for revert: should be safe to submit now that aosp/1596096 is merged
Bug: 173331190
Test: treehugger
Change-Id: Ife3607c024006ce4fe46c981e9742170becb6331
Lorenzo Colitticommited 2021-02-22 05:07:22 +00:00
* changes:
[IT06]Move INetworkActivityListener into connectivity module
[IT05] Remove the unused network activity logic out from NMS
[IT4.7] Add network activity info into dumpsys for debugging
[IT4.6] Unbundle NMS out from ConnectivityManager
[IT4.5] Update radio power from CS directly
Chiachang Wangauthored and Gerrit Code Reviewcommited 2021-02-20 02:02:46 +00:00
1. Stop using ConnectivityManager for VPNs in VpnDialogs.
2. Delete updateLockdownVpn, since all callers have been migrated
to calling VpnManager directly.
3. Delete the call to VpnManager in factoryReset, since the only
caller (ResetNetworkConfirm) has been updated to call into
VpnManager directly.
4. Delete getVpnManager, since it is now unused.
Test: m
Bug: 173331190
Change-Id: I5d071281c0e36f6523fea10671a9abf994c66d66
Lorenzo Colitticommited 2021-02-19 17:34:30 +09:00
Add setHttpProxyConfiguration to the public API, and use
ConnectivityManager APIs from ActivityThread (instead of hidden APIs) to
get/set the proxy for an app process.
The default proxy is now initialized with getDefaultProxy instead of
getProxyForNetwork(null); this should not make a difference, as nothing
should have called bindProcessToNetwork at that point yet.
Bug: 174436414
Test: m; device boots
Merged-In: Ifb516194ecde1567cea4b6806946091cdcf2f015
Change-Id: I06b797eeae54609aecdc0afe1df4e6c602a17a69
INetworkActivityListener is hidden and the only usage is inside
the connectivity module. Thus, move this into module scope.
Bug: 170598012
Test: atest FrameworksNetTests
Change-Id: I0a75c440c1daa773217bbd362b212fda4d07ec64
ConnectivityService is no longer to update idle timer to NMS but
send to INetd directly after this change. Replace the API
implementation in ConnectivityManager to refer into
ConnectivityService instead of NetworkManagementService to remove
the dependency between CM and NMS for ConnectivityService mainline.
Bug: 170598012
Test: atest FrameworksNetTests
Change-Id: If0ac9a6427dba5a732a15b5d7ca1351b71b07b7b
lucaslinauthored and Chiachang Wangcommited 2021-02-18 11:48:06 +08:00
Tethering API stubs depend on connectivity stubs for classes like
MacAddress or LinkAddress, so connectivity stubs cannot depend on
Tethering stubs or there would be a circular dependency.
This means ConnectivityManager API surface cannot reference Tethering
API constants. Instead, use the literal in ConnectivityManager.
This means that both ConnectivityManager and TetheringManager specify
the constant value. An alternative considered was to have
TetheringManager depend on the ConnectivityManager constants, but
considering that ConnectivityManager only has some of the constants,
this would be more confusing. Breaking the constants by mistake is
unlikely as their values are part of the API surface, so will always be
in sync.
Bug: 171540887
Test: m
Change-Id: I16b6e1912fffc5ff8b3b392901d2357ffd213c72
* changes:
Check registering system default callback needs NETWORK_SETTINGS.
Move VPN code from ConnectivityService to VpnManagerService.
Add a skeleton VpnManagerService, and start it on boot.
Convert LockdownVpnTracker to NetworkCallbacks.
Minor fixes to VpnTransportInfo.
Lorenzo Colittiauthored and Gerrit Code Reviewcommited 2021-02-15 00:00:47 +00:00
Main implementation of ConnectivityService.setOemNetworkPreference. This
covers the main requirements of this method including listener
functionality.
Bug: 176495594
Bug: 177101287
Bug: 176494815
Test: atest FrameworksNetTests
atest NetworkStackTests
atest FrameworksNetIntegrationTests
atest NetworkStackIntegrationTests
atest CtsNetTestCasesLatestSdk
Change-Id: I8d318ab07785e52dd84d6261fdea8f318dce9bc5
ConnectivityService itself does not depend on mVpns or the Vpn
class any more. Most of this CL is simply moving code from one
class to another:
- Move the AIDL calls from IConnectivityManager to IVpnManager.
- Move the implementation from ConnectivityService to
the new VpnManagerService.
- Move the APIs from ConnectivityManager to VpnManager, but
temporarily maintain some shims in ConnectivityManager for the
moved calls so that existing callers do not have to be modified
in this CL.
- Update VpnService to call IVpnManager instead of
IConnectivityManager.
- Move the code that registers the VpnManager service from
ConnectivityFrameworkInitializer to SystemServiceRegistry.
Bug: 173331190
Test: atest HostsideVpnTests FrameworksNetTests CtsNetTestCases
Change-Id: I4911e2144df721a94fa00da9edf0dc372a7091c2
Lorenzo Colitticommited 2021-02-12 01:12:24 +09:00
This will allow moving LockdownVpnTracker from the connectivity
to the VPN code. This requires moderate refactoring since it's
pretty tightly coupled to both.
In this CL:
1. Add an @hide API to tell ConnectivityService that legacy
lockdown VPN is enabled. I chose not to use the existing
setVpnRequiredForUids API because that method has specific
semantics and because it will be required long term since
it's used by non-legacy VPN types.
2. Instead of updating LockdownVpnTracker inline from the
ConnectivityService handler thread, have it listen to
NetworkCallbacks. This introduces an extra thread hop, but
most of the interactions between the lockdown VPN and CS were
via NetworkAgent, which is asynchronous anyway.
3. Add code to LegacyTypeTracker to send the extra
CONNECTIVITY_ACTION broadcast for the underlying network type
that is sent after the VPN connects. In order to do this, make
Make LockdownVpnTracker specify its underlying network
(via setUnderlyingNetworks) when it connects.
4. Reimplement LockdownVpnTracker#augmentNetworkInfo based on
information that is available in ConnectivityService.
5. Remove the code in LockdownVpnTracker that counted errors.
I think this code has not worked since lollipop, because
ConnectivityService never sees NetworkInfo objects in state
FAILED. This is because ConnectivityService only hears about
NetworkInfo objects via NetworkAgents, and LegacyVpnRunner
only registers its NetworkAgent when the connection succeeds.
Bug: 173331190
Test: passes existing tests in ConnectivityServiceTest
Change-Id: I66d18512882efd468ee0ecec61f28786a195b357
Lorenzo Colitticommited 2021-02-12 01:07:29 +09:00
This method allows internal components to track the system
default network. This differs from registerDefaultNetworkCallback
because that method sends callbacks for the default network for
the UID that called it. This may not be the system default
network, for example, when a VPN is up and applies to the UID.
Bug: 173331190
Test: new unit tests in ConnectivityServiceTest
Test: new unit tests in ConnectivityManagerTest
Test: new CTS tests in ConnectivityServiceTest
Test: new CTS tests in HostsideVpnTests in other CL in this topic
Change-Id: Id02748a2183f71b71ff2a53a580466b9dcecaa93
Lorenzo Colitticommited 2021-02-09 20:58:28 +09:00
Not currently setting the atttribution tag for location
permission checks. Plumb the attribution tag for all location permision
checks (so that location access is correctly attributed to individual
components within an app)
Bug: 162602799
Test: atest android.net
Test: atest com.android.server
Change-Id: Iee95f05204f51a4f8cb1f36acfb60e8cdeb156f4
Nothing on the system is using registerNetworkFactory,
unregisterNetworkFactory at the moment.
registerNetworkFactory, unregisterNetworkFactory are protected by
signature permissions, so could not be used by anything outside of the
system.
Remove the two methods and the underlying support for this legacy,
deprecated mechanism.
Bug: 179229316
Test: atest FrameworksNetTests
Change-Id: I7cdc9eed67f846c8774474af038133040aeccab3
Lucas Lin
authored and
Gerrit Code Review
commited 
Chalard Jean
authored and
junyulai
commited 
Remi NGUYEN VAN
authored and
Treehugger Robot
authored and
Roshan Pius
authored and
paulhu
authored and
Lorenzo Colitti
commited 
Chiachang Wang
authored and
Nataniel Borges
commited 
James Mattis
commited