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
When the admin has disabled fingerprint as unlock option, we let the
user know that the admin has disabled that option with a more details
link which will trigger the admin support dialog. And made some small
fixes apart from this.
Change-Id: I01021b952dc6fb29a65d37401a6411a6088d5cef
Update the UX and dig the data usage screen out of a huge whole of
technical debt. Switch every to use Preferences rather than standard
layouts and ListViews.
Split data usage into several fragments, all separated.
DataUsageSummary:
- Shows a summary of the 'default' usage at the top, this will be
the default sim on phones, or wifi if it has it, or ethernet
as last attempt to show something.
- Also has individual categories for each network type that has
data, cell, wifi, and ethernet. Maybe should look into bt though?
DataUsageList:
- Takes a NetworkTemplate as an input, and can only be reached from
the network specific categories in DataUsageSummary
- Shows a graph of current usage for that network and links to
app detail page for any app.
- Has gear link to quick get to billing cycle screen if available
BillingCycleSettings:
- Just a screen with the cycle day and warning/limits separated
out from the data usage.
AppDataUsage:
- App specific data usage details
- May need some UX iteration given lack of clarity in the spec
Bug: 22459566
Change-Id: I0222d8d7ea7b75a9775207a6026ebbdcce8f5e46
- 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
Create mHeaderView and set it as a pinned header, each time onActivityCreated
is called.
Bug: 20652673
Change-Id: Ia0e174f0686ac0abb601c591f3774c9152b785fa
Add a progress bar when the Wi-Fi screen is in a transient state,
like enabling, disabling Wi-Fi and scanning for network. This change
sets the progress bar as a pinned header at the top of the activity.
The pinned header container needs to be match parent so that the
progress bar can occupy the full width of the screen. If the header
view doesn't want to fill the width, then the header view *inside*
the container should be wrap_content.
Added an overloaded setPinnedHeader method that takes a layout
resource ID, and returns the view to the caller. This way the
inflater can set the parent property so that layout params will not
be ignored.
Bug: 17389577
Change-Id: I18d0eb7c72ad31d1c4b35a54789016c32c81fb93
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
Also add loading screen to manage permissions as this can take a
long time to load in some circumstances. Build loading screens into
Utils and SettingsPreferenceFragment so that it can be easily used
other places in the future.
Change-Id: I7febd06695487e02ced793a9fd418051b5f0eab8
- will actually make the Ripple look better and a bit longer
(it was showing and disappearing a bit too fast)
See bug: #14974443
Change-Id: I7a0354c679cfa8d9596bcb957c922b8dcf88f0e3
SettingsPreferenceFragment$1@273c8fdb was not registered
- add override for onUnbindPreferences() that will unregister the observer
if needed
- keep track of the root adapter so that we can unregister / register with
the correct one (by having a new PreferenceScreen the root adapter would not
be the same and thus unregistering the Observer on the new one would not work
and create the current bug)
Change-Id: I2cef0398c2ae0ab4f5ffd67ca20e8874be997bf6
com.android.settings.SettingsPreferenceFragment$1@3c1d9ecb was not registered
- use a monitor to control registering / unregistering
Change-Id: Id66dd698abf92643c97938e2091c3be38e6b78bd
...when "change language" warning dialog is on screen
- try harder at getting the parent fragment. First try by calling
getParentFragment() and if this is getting a null reference, try
again by using the fragment Id saved during onSaveInstanceState()
Change-Id: I3dbc6a229224c8770ff2c7e432e76b8796c4b099
- add a FrameLayout into the preference list fragment
- add public void setPinnedHeaderView(View pinnedHeader) and
clearPinnedHeaderView() APIs for adding and clearing the pinned header
Change-Id: I50ba5dd150167e0d49cc54bee1203f46db6d7a66
- remove unnecessary code
- use keyed Tag with a well known App key for preventing collisions
- fix missing Brightness Level preference key (used for highlight)
Change-Id: I070e3b8c3cb43da7addd34be192aade21951f57c
- for having the tint attribute to be populated you need to have the Theme passed.
This is why Fragment.getActivity().getDrawable(...) should be used instead of
Fragment.getResources().getDrawable(...)
Change-Id: I945eca98e1d73fda3b290a6ababfd1fb41118d8f
Gasp ... the Observer registering/unregistering code was not totally correct as
we were unregistering on a different RootAdapter.
- refactor the code for registering / unregistering the Observer
- unregister when the Fragment is stopped thru onStop().
Change-Id: I036eacd87c80fd2c9dedca705fb94a57a0c9a21d
- add to SettingsPreferenceFragment to know when the associated
RootAdapter is changing and thus being able to find the highlighted
Preference
- also, add the correct Search key during indexing. She should
match the one created when adding dynamically the Preference
- last, increase to 400ms the delay to do the highlight
Change-Id: I3a1a81fdf5c8ab5f3aaab29f16ea9879ab6df056
- use PreferenceFragment.onBindPreferences() to launch highlighting
- improve SettingsPreferenceFragment code for highlighting: now we can
find the View to highlight thru its Tag if there is no ListAdapter available
- add HighlightingFragment for highlighting a View from its tag/key. This
is dealing with cases when the content is custom and not relying on
SettingsPreferenceFragment (like DataUsageSummary)
Also:
- improve DataUsageSummary so that onResume() is not recreating the
Tabs all the time
- add missing "android:keys" on some Security Settings preference files
Change-Id: Ib1dd8238fe2fb57c151d584c0810a0e0a5ad97c4
- fix computation of the Preference position in its PreferenceScreen
- use "highlight" (scrolling and Ripple effect) for showing the result
- "highlight" is only done once
Change-Id: I232d79d795b0983beac5a9fec3dfbe9da329c98f
- 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
- 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
Fixed bug in WirelessSettings where it was asking users for a PIN when
they weren't restricted. Did this by refactoring the preference level
pin checking into the superclass, where it checks for the restricted mode first.
Also pin protected changes to certificates for restricted users.
Change-Id: I8310fd39f0862159668318fc1360ec6859cc00d5
