- Use SettingsLib Indexable
- Directly use resource id in getPreferenceScreenResId
Bug: 135053028
Test: roboletric
Change-Id: I05f493b55e8b6e2091301e9231ba5615215618e6
- Add function getXmlResourceId, Fragments don't need to write
xml resource id twice.
- Remove getPreferenceControllers from Indexable.java. Because it will
move to SettingsLib later for other apps which don't need this function
Bug: 135053028
Test: robolectric
Change-Id: I1e74519aecdea3dde64a5aea79f08d766dbc0003
When possible, remove or simplify getNonIndexable() logic in fragments,
and use searchable="false" in xml to suppress index.
Change-Id: I5bdf5bc7d5494a64cdd9e230a51321a4b210af69
Fixes: 112608186
Test: robotest and manual search
Now we can easily mark a preference nonIndexable in xml instead of
adding key into searchIndexProvider.
Bug: 112608186
Test: robotests
Change-Id: I0ff16d44bb7b6ad148d3d35f09ca0da0163f73f4
- If a <preference> tag also defines a controller, we will try to
instantiate it before displaying the UI. The same logic is shared by
BaseSearchIndexProvider so it also drives search suppression.
- If user also defines a list of controllers programatically, the
programatically created ones takes precedence.
Bug: 73668763
Test: WIP
Change-Id: I7aecec270bcd3af261e012ef1f6995d2a523cfa1
Add the ability to define a Preference Controller
in xml using the 'controller' tag.
This is useful for two reasons:
- It allows the controllers to be instantiated via
reflection for Slices and Dashboard fragment
- Removes the requirement that controllers be defined manually
in Fragments
In order to be instantiable, they must have a unified construction
following either:
ClassName(Context)
ClassName(Context, String)
Also added a robotest that verifies that all controllers defined
in XML follow the constructor schema, and extend
BasePreferenceController.
Test: robotests
Bug: 67996923
Change-Id: I304b35dc666daebecf0c9e286696f3f2a510704a
This is a clean up to action bar menu item pattern, we will use the same
pattern to build search icon on all pages in a later change.
Bug: 68814716
Test: robotests
Change-Id: Iedd3ec263e8ccb63ed75ec7a95b28c00878b1de4
'On'/'Off' depending on whether the backup is enabled in settings.
Refactors BackupSettingsActivity to be shown on System fragment via
xml/PreferenceController instead of category in the manifest.
Bug: 36891827
Test: make RunSettingsRoboTests
Change-Id: I61425fed4d63055c6c386be38792ae074aa72679
- remove DashboardFeatureProvider.isEnabled() and all relating code
and tests.
Bug: 35764802
Test: make RunSettingsRoboTests
Change-Id: If7796677abc8904b7436525836d50cdef38e37a4
- Use static summary for most items
- Move summary for user setting to user&account setting
Bug: 34975053
Test: RunSettingsRoboTests
Change-Id: I9bf87267778dc5933f97f5d3b9ae0f4f0b8da1a8
Use the centralized registry to look up category key instead.
Bug: 32936784
Test: make RunSettingsRoboTests -j40
Change-Id: I0b8c72d70f93e4b5c58871ac90de41f69ad15653
Refactored getLocaleNames() into a FeatureProvider interface so it's
reusable and testable.
Bug: 31801428
Test: RunSettingsRoboTests
Change-Id: I2d31a66a4b32cfa7a364a4cfef1f6eea87084577
- Added a activity-alias pointing to displaySettings as top level
setting item.
- Refactored all preference logic in DisplaySettings into
PreferenceControllers. During fragment onAttach it installs all
controllers, and during onResume it updates preference state. Each
controller listens to its own preference change event.
Bug: 31800242
Test: RunSettingsRoboTests
Change-Id: Ibc9bf200c5acce7c4ae9292340822afee27a3a28
- Make a SummaryConsumer interface. Things that needs latest summary
should implement this interface (DashboardAdapter for homepage,
DashboardFragment for subsettings). This also decouples SummaryLoader
from relying on SettingsDrawerActivity.
- Make DashboardFeatureProvider more generic to load DashboardCategory
by key.
Bug: 31781480
Test: RunSettingsRoboTests
Change-Id: I9c65456fb433a74c352498251e0ccf65da0be1f0
Merged refreshAllPreferences into DashboardFragment. This hopefully
makes it more modular to manage preference display logic in each
dashboardFragment, and makes it more efficient to monitor category
changes.
Now subclasses needs to implement 2 methods:
- displayResourceTiles(): for 'static' preferences from xml
- getDashboardTiles(): returns a list of dashboard tiles and superclass
will wire it up to preference screen.
If getDashboardTiles() return null (aka no dashboardCategory available),
the fragment will not attempt to monitor category change. The edge case
is that if a package starts to provide a tile for this category, we will
not be notified. I have not seen this case coming up. If we indeed need
to handle this case, the category listener needs to have a way to
monitor specific category rather than globally.
Bug: 31781480
Test: make RunSettingsRoboTests -j40
Change-Id: Ia9f9541b95816214df0d0bb27e3e41078c36c5ca
In order to move the preference and its logic cleanly, created a
controller object that encapsulates the preference/click handler.
Bug: 31801428
Test: RunSettingsRoboTests
Change-Id: I332384e20fbf0e21d2f3becb531d97b20f7f7ef1
- Use activity-alias to define which activity shows up in what category.
We choose activity-alias because it creates a reference to UI we need
without having to define a new set of intent-filter and/or category
keys. This reduces maintainence in the long run. We should merge
metadata from activity-alias into targetActivity when cleaning up.
- Created new System dashboard activity that hosts all system category
tiles dynamically, and a static tile for checking system update.
Bug: 31781480
Test: manual
Test: make RunSettingsRoboTests -j40
Change-Id: Ia2d762e3e1aebd17423a395c5e6c286dc3326492
