The language and input settings are highly dynamic and this change adds search
support for that. This category depends on installed IMEs, input devices, user
dictionary configuration, etc. We not only compute the right preferences to be
indexed but also track related system state in the settings app to rebuild the
index if needed.
bug:14066763
Change-Id: Ia89d9e35bd79abf8d74614691aedf4ca9b11b6f2
We have some settings that are dynamically generated based on what packages are
installed. For example, accessibility services, etc. We now update the index when
the relevant installed packages change.
bug:14056852
Change-Id: I6143382bf2c7399d3c80abea0835d717935a9200
..that has no Fragment nor Intent at SettingsActivity.onHeaderClick(SettingsActivity.java:654)
- satisfy the Monkeys has they were able to click on "WIRELESS &
NETWORK" header which is a Category and normally non clickable...
(so probably a race condition)
Change-Id: Ia33d2b6e55e910409a566e5f05c1e3bae8008807
- modify the SQlite data model
- update Index code for managing the key value
- pass the key when launching a Fragment or and Activity
- implement a small animation for highlighting the Preference
from a Search result
Change-Id: I617643a4e5e3b752ece8f45ce7d5429037e479da
...affordance is tapped from second level sub settings page
- start an Activity instead of switch Fragments
Change-Id: I0e47d6539a3a048d7aa25bdb125c4c99031f9e85
... settings after orientation change
- gasp, there were some issues in the way we were tracking if
a search result fragment was opened. Simplified that code.
Change-Id: I7f8efb3a5aab1a275193f7de15ac50ca33bdad16
...Settings is launched with an Intent
- fix the NPE by checking if mSearchMenuItem / mSearchView references are null
Change-Id: I7518c8360af88a20df780be8cb89360a26cdb8d0
- now support ListPreferences and save the "entries" attribute
- update Index database schema (and increment its version)
- do some clever stuff when showing Search results: if there is
a "$s" or "%s" in the summary (replacement strings), just use
the entries instead
Change-Id: If36595c3816706b6349faff7d3c2e725d3ea33f4
- follow the UX spec by no more using a Drawer
- the Dashboard is now a Fragment that contains the list of Headers
- the search results are also put into a Fragment that is replacing
the initial one (Dashboard or other) when expanding the SearchView
- use a SearchView for query input
- when tapping on a Header or a Search Result, re-launch Settings as
an Activity so that we are benefiting from the Activity stack for
UP affordance and BACK button
- manage UP affordance to show it only when needed
- move some Actions to the Menu in the ActionBar for allowing space
to the Search action and removing some clutter
- fix an issue with the Index and WiFiEnabler and their cached Context
that was not updated when there was a Configuration change
- simplify the SettingsActivity code by extracting some inner classes
Change-Id: I50b5f77bb44a7fade1886114dbbc820609a5e63d
- define SettingsSearchIndexablesProvider as an internal
SearchIndexablesProvider
- protect access thru using android.permission.READ_SEARCH_INDEXABLES
- update WallpaperTypeSettings and WifiSettings for taking care of
the new model
- update the Dashboard for taking care about external Icons for the
search result
- update sqlite model/version for taking care about Intents
(enable launching external applications for showing the settings)
Change-Id: I2e38599327e6480f1754f52666becce0884cee9d
scrolling through settings options
- force the image and background to null when needed in the Adapter
Change-Id: If4c1769dcd1651b683a34001dcd922c6554252c0
- introduce a new private interface "Indexable".
- refactor Wallpaper and Wi-Fi settings to support this new
interface.
- only index saved/remembered Wi-Fi networks
- also add the capability to remove some data from the Index.
Fragments that want to publish some dynamic indexable data should
implement the "Indexable" interface and provide a static final field
named "INDEX_DATA_PROVIDER" with is the Indexable.IndexDataProvider
interface for providing the data for indexing.
Thru this interface the Index can ask what are the data chuncks to
index.
Change-Id: I31e7212c87b8218efe1a8f3028147cb19e119be6
...java.lang.NullPointerException: Attempt to read from field
... 'long com.android.settings.SettingsActivity$Header.id' on a null object reference
- fix the AndroidManifest for missing meta data
- fix NPE causes in getHeaderTitle()
- update how we are putting Fragments on the BackStack
Change-Id: Ifc0bba744c3b2a0603c2f11f711ef493cbacc9d2
- add basic UI for search
- build the search Index thru sqlite FTS4 (faster than FTS3)
- create the search Index on the fly depending on the locale
- re-index if there is a configuration change
- re-index too if the Android build version has changed (usefull
for an Android OTA or when a new Android version is pushed as
we need to recompute the Index)
- search thru "title" and "summary" Preference's data
- group results in the same order of the Settings categories
into the Drawer
- rewrite "title" and/or "summary" if they are containing
an hyphen "\u2011"
- add Preference Keywords (only for the Settings App) in the
Index and allow search on them (Wi-Fi network preference is
used as an example)
Known restrictions:
- we cannot yet search for "dynamic settings"
- ... nor we cannot search for settings coming from an external App
(like the Phone App and its related settings that are surfacing
into the Settings App).
- will need a few other CLs to add more keywords (and have them translated)
Change-Id: I017a4d6c433f28c257c08cacc1bed98c4c517039
- now select the correct header when launching Settings shortcuts by
taking care of initial header
- also fix an issue when having to "double BACK" on the initial header
- some code cleaning (no need to test non null references)
- move code to group it by topics
Change-Id: Ifdf6dd7f5605e858b324d00165f0a5e8124efdfc
Read-only version of the configuration screen for
Limited Interruptions. Defaults to the logic implemented
for this mode, namely block notifications except for
Calls & Alarms.
This settings panel will serve as a target for the
configure affordance in SystemUI.
Change-Id: I33fd1e11ab76dbb7044bb94cb096cd892945947d
Related to bug #12939786 and bug #13223838
- first use Fragment BreadCrumb for managing Titles and Back
- consider the first fragment as the initial one (both in the
normal case and in the shortcut one)
- fix usage of the Fragment BackStack so that in all cases we
are returning to the initial Fragment before exiting the App.
Change-Id: I96989d14f4e88688747b93ab9fadd96aea214a2c
Second pass:
- use Theme Holo for the Drawer too
- add a temporary background for Drawer icons (so that they dont mix
with the Drawer background)
- remove the "More..." icon as it was not needed
This CL will show that there is a discrepancy into the Drawer icons
size (some are smaller than the standard size, some other bigger).
This issue will be fixed when the new set of Icons will be delivered
by the UX team.
Change-Id: I431882df9b98157e98a1b735f31d9e77ef846767
... and use Holo (Dark) Theme for the Drawer as requested by UX
Also remove the Wi-Fi and Bluetooth switches in the Drawer per
following UX specification.
Change-Id: I4fc17481255b5db337a887033bc831ded0d2d701
- revert back to an Activity instead of a fragment. This
is a straight reverse of the changes introduced for trying
to have a Fragment.
Basically ChooseAccountActivity was previously an Activity for
choosing an account type. If the list of account types was containing
only one item, then the ChooseAccountActivity was just a pass thru
and was falling back to the only account authority available.
In the current reported bug, this was happening by disabling the
Email app and thus having only the GoogleAuthenticator as an
Authority.
Then in the onCreate() the ChooseAccountFragment was seeing that
there was only one account authenticator and issuing a BACK button
press. Too bad, this was done into a non finished Fragment transaction
and leading to a crash.
All in all, we NEED to have an Activity and cannot use a Fragment
in that case.
Change-Id: I4a867a25fe9580929ec50a6775105adac1f88c52
...on type of accounts(corporate,google etc.,) in Settings under Accounts section
- allow Account Type (corporate and the others...) entries to work.
Basically as they are sharing the same fragment we could only hit it
only once (and the first hit was winning).
Change-Id: I16683fc7342564a8ed1a4853a576166ab4d91df9
- fix behavior when we are closing the Drawer. Now will not trigger twice the same action
- fix selection in the Drawer for "Add Account": it basically should never be selected
as it is more like a button
- fix also Titles stack when launching an Intent
- remove some dead code
Change-Id: I196ad9fcd0599703f2abb902b088fbda9b4690a0
- save the titles stack during onSaveInstanceState(...)
- set it back when creating the activity if there is a savedInstanceState
and restore the title to the last item in the stack
Change-Id: Ic6c2714f5474275c9f55cc4d6c70d14f6a8cd993
- remove duplicate reference to current header (mCurHeader) in favor of mCurrentHeader
- clean onSaveInstanceState()
Change-Id: Ia9322471f0b0d13d51e105c8fd625774d8867fdc
...Can not perform this action after onSaveInstanceState
- prevent a click on the Drawer's Headers when the App is paused / finished
- register / unregister the DrawerListener when needed
Change-Id: Ia270ef27b23c66d55565bbb73d4f6a6531b742d2
Revert "Fix bug #12939786 BACK should go back into the Fragments BackStack and finally to Overview ...and then exit the Settings App"
This reverts commit 4cc95a53c2.
Change-Id: Iaa21d4771d0b004eff3d8e68b91b546a633d8f23
...and then exit the Settings App
- fix the way we manage the Fragment BackStack
- revert back ChooseLockGeneric to be a PreferenceActivity
Change-Id: I3c366b4be606e2e211facd0299b9a2de5cc6ea79
- ApnSettings is now a fragment so introduce a new ApnSettingsActivity
- ApsSettingsActivity will use the ApnSettings fragment
- move the getListView() call to onActivityCreated(...) as the ListView
needs to be created before this call can be done.
- add also an alias for the old activity name ".ApsSettings"
Change-Id: Id228722d7f34415d4b036282f0845e28546111df
- 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
