Delay DropBox until SettingsProvider becomes ready

It turns out that we are still not ready to publish
DropBoxManagerService at an extremely early boot phase as we attempted
so [1].  Our best right now is to publish DropBoxManagerService
immediatelly after SettingsProvider is installed.

Otherwise, if WTF logs are generated in a too early boot phase, it is
indeed possible that two different instances of SettingsProvider can
be created.

The first SettingsProvider instance, created by the
DropBoxManagerService access to Settings, is still present, and a
reference is held in Settings.ContentProviderHolder, such that
framework API access hits this instance.

The second SettingsProvider instance, created by the SettingsService
startup, also still exists and is referenced by
SettingsService.mProvider -- this instance is hit by "settings" shell
command access via SettingsService.onShellCommand().

This creates a situation where settings modifications made via shell
command cannot be seen by the usual frameworks APIs, and vice-versa.

 [1]: Ie71d53fc125ebc47fa08ef59a8b7e4f66f2e805c
      d79d203b357b8ac54c36e028d8bb80e3a39165f5

Bug: 72399950
Fix: 72450122
Fix: 73505784
Test: atest CtsTextTestCases:android.text.format.cts.DateFormatTest#test_is24HourFormat
Test: atest CtsInputMethodServiceHostTestCases
Test: Manually verified as follows
      1. Boot a certain device that has neither /proc/wakelocks nor /d/wakeup_sources exists
      2. adb shell settings get secure enabled_input_methods
         -> shows non-empty result
Change-Id: I66b68e7f456c4e0e8f5933e65202c61ed862088d

0 files changed, 0 insertions, 0 deletions