Currently when ListPreferences are used in a PreferenceActivity, the summary
values are set to the same as the current index in mEntryValue. This patch
adds the ability for a string substitution to be used in the summary
which points to the corresponding entry in mEntries to aid in
localization.
For example a preference may be named "color" with the following attributes
in the locale "de" (German):
mEntryValues = { "red", "green", "blue" }
mEntries = { "rot", "grün", "blau" }
mSummary = "Die Farbe ist %1$s."
getSummary() returns "Die Farbe ist grün."
Change-Id: Iea169ac3d1c9d6290d853fc7c67a7c4c8a11bb90
This introduces problems when scrolling through preference screens, due
to a clash in this cache versus the ListView's cache.
This reverts commit 01dbc2ed55.
If layout id is specified for a Preference object, convertView is set to null
in its adapter which results in inflation of Preference view in getView each time the Preference object is laid out on the screen.
Just use an instance variable to cache the inflated view nulling it whenever the layout changes and use it in initing the convertView in getView.
More CPU speed stepping happening with newer devices, so we need
to qualify CPU time with the CPU speed, since power consumption
varies greatly by speed. Apps that peg the CPU should get a higher
penaltly.
Also, fix for 2062930: NPE at VolumePreference.onKey()
During orientation changes or homing, the volume is reverted. Also,
during pause/resume, the original and modified values are remembered and
restored if the dialog was up.
framework classes to deal with the new property. Also update various
documentation that mentions the default ringtones.
Use the build property as the default alert when the user has not chosen
an alert for an alarm. This is also used if the alarm alert is null when
the alarm fires.
BUG=1723684
Automated import of CL 145870
The problem was that the Preference widget was reenabled when its dependency
was in enabled state. The enabled field was basically overloaded. The fix was
to add an additional field to keep track of whether its dependencies were met.
Original author: chanm
Merged from: //branches/donutburger/...
Automated import of CL 143298
The problem was that the Preference widget was reenabled when its dependency
was in enabled state. The enabled field was basically overloaded. The fix was
to add an additional field to keep track of whether its dependencies were met.
BUG=1653960
Automated import of CL 143150
