The flag to check whether the single line title attribute is initialized
only when we processed the layout attributes. When the attribute is not
set in the layout, but set through the setter method, the flag is not
being updated properly, and hence the title view is not set correctly.
Need to update the flag as well when the setter method is called.
Bug: 62947301
Test: manual
Change-Id: If843663165a0f3348048aaf1d920f3b740af5bc3
Only call setSingleLine() on the preference title if the attribute is
set.
Bug: 37328004
Test: manual
Change-Id: Ia95230cd08feaf8213cb5917c105d070eb30c11c
Add an attribute to Preference to specify whether the space of the icon
view should be reserved when no preference icon is provided.
Bug: 36448695
Test: manual
Change-Id: I03b49fe93d54bb9106cf167a677a9ea544a3e3a1
Add an attribute to Preference to specify whether single line is to
be used for the preference
Change-Id: I578b496cdc4c5b0e3b3146183c6c30c4dee02eab
Fix: 36389770
Test: manual
There is also change in PreferenceManager.getSharedPreferences. The
original was not always returning null in case mPreferenceDataStore is
not null. That was contradictory with the java doc and conufing during
the runtime. Added tests for it.
Test: Separate CTS (2) being submitted along this one, see the topic.
Bug: b/34322039
Change-Id: I78a6758a674c3c8139bbe66ec17f2e29ca847828
Until now we have been recycling only framework preference widgets since
there were no guarantees for third party preferences to support recycling.
This let to broken animations for preference widgets that are outside of
the framework.
This change makes recycling to be used always and in case the developers
need to turn it off they can explicitely use a new attribute that is
being added to the Preference called "recycleEnabled" and set it to false.
Bug: b/34334451
Test: Test are part of the same topic.
Change-Id: I324087841e1edddbf0d3eaad00b5895a196acff6
Bug: b/35977048
Test: Done manually. Automated test will be added later.
After recent changes in PreferenceActivity finishing the activity on
pressing back is not correct anymore. Instead onBackButton method should
be called to deal with it (we have fragments transactions for instance).
There can be multiple buttons:
1. The native default one - calls onBackPressed by default so no extra work
needed.
2. PreferenceActivity has buttons that can de displayed when settting
EXTRA_PREFS_SHOW_BUTTON_BAR to true. But it is a private API and I
didn't find any usage of it, so there is no need to change that. Also
it looks like something very specific used in WiFi wizards.
3. Apps often use a toolbar that has a home button which essentialy
emulates back button. The issue is that this Activity never had support
for this. So apps had to override onOptionsItemSelected and some of
those are unfortunately calling finish() which worked previously when
PreferenceActivity wasn't using fragments in single pane. This CL adds
support so app will no longer need to override that method and some
apps need to be instructed to use that override in O.
Change-Id: I94f557edb2e03f89fbf02e800beb390b2ad0544f
I have done some important cleanup of java docs where it wasn't clear
enough that there is a PreferenceDataStore option.
I have fixed incorrect behavior when setting default value while data
store is assigned. Previsouly we looked into SharedPreferences which is
incorrect.
I have also changed behavior of methods getSharedPreferences and
getEditor. These methods now return null when custom data store is
assigned. The reason is that we definetly don't want to use
SharedPreferences if data store is assigned. So the original behavior
was a bit ambiguous. Also if we didn't enforce it, we would have
troubles to change that in the future.
Test: Tests are under the same topic.
Change-Id: Ib7303bae13648767c519edba74ef9a7143e703df
These were never part of any public API level, so apps should never
have been using them.
Test: builds, boots
Bug: 31241513
Change-Id: I4fc8f5c325da56694a5db98acc995a22d4947805
When navigating from a preference panel back to the headers in single pane,
the title was not restored and the original one (of the previous
preference panel) was kept instead.
Bug: b/35468759
Test: Is covered in ag/1761868
Change-Id: I30cc4c1d2a53d05411cc849ce8423b694c76976a
Transitions in and out of multi-window were causing navigation history
losses + incorrect views to be displayed. The history loss was caused by
the fact that single-pane mode was using Activities but multi-pane mode
was using Fragments. Translating history between those two would be
challenging. Because of that Fragment approach was also applied to
single-pane mode. That required some changes in back press handling and
initial logic when creating the PreferenceActivity.
Test: Separate CTS CL being submitted along this one, see the topic.
Bug: 32201932
Change-Id: I5e6a6a21c34e813d1c3522ae7f5e33f43887c602
Preference class now keeps track of its PreferenceGroup parent which
makes it easier to remove it from the preference hierarchy.
This required a new API method.
Test: Separate CTS CL being submitted along this one, see the topic.
BUG: 30599046
Change-Id: Ia9f274ef0315cb09a8c558e781b10f57efd28406
Developers will be able to use PreferenceDataStore to replace default
SharedPreferences to store / retrieve the data.
Test: Separate CTS CL being submitted along this one, see the topic.
Change-Id: Ie46a876dcb14b46b8b2584735c106c25655ec6cf
Preferences lack a title on watch type devices due to lack of ActionBar
support. A custom ListView was added to use a custom wrapper adapter to
add a persistent header view at the top of the ListView that developers
would not be able to remove via the ListView API.
Bug: 27962897
Change-Id: I6bccecf85592d9507e0c7a04c9a035617001e9ef
Symptom:
1. Set Alarm volume to 0 on Sound & notification screen, then tap
Back key and reopen the screen.
2. Set Alarm volume up to 1 or larger, then alarm icon changes to
unmute.
3. Set Alarm volume down to 0, then the icon doesn't change to
mute. There expected the icon should change to mute one.
Detail and sample:
SeekBarVolumizer manages a variable mLastAudibleStreamVolume.
This variable decides whether it executes mute procedure or not.
When this variable is 0, it will not execute mute procedure.
Because the condition to execute mute proceduce is below.
- lastAudibleVolume * (mute ? -1 : 1) < 0
What original code will not update this variable from constructor
is one of problems. So once the icon changes to unmute one,
the icon will never change to mute one.
Solution:
Changed the condition as it doesn't depend on value of
lastAudibleVolume.
Bug: 30265487
Change-Id: I42165f39d1f344169674c09a045b6fb2bb25db4d
Also hide a few APIs as requested by council. Add a method to
easily determine if a given File would already be encrypted at rest
by the OS.
Bug: 27531029
Change-Id: Icad5f1cd56411ad3ac707db85fd7449acdcc4b94
Mostly consists of removing the word "encryption" from most APIs,
since we can't actually make promises about the data being encrypted.
Bug: 27531029
Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
Overriding getSummary breaks support for summaries even though it's
supported in the layout for SeekBarPreference. If there's no summary the
return value is already null in the inherited implementation.
Change-Id: I2e72ea3c4a624acbf200e9617173eb072572fa57
Developers using these classes can getPreferenceManager() and
explicitly set the storage location for any SharedPreferences values
persisted through it.
Bug: 26747519
Change-Id: I133045df6a69aa99f33b6b6c447f52605468b927
Needed for apps that want to migrate SharedPreferences from CE to DE
storage. Note that a device will only ever enter a CE mode with a
factory reset, so apps should only be using these APIs when they
want to migrate files to a consistent location on non-FBE devices
for simplicity.
Bug: 25503089
Change-Id: Ic846215da1617d116a048e036415ac7ad523b770