- remove that HomePackageReceiver from the AndroidManifest
that could force Settings to run
- use a HomePackageReceiver into HomeSettings and DashboardSummary
- fix also the BatteryInfoReceiver for refreshing the Dashboard
Change-Id: Id3891529fc176e7e4c450f2ce723f8ac2af66c58
- add a BaseSearchIndexProvider to HomeSettings
- use a BroadcastReceiver for tracking add or remove of
Home / Launcher apps
- add "launcher" synonym for "home" too
- also code cleaning for DynamicIndexableContentMonitor
See bug: #16484927 Add "launcher" as a synonym for "home" in settings search
Change-Id: I819f4e5f7bd5e9a7882609206b2733ea1912fc69
- get rid of PreferenceActivity as much as we can and use fragments instead
- add Drawer widget
- add Dashboard high level entry into the Drawer (but this is work in progress and would be done in another CL)
- add bypass of fragment's Header validation when launched from the Drawer but *force* validation if external
call thru an Intent
Be aware that WifiPickerActivity should remain for now a PreferenceActivity. It is used by SetupWizard and should
not trigger running the SettingsActivity's header building code. SetupWizard is a Home during the provisionnig process
and then deactivate itself as a Home but would make the Home header to appear in the Drawer (because momentarily we
would have two Home).
Also, verified that:
- the WiFi settings still work when called from SetupWizard
- when you have multiple Launchers, the Home header will appear in the list of Headers in the Drawer
Change-Id: I407a5e0fdd843ad7615d3d511c416a44e3d97c90
When the user deletes the last-but-one, there's nothing more that
they can do in Home settings (and we'll be suppressing it from the
top level of the Settings UI as well), so we now back out with
a dialog explaining the situation.
Bug 10918801
Change-Id: Id03169dace976f7de639e3b3ab3d50ed161258d8
