Every time the PreferenceScreen is displayed a new ListView is
created and bound to the adapter. As the same adapter is used during
the lifetime of PreferenceScreen and the listviews never gets
unbound, the adapter will contain a list of unused views. The old view
should be unbound from adapter when we create a new view.
Change-Id: I13e2d0dc79c8ff79b58efa650653e3f84c6e53c5
3362464 API REVIEW: android.content potpourri
3362445 API REVIEW: Fragment transaction stuff
3362428 API REVIEW: Fragment stuff
3362418 API REVIEW: Loader stuff
3362414 API REVIEW: android.content.pm.ActivityInfo
Change-Id: I6475421a4735759b458acb67df4380cc6234f147
Bug: 3184831
Copied holo layouts to *_holo.xml and restored the old layouts for
non-holo (pre-honeycomb) apps to use so that their layout assumptions
aren't messed up.
Change-Id: If4dcef16191a47a4b101da6bfb0c2df1757d1ae4
Bug: 3236568
This adds a way to insert a title as well as get a callback when that title is clicked.
It is not really on the backstack and clicks must be handled via the listener interface.
3257701 Preference headers have duplicated "title" and "summary" if
title is not loaded from a resource
3267312 Fragment.onConfigurationChanged doesn't get called
Change-Id: I76e346ba88aa632ebb9aa413a2ce2645ebf357cd
Change-Id: I37366c3465aa1d8d2bd30fb6ae4b821f5f2d5e2d
Additional changes to make the left and right padding
behave the same way as the top and bottom padding.
That is, our default pref screens will automatically
apply the padding and clipToPadding tags. Custom preference
screens will appear as before.
Uses LayoutParams now instead of a specific id.
n the case of any standard PreferenceFragment layout, we can
change the list styling to add padding and set clipToPadding to false.
In this case, we don't want extra padding in the parent ViewGroup
(R.id.prefs).
When an app specifies a custom preference fragment layout, we want
to add the previously existing padding styles R.id.prefs.
Change-Id: Idfd77dcbef264c6f5f4121b66fd54c684ad0a288
Add a new "icon" field to Preference for adding icons to the left of the preference title.
Several screens such as BluetoothSettings and Accounts have added their own custom preferences
just to add an icon to the left. This makes it simpler going forward.
launch a new fragment on the same call.
There were some problems with the API design where you could do
things in such a way that a back stack entry that was not at the
top would get popped. Ouch. Hopefully this change prevents that
from being able to happen.
Change-Id: I8cbc952e12ddd231ff6c84b6e9bbf5125f449f04
Addresses these bugs:
3061847 - With no headers, PreferenceActivity crashes
2888426 - minor typo in DevicePolicyManagerService.ActiveAdmin.writeToXml()
3159155 - IllegalStateException:"Can not perform this action after
onSaveInstanceState" while dismissing a DialogFragment
3155995 - PopupWindow.showAtLocation does not respect LayoutParams
Also tweak the new fragment APIs to use abstract classes instead of
interfaces as base classes.
Change-Id: I9c0b4337fe0e304b737b5f7c2762762372bb3020
Changed the preference dialog with text input to pan if
the display area is limited. This helps the user to see
the input better.
Change-Id: I12341546f6f82601ac5a2746153255a9b2d49a1c
Merge commit 'ca1db5ae68971779fd8af83c908128849f470ae0'
* commit 'ca1db5ae68971779fd8af83c908128849f470ae0':
Fallback to SharedPreferences$Editor.commit() when no apply() exists.
Merge commit 'dd644c179c1bf47d82d776d7f644e4fc1467159d' into gingerbread-plus-aosp
* commit 'dd644c179c1bf47d82d776d7f644e4fc1467159d':
Fallback to SharedPreferences$Editor.commit() when no apply() exists.
Gingerbread widened the SharedPreferences.Editor interface, adding an
apply() method. Most people don't implement this interface
themselves, but a couple apps do.
A few spots in the core framework take a SharedPreferences[.Editor]
from apps, which might be a pre-Gingerbread implementation without an
apply() method. This patch makes sure we never depend on the presence
of an apply() method, falling back to commit() if apply() isn't
available.
Change-Id: I32693ac9227a60b694526a26a30234fb17a40581
Adding a new concept of "next" and "previous" to fragment.s Previously, fragments would
either be placed onto or taken off of the stack, or would just replace the current
fragment. The new next/prev capability gives the ability to run a transition that is
specific to next/previous operations, such as navigating forward and backward in a list.
New next/prev animations may be associated with a fragment replace operation to get the
next/prev animations built into the system (next animates things up, prev animates them
down).
Change-Id: Ia9f3663bac009376420d845b396ac51b8e4d1647
Bug: 2988732
RingtonePreference was calling startActivityForResult on Activity instead
of on Fragment, so the result was not being delivered to the fragment.
Setting a fragment owner on the PreferenceManager instance so that it can
be used instead of getActivity() for launching the intent.
Not exposing any new public APIs at this time.
This adds a simple API to have your back stack automatically
shown as bread crumbs in the action bar. Introduces some APIs
to retrieve the current back stack.
Also fix a little bug in the "activated" state where it was
being propagated down the hierarchy as "selected". :p And from
that, fix the standard colors to be reasonable when in the
activated state.
Finally PreferenceActivity is updated to take advantage of
bread crumbs to show your place in the preferences.
Change-Id: I9d633bedf8d7c6e4ed9b25cb9698faa66c7dd9a4
Use this in ListView and GridView if the top view is not checkable.
This allows PreferenceActivity to now highlight the current heading
that is being shown.
Change-Id: I0d28aded9a61a42962b4aece420ae4058712d963
- Have PreferenceActivity save and restore its header state.
- Keep track of the current header selection.
- When headers are updated, try to retain the current header selection.
Also fix issue #2995541: Cannot add new contact. We were not allowing
fragment transactions in some cases.
Change-Id: I4aa4c703ed5f4ecf9f425cd7eeea4740c6360ce9
Fix issue #2975886: Make getTargetFragment() survive rotation events with
retained fragments. We now fix up the fragment pointer when restoring state.
Fix issue #2919928: In PreferenceFragment, addPreferencesFromResources() is
not effective when called after onActivityCreated(). Note to self: do not use
a what code of 0. Maybe that should be documented (I'll do it in gingerbread).
Hopefully implement #2992753: DialogFragment.dismiss will NPE if called too soon
(before attached to activity). We now keep track of the FragmentManager
separately from the activity, and set that as soon as the fragment is part of a
transaction.
Investigate issue #2988876: NPE when device orientation is changed. The NPE is
because of the app trying to do a fragment transaction in onPause(). This is
fundamentally not viable, since (a) the activity will be gone before we ever
have a chance to process the message to commit the transaction, and (b) even if
we did try to commit the transaction earlier, this would be done after
onSaveInstanceState() and thus not work in cases where the activity gets killed
in the background. So instead, we'll just throw an immediate exception if you
try to do this.
Change-Id: Iea62b50eb79f066af2471fce86836d073398f4f7
Also removes the artifical restriction that only one apply() can be in
flight at once. That was old from when I thought it'd end up being
required, but wasn't.
Change-Id: I3540ea8be6e0760d6a51d218186f71655c2f3f55
Adds a fire-and-forget save method (startCommit) to the
SharedPreferences.Editor, which is the way most people use it anyway.
This commit adds the implementation. The previous commit added the
interface and docs:
previous change: Idf9934b445da1fb72b79f0192218b47c0a7f5a34
git commit: edf32d0131
In addition, this change:
-- adds a generic "runPendingWorkFinishers" mechanism to
ActivityThread to wait on async operations that are still
in flight and use it for this.
-- ties runPendingWorkFinishers into Activity.onPause,
BroadcastReceiver, and Service.
-- makes sSharedPreferences keyed on name, not File, to avoid
unnnecessary allocations
-- documents and guarantees what thread
OnSharedPreferenceChangeListener callbacks run on
-- makes a few things in frameworks/base use startCommit(), notably
Preference.java (which was ignoring the return value anyway)
Change-Id: I1c8db60ad45643226fe6d246d3e513eeb7bd0ebd
