This change does not neglect NITZ. NITZ will be used if network
is not available for long enough so that previous NTP
suggestion becomes stale.
Before this change, if an NITZ time signal was available, it would be
given priority over an NTP-derived time.
After this change, if an NTP time signal is available, it will be given
priority over an NITZ-derived time.
This change modifies the default configuration of the system time
detector. It can be modified by partners altering the configuration
directly or by use of a build-time config overlay. The configuration can
not be influenced by users currently.
This change is being made because we have had reports over the years of
NITZ information being incorrect or inaccurate. Responsibility for
sending correct NITZ time lies with carriers and can even vary from cell
to cell on the same network. We assume NTP will be more consistent and
reliable, so we are modifying the default.
Testing plan: use `adb shell dumpsys time_detector` to see suggestions
history and what suggestion is currently being used.
One way to disable NTP suggestions is to turn off WiFi and cell data plan.
Other way is to remove "network" from config_autoTimeSourcesPriority
list in frameworks/base/core/res/res/values/config.xml.
Bug: 172230856
Test: presubmit only
Change-Id: I63e0b865eb454e6c368af846e6bcb3e1924a9d0f
* changes:
[FUI07] Stop making NetworkState with NetworkInfo from external callers
[FUI06] Stop using NetworkInfo in NetworkState from external callers
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
Follow-up from previous patch. This change stop accessing the
constructor that needs NetworkInfo to create NetworkState, which
is no longer accessible after ConnectivityService become
mainline module. Instead, pass a legacy network type which is
dedicated for the need of the type.
Test: atest FrameworksNetTests NetworkPolicyManagerServiceTest
Bug: 174123988
Change-Id: I24157bc33e5a5819eccd6a3111d2049f531c1d43
This is achieved by:
1. Use legacy network type inside NetworkState to replace the
needs of referencing NetworkInfo.getType().
2. Let getAllNetworkState only return networks with isConnected()
equals true. This allows callers such as NPMS or NSS does not
have to reference to NetworkInfo.isConnected().
Test: atest FrameworksNetTests NetworkPolicyManagerServiceTest
Bug: 174123988
Change-Id: I1c4eb08d18ca973eb8f41d06258872eabc0006b8
Remove com.android.server.BootReceiver$2 from the denylist as this
anonymous class was retired in change https://r.android.com/1565971.
(cherry picked from commit 1653aba6bf)
Bug: 159164105
Bug: 179645293
Test: atest PreloadCheck
Change-Id: I94122241dc4cef84524ca83513a68d1fa8ffbe65
Merged-In: I94122241dc4cef84524ca83513a68d1fa8ffbe65
* changes:
Change ConnectivityServiceTest to prepare for VPN code move.
Add to VpnManager the VPN APIs used by Settings and SystemUI.
Remove temporary hack in VpnTest.
The VPN code is moving out of ConnectivityService to a new
VpnManagerService. Update VpnDialogs to call into the new
service.
Bug: 173331190
Test: builds, boots
Test: atest HostsideVpnTests
Change-Id: I173ed0c3e39afb91c0dde1426dc492e9225afb00
The static validate() method an PROXY_* constants in Proxy are
used by both module and Settings. After Proxy is moving into
connectivity module, Setting will not able to access them.
Thus, move them to ProxyUtils in net shared lib.
Bug: 172183305
Test: atest FrameworksNetTests
Test: atest CtsNetTestCases:ProxyInfoTest
Change-Id: I02c88aeaeb53d62b87a42a2d8ead9b140b054650
No-op changes to make it easier to review the VPN code move.
1. Set underlying networks via MockVpn, not ConnectivityService.
2. Add a processBroadcastForVpn utility method that we can modify
without too much churn when the code is moved.
Bug: 173331190
Test: test-only change
Change-Id: I4256ca5f33034ef9d1de79857795a6ed1d644e61
Settings and SystemUI use these through raw AIDL calls.
Make them proper manager calls so we can move the implementation
without touching the callers again.
For now these still call into ConnectivityService via
IConnectivityManager. In an upcoming CL the implementation will
move to VpnManagerService.
Test: m
Bug: 173331190
Change-Id: I91528e1ad9948fbaa1fc5e37c61c5eb95f54964e
This temporary hack was necessary due to b/175883995. Now that
that bug is fixed, remove the hack.
Bug: 171529940
Test: test-only change
Change-Id: I48bd594cf3a37575f4888c1be9a1cf535de2e4d2
Currently, NetworkRequest has several types of requests (LISTEN,
TRACK_DEFAULT, REQUEST, BACKGROUND_REQUEST), and we expect more
to be added.
There are really three categories of request:
1. Requests satisfied by only one network and will keep that
network up, and thus need to be sent to NetworkProviders:
REQUEST, BACKGROUND_REQUEST.
2. Requests satisfied by only one network but will not keep that
network up: TRACK_DEFAULT
3. Requests satisfied by multiple networks and will not keep any
networks up: LISTEN.
Unfortunately the separation is not very clear. Currently, for
any valid request, either isListen() will return true or
isRequest() will return true. This makes it impossible to tell
whether a particular request should be sent to NetworkProviders,
so the current code sends TRACK_DEFAULT requests to
NetworkProviders as well. This is incorrect - a TRACK_DEFAULT
should never keep a network up, for example.
This CL attempts to clarify things by making isRequest() return
false for TRACK_DEFAULT requests and thus never sending them to
NetworkProviders. After this CL:
- isRequest will return true only for requests that attempt to
bring up or keep up a network.
- isListen will return true only for requests that match multiple
networks but do not keep any of them up.
- Neither will return true for TRACK_DEFAULT.
Test: atest ConnectivityServiceTest
Change-Id: I7aad30ade8f7ab2a179e53483d9afd8675f64a12
This is mainly used by VCN, where VCN-eligible networks might
be registered before VCN management service can fire request
to prevent the newly created network from being torndown
immediately by ConnectivityService.
Test: atest ConnectivityServiceTest#testNewNetworkLingering
atest ConnectivityServiceTest#testNewNetworkLingering_bgNetwork
atest FrameworksNetTests --rerun-until-failure 20
Bug: 175180558
Change-Id: I7768daf4cf2d8f6d8057b5107412e06104ba82e0
This change adds support for retries with incrementally increasing
delays.
Bug: 165827287
Test: atest FrameworksVcnTests
Change-Id: I414dce5882540bbe338d0bc1f40481df424821fe
Add additional tests based on proxy implementations of
ChildSessionCallback and ChildSessionConfiguration
Bug: 165827287
Test: atest FrameworksVcnTests
Change-Id: I165716a0212da7c06b9723656ffe35921cf81854
