- when the fragment is created, checks the argument to see if the extra
fragment arg key is set. If so, do not hide the preferences in the
advanced button.
Change-Id: Id662ae1cec77edad7fcd5d6daa71929a8cb1402c
Fixes: 68988454
Test: make RunSettingsRoboTests
In fragments where preferences were being injected after
the super#onResume, the incorrect preference was
being highlighted as the selected result.
This is because the index of the preference is calculated
in SettingsPreferenceFragment#onResume, but the index is
not checked again before the item is highlighted.
Instead, we calculate index right before we highlight.
Change-Id: Idaa655f682a1a6186c1996fb51d352589bbeda0f
Fixes: 62179739
Test: runtest --path packages/apps/Settings/tests/app/src/com/android/settings/SettingsPreferenceFragmentTest.java
Also consider the visiblity of list container, when list container
is invisible, we should show the empty view.
Bug: 62062415
Test: RunSettingsRoboTests
Change-Id: I065e70386242c425ef3cbfb2b703a5433dbe40c1
The preference framework does not remove pref recursively. So when a
preference is nested in preference hierarchy, it's not safe to simply
call screen.removePreference(). We need to first find its parent and
remove pref from its parent.
Change-Id: Ic7fefa498ed71a8877d862845ddcc2d6d6034a55
Fix: 38507066
Test: make RunSettingsRoboTests
The implementations have been imported into SettingsLib. Setting's copy
can now be removed, which this change also does.
Test: Manually check battery status, which uses FooterMixin, looks OK.
make RunSettingsLibRobotTests && make RunSettingsRoboTests
&& make RunSettingsGoogleRoboTests
Change-Id: I6539605fdad80d156ff5ff249e68df4a1c412067
There were two issues that stopped the options menu from
showing properly. First, the SettingsPreferenceFragment did
not call its super class, causing the Lifecycle methods to
never be called. Second, the options menu was not being
invalidated which also stopped the Lifecycle methods from
being called.
Change-Id: I29f2fc105c7ecae7adaccb2e4643e48646398d8d
Fixes: 37255835
Test: Robotest
- Add a method in VisibilityLoggerMixin to log visible event using
LogMaker, which allows logging additional FIELD_CONTEXT field.
- In Utils.startFragment, add current page's metricsCategory as an extra
to next page.
- In next page's onResume(), extract the previous page's metricsCategory
and send it to VisibilityLoggerMixin.visible()
- Update all caller with additional paramters
Change-Id: I8e1f2597fa465b7d3aa16fa1d21c052a3219694a
Fix: 35359289
Test: RunSettingsRoboTests
- Create a new layout for footer prefs.
- Create a new FooterPreference type to use the layout
- Create a Mixin to create and add the pref to screen
- Create a new lifecycle observer type to invoke mixin at right time
- Switch SettingsPreferenceFragment to use footer mixin.
- Switch FingerprintSettings to use the new footer pref.
Bug: 33579394
Test: RunSettingsRoboTests
Change-Id: I548ac39a0d120196a7ffed09b4f98bd9a80bae90
This allows app fragment use a less heavyweight fragment as super class
if they don't need PreferenceFragment. Using this class as base is
generally easier to set up robolectric tests too.
Bug: 33354536
Test: RunSettingsRoboTests
Change-Id: I91c4d242ea0333c76c8767c03c3f18dee6b6e104
The searched item isn't highlighted.
To fix this issue, the highlight process should be posted
as Runnable object.
Bug: 31983855
Test: manual - search a item in Settings app
Change-Id: I0dcc5bb52b2faa0a23991459885d8dfcaed0f226
Bug: 30681771
Test: SettingsUnitTests
Refactor visibility logging from InstrumentedFragment into a mixin. And
apply mixin in remaining fragments.
Change-Id: Ibbb59904336254a3e4bb9e8c7d0b36e5a6bc2622
Bug: 30642749
The 2 classes are almost identical so I'd like to just merge them if
there is no specific reason for keeping both.
Change-Id: I46af41388e25abf79066ff25bfb793cdef2e06ea
Its broken and isn't worth maintaining, instead port the few things
using it over to SettingsPreferenceActivity with wrapping blank
Activities like the rest of Settings.
Change-Id: Ic82f0dcb63ed9b4078f7da6a79c0c52f0130e8d1
Fixes: 28779941
Deleted a bunch of unused colors. Also deleted the FAB
since it's never actually used, The one xml location sets the visibility
to gone and it is never changed.
Change-Id: I9424d581960ef879f6742bf8f06ac8932224c7cc
Take into account the prefs we are currently caching within the
group when counting how many prefs have been added.
Change-Id: I962acd41592c1a9366882711d3f4944bffb54d22
Fixes: 27931457
This is a follow up to 0708d9e119. The setHasOptionsMenu has
to be set for the back button to work and this needs to happen
regardles if the fragment has an help uri or not.
Bug: 28237921
Change-Id: Icec7a94312bdab5470efa0893a339d753c995eb1
Moved HelpUtils to SettingsLib in frameworks/base so it can be shared by
packageinstaller as well.
Bug: b/22096093
Change-Id: I8d620abcde8279a3b4d11bbcff8ae9b6f46a1895
Disable animations for all SettingsPreferenceFragments, unless they
explicitly ask for them before creating their preference screens.
Turn it on for all fragments using the cached removal currently.
Bug: 27713314
Change-Id: I1bc14e7aeb3ee5b8ddb4f3547f472305cd312edf
Removing all prefs causes ugly animations, so avoid it at all cost
and cache all the prefs (while still added) as long as possible.
Bug: 26271353
Change-Id: I33b84d751938b460f4b66c0158057407dd45d974
whenever the Talkback setting in SUW is pressed, and remove check for parent
Activity from SettingsPreferenceFragment.
Bug: 26734639
Change-Id: I5671735437844ac54ea68322838d9b6b5c81957f
summary), Talkback no longer disabled when preference is tapped, fixes
SettingsPreferenceFragment to not check parent class to determine whether to
show options menu.
Change-Id: I3345e1a878f51b4387ca1bfe89855339617a94d6
The empty view wasn't being updated initially by the fragment
so it was being left in an empty state since no preferences are
added after the fact.
Bug: 25609200
Change-Id: Ib9aa02ba94bf7077d01892d96d79d39203047f4d
