Add a new NetworkTimeHelper impl and changes to support it in the
time detector service code.
Background:
When the location code that became NtpNetworkTimeHelper was first
written, Android devices were not guaranteed to be requesting the time
regularly from network time sources: it was only done if the user had
enabled automatic time detection.
That changed a few releases ago, and so the location code should always
be able to ask the time detector for the latest network time signal.
This is part of a wider goal to remove several dependencies in the
Android platform on low-level NTP client code (NtpTrustedTime class).
The NTP protocol usage should be an implementation detail, not something
that is widely known to unrelated classes that want an accurate time.
With the new impl, the SDK SystemClock.currentNetworkTimeClock() call
will ask the time detector service for the latest network time too, and
not interact with the NTP client singleton directly as it does today. It
currently needs to use the NTP client because both the location code and
time detector use the NtpTrustedTime singleton independently and it is
therefore the closest thing on Android today to an authority of "what is
the latest network time the device has obtained?".
Once the time detector is the authority on "latest network time", it
will allow the platform to apply stringent checks to things like time
sync accuracy, which is currently not well checked and heavily dependent
on network round-trip time and network delay symmmetry.
This refactoring is also potentially important for form factors like
Wear, which disable NetworkTimeUpdateService and therefore won't trigger
NtpTrustedTime while attempting to sync. There's a good chance the
location time sync is also broken on Wear (if present) because of the
unusual networking constraints. The API
SystemClock.currentNetworkTimeClock(), which was added to the public SDK
in Android T, may be unreliable or broken on Wear. In future, Wear could
call suggestNetworkTime() on the time detector service from its own
equivalent of NetworkTimeUpdateService and restore
SystemClock.currentNetworkTimeClock() behavior, while also supporting
the location stack's needs (if that is also used on Wear).
Centralizing network sync under NetworkTimeUpdateService will mean that
fewer components on devices will be syncing time for their own ends,
potentially reducing load on time servers too.
This centralization also supports options for changing how "network
time" is obtained in future, e.g. allowing easier integration of newer
protocols like NTS or Roughtime, or partner plug-ins to support
proprietary protocols.
New implementation details:
The TimeZoneDetectorNetworkTimeHelper implementation retrieves the
latest network time suggestion from the TimeDetectorInternal API. It
attempts to pass time to the GNSS code as often as the original
implementation, even when a new time signal isn't available and its
potentially repeating itself, in case GNSS code has become reliant on
that. Generally, it's hard to tell what the contract should be,
particularly with the unusual behavior around "on demand" Vs "periodic"
and the historic bug there.
The new implementation should become the default when it is considered
safe to do so, i.e. after testing when we are confident that
NetworkTimeUpdateService is behaving as well as the old
NtpNetworkTimeHelper impl when detecting connectivity, etc. This can be
done with a single boolean compile-time flag.
Other changes:
The time detector is now a dependency of the location stack, so the
SystemServer service bootstrap ordering has been adjusted.
Bug: 222295093
Test: atest services/robotests/src/com/android/server/location/gnss/TimeDetectorNetworkTimeHelperTest.java
Test: atest services/tests/servicestests/src/com/android/server/timedetector/TimeDetectorStrategyImplTest.java
Test: atest services/tests/servicestests/src/com/android/server/timezonedetector/TimeZoneDetectorStrategyImplTest.java
Change-Id: I2f9a14776e9fafe426213df7cb0307a3fe541fad
Also Cp'ing changes in ag/19338309 together.
Test: tested locally, service starting as expected.
Bug: 267404564
Change-Id: Idf26fd9408290263f791b8eb23689368064459db
Previously, on first boot, an HSUM device would unlock the system user,
then create the MainUser (if needed), and then switch to the boot user,
all at around the same time.
This cl reorders these events and spreads them out:
* first, early on (just prior to PHASE_SYSTEM_SERVICES_READY), the
MainUser is created (if needed)
* later (after PHASE_THIRD_PARTY_APPS_CAN_START), the system user is
unlocked
* then we promptly switch to the boot user. This needs to be after
PHASE_THIRD_PARTY_APPS_CAN_START since special apps may designate a
different boot user.
This will ensure that the MainUser can be retrieved much earlier on by
system services whose operations may depend on it.
Also, the structure of BootUserInitializer is renamed to better reflect
its role, and its structure is modified slightly to allow SystemServer
to use it more easily.
Bug: 262438904
Bug: 266098768
Test: flashed HSUM and confirmed that MainUser was created as needed
Test: atest FrameworksMockingServicesTests:com.android.server.pm.UserManagerServiceTest
Change-Id: Ic84b1be538234b2bfde3ae792c9a923ace55f24c
- Move ArtManagerLocal initialization before the boot compilation step
(UpdatePackagesIfNeeded).
- Delay scheduling the background dexopt job because the job scheduler
hasn't been started at that point.
Test: Boot with dalvik.vm.useartservice=true and check logcat that ART
Service starts up and a first-boot dexopt runs without errors.
Bug: 266028904
Change-Id: I108b877f2a99c69c20f7209339cd193c2d41e7ea
Changed system server initialization order: ArtManagerLocal needs to be
initialized before mPackageManagerService.systemReady() is called,
because that calls CarrierAppUtils.disableCarrierAppsUntilPrivileged,
which may call ApplicationPackageManager.setSystemAppState to set
SYSTEM_APP_STATE_UNINSTALLED, which ends up calling ArtManagerLocal to
clean up any app profiles.
Test: Boot with dalvik.vm.useartservice=true and verify that calls to
clearAppProfilesLIF and destroyAppProfilesLeafLIF during boot
are handled by ART Service.
Bug: 251903639
Change-Id: I8a3a16ce85f315a28fa8459325470cfe5f32ca8c
This variable is intended to be used as part of the startOtherServices
method of the system server much like `isWatch` is used now in order
to selectively skip starting system services, which are not relevant to
the operation of Android TV.
Test: make
Bug: 264411203
Change-Id: Ife21ac60e11d6669954dc0f77b2c85d0149d2d7b
Add the callback when the ART Manager is initialized, and move the
CompilerStats code into it.
This moves the ART Manager initialization code from SystemServer to
DexOptHelper to keep it more contained, and it also fixes a small bug
where an ArtManagerLocal instance was created and registered even when
ART Service shouldn't be in use.
Also remove TODO for controlDexOptBlocking handling when ART Service is
in use. It got marked with LegacyDexoptDisabledException, so it's moot
to support in that mode.
Test: Boot
Bug: 251903639
Bug: 260072740
Change-Id: Id0995ef9f24ee007207ee0d1f7d2108fa81b15aa
Currently, the call to rebootOrShutdown is synchronized on the
Runnable.this instance, and thus there is no way for any other thread
to contend on the same lock.
Change-Id: Idaacda47031431435598dfd45840b1344c5938e6
Test: manually
See details in the bug.
Before:
D SystemServerTiming: DexUseManagerLocal
I system_server: Waiting for a blocking GC ClassLinker
I system_server: Background concurrent copying GC freed 207020(9016KB) AllocSpace objects, 21(896KB) LOS objects, 49% free, 12MB/25MB, paused 56us,21us total 209.779ms
I system_server: WaitForGcToComplete blocked ClassLinker on Background for 177.623ms
V SystemServerTiming: DexUseManagerLocal took to complete: 182ms
After:
D SystemServerTiming: ArtModuleServiceInitializer
V SystemServerTiming: ArtModuleServiceInitializer took to complete: 3ms
...
D SystemServerTiming: DexUseManagerLocal
V SystemServerTiming: DexUseManagerLocal took to complete: 20ms
Bug: 263373204
Test: manual - See above.
Change-Id: I81e517fd3c18ccd3490947b16e36e7d43b2fc07c
Add getApplicationGender()/setApplicationGender() API to allow
app set the application's grammatical gender
Bug: 259175720
Test: atest and get/set the API
Change-Id: I83842eadd8cdaa7c148acf6dfb37df32564e241d
Move NetworkManagementService and NetworkManagementInternal from the
com.android.server package to com.android.server.net. Update
TEST_MAPPING to include NetworkManagementServiceTest in presubmit.
Bug: 259341026
Test: atest (triggering TEST_MAPPING execution)
Change-Id: Ibdff9c19c264ff54b9039e1f0aa4186641d5b302
Move the ArtManagerLocal initialization to a place where it can access
PackageManagerLocal but still is early enough to precede binder calls
to notifyDexLoad.
Test: Build with dalvik.vm.useartservice=true, boot, launch an app, and
check with temporary logging that
ArtManagerLocal.notifyDexContainersLoaded gets called.
Bug: 254043366
Change-Id: I97d59f9c15402648627006dde874a068b0706157
The service constructor and onStart() only does trivial work and its
start time is also tracked by TimingsTraceAndSlog. The new app op and
permission implementation will only be active when they are later
selected inside the existing permission and app op system services and
that selection will happen behind a feature flag disabled by default.
Bug: 182523293
Test: presubmit
Change-Id: I2d678ef2d5747440afebc92868f92c4a02565856
This service is callable by system components like keystore2. This
service calls into a mainline module API to do all the work for remote
provisioning.
Also include new OWNERS for the RemoteProvisioning implementation.
Bug: 254112668
Test: Locally modify keystore to call the new service
Change-Id: I6708d0b415798c78a4d66f279589d9def552ae78
This change includes:
1. Enabling WearableSensingManager to be retrievable.
2. Starts WearableSensingService from system server.
3. Introduces WearableSensingShellComamnd for testing.
Bug: 249135378, 244181656
Test: Builds.
Ignore-AOSP-First: to prevent new feature leak.
Change-Id: I4ffaac37c0fe8874ae8b0ae6fec086e4cd27b2f1
System server can only be compiled and signed by odrefresh in early
boot, so it is no use capturing dex load events for it.
Test: Build & boot
Bug: 254043366
Change-Id: If27569b784aeb882d3a20bd21a30137e6530e663
Start status bar manager service but not register global actions
provider on watches.
Bug: 257861786
Test: device can boot
Test: atest StatusBarManagerServiceTest
Change-Id: Ib9a13f159084f8970628a5eb89ca9aa88b2d050e
For now we can register both HIDL and AIDL sensorservice, and the vendor
can choose which one to use.
Test: atest VtsHalSensorManagerTargetTest
Bug: 205764765
Change-Id: I26ee176baea59f86281ae3a46ea580443064b5ef
On upgrade from Android 13 or earlier, LockSettingsService is creating a
synthetic password (SP) for all users that didn't have one before, and
re-encrypting the user's CE key with the SP. Currently this happens at
PHASE_BOOT_COMPLETED, since Weaver is not yet guaranteed to be available
at the previous phase, PHASE_THIRD_PARTY_APPS_CAN_START.
An issue with using PHASE_BOOT_COMPLETED is that during an upgrade,
PHASE_BOOT_COMPLETED happens after the userdata filesystem checkpoint
has already been committed. Therefore, if a problem occurs with the
migration to SP, the changes won't be rolled back and the device will be
left in a broken state, recoverable only via a factory reset.
Important migrations like this should happen before the checkpoint is
committed. Therefore, replace the use of PHASE_BOOT_COMPLETED with a
direct call into LockSettingsService in an appropriate place, similar to
the existing LockSettingsService.systemReady() call.
I also considered creating a PHASE_THIRD_PARTY_APPS_STARTED boot phase.
However, any new boot phase would become part of the services API
(services/api/current.txt), which is more than I'd like to do here.
Test: Made an intentionally broken build with
LockSettingsService.onThirdPartyAppsStarted() changed to throw a
RuntimeException at the end, crashing system_server. Tested an
OTA from tm-qpr2-release to that build, on a device that didn't
have a lockscreen credential set on user 0 (so that user 0 was
migrated to SP-based credentials just before the crash). The OTA
failed as expected and successfully rolled back to the original
build, with user 0's data still accessible (this was not possible
before this change).
Bug: 232452368
Change-Id: I77d30f9be57de7b7c4818680732331549ecb73c8
