- Handle a backup URI, so that if the specified URI is not available,
another can be used.
- Add some data to help intents when they are intent URIs
- Fill in the context with a classname when it isn't present
Bug: 15475009
Change-Id: I7050fa61121901929e650b20bd7a0ae21e8ba207
Allow help uris to be either an intent uri or as uri (as they were
before). Also add a default help uri, and specific helps for several
screens.
Bug: 15475009
Change-Id: Iff982892973f01d32ff61ea88d4844e9a7153500
Allow system apps to add a tile to the top level of settings that
links to an activity through adding a filter for a specific action.
Determine the info for the tile based off manifest info for the
activity. Also allow the same for managed profiles, but show a dialog
in between to select which profile.
The category in which the item is to be placed must be in meta-data.
The icon and title can be specified through meta-data as well or
if unspecified the activity's label and icon will be used.
Also added an optional <external-tiles> tag to the dashboard
category xml, this allows Settings to put external tiles
in the middle of some categories (Personal does this).
Bug: 19443117
Change-Id: Idc9938d1549d181103a3030a8784b527215a8399
- 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
- follow UX spec
- update also the Search Panels (suggestions / results) to
follow the same specs
See bug: #15384992 Setting Dashboard - padding updates
Change-Id: I3d27a3b3d9779644f8ea123990a0c7bed8d4ba74
- prevent loading categories twice
- add some logging to see the time taken for building the Dashboard titles
Change-Id: I31724c0e66fe3b453a87f12476f58db84c73423f
Introduce the new Dashboard (a grid like presentation of
Settings top categories) per UX specification.
- the Dashboard is composed of "categories" and in each of them
you have "tiles"
- implement a new layout for showing top categories
(DashboardContainerView). This layout basically acts like a
grid
- depending on the device configuration make the grid with 1
column in portrait / 2 colums in landscape (phones) OR 2 columns
in portrait and 3 in landscape (tablets)
- take care of Accounts adding and removing (as it changes the
number of tiles to show)
Also remove all the old code related to Headers
Change-Id: Ie29944132c1b4c3f7b073d5a7d4453b8f5ec19a7
- 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
- there was a crash when inputing "w" then "-" then "-". This
crash was due to the InputFilter which got some strange indices
from the BaseInputConnection.
- so now we are doing our own filtering before sending the query
to Sqlite. We only keep Letters / Digits / Spaces.
Change-Id: I66dcbebeec9217cf8fd65a16b10fe2304d98cf58
android.database.sqlite.SQLiteException: malformed MATCH expression: [ avs- /y@ggmd"*] (code 1)
- the real issue was linked to the double quote
- add an InputFilter to the query EditText so that we allow only
Letters / Digits / Spaces (and this should works for all Locales)
Change-Id: I6016cc25d154b386870379dfa4c79a40c5505530
- remove crashing code. Basically let the Framework do its work.
No need to save the state of the EditText by ourselves.
Change-Id: I49e98a852f4fcda61eabaa2967d027942905ec27
- 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
- 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
