This introduces four generic thread that services can
use in the system process:
- Background: part of the framework for all processes, for
work that is purely background (no timing constraint).
- UI: for time-critical display of UI.
- Foreground: normal foreground work.
- IO: performing IO operations.
I went through and moved services into these threads in the
places I felt relatively comfortable about understanding what
they are doing. There are still a bunch more we need to look
at -- lots of networking stuff left, 3 or so different native
daemon connectors which I didn't know how much would block,
audio stuff, etc.
Also updated Watchdog to be aware of and check these new
threads, with a new API for other threads to also participate
in this checking.
Change-Id: Ie2f11061cebde5f018d7383b3a910fbbd11d5e11
Fixed one setting that was migrated but not marked deprecated.
Removed a hidden setting that is no longer used by the new
power manager service.
Bug: 7231172
Change-Id: I332f020f876a18d519a1a20598a172f1c98036f7
Because the NetworkInfo included in CONNECTIVITY_ACTION broadcast
extra does not reflect the state applicable to the calling UID, and
the last sticky broadcast may have stale state, transition to calling
ConnectivityManager.getActiveNetworkInfo() directly.
Change-Id: I86b316fbedd0273585ad5f1248b091bc3a3a5520
Uses NTP server and timeout from secure settings, or fallback to
defaults in resources. Update various system services to use cached
NTP time when fresh enough, or force updates as needed.
Bug: 4517273
Change-Id: Ie1c4c4883836013d02ca0bbd850cf8949f93b34b
Listen for connectivity changes. If WIFI is connected, check if
we have recently checked for NTP time. If we haven't yet checked the
time or it has been long enough (a day), then connect to the NTP server
and get the latest time. Update the time if it is significantly out of sync.
This doesn't poll the NTP server every time there is connectivity, only
if it hasn't been checked since boot or has been a day.
This fixes the problem that during SetupWizard, we try to contact the NTP
server before there is connectivity and fail. Now, as soon as the user
chooses a WiFi network to connect to, it will update the time before
getting to the Date/Time step. Then as soon as the user corrects the TZ,
the date/time should be correct.
Bug: 3491920
Change-Id: I62664156616510b67ecd6a1c24dd838b98d5204f
Do this on a periodic basis as well as when the AUTO_TIME setting changes to true.
If we recently acquired NITZ time from the telephony provider, then don't override
with NTP time.
