cef09fee2126f901aa164f6e89c370ab81cff1b3 |
|
13-May-2016 |
Adam Powell <adamp@google.com> |
Add Fragment#onAttachFragment for parent fragments Add a matching onAttachFragment method to Fragment to match the fragment host version. Bug 28760393 Change-Id: I1dbcc336e4f191717add0dc83d48db93baa953fa
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
fd15fbacc1d0cb92f2edf72137e4940be2547aa4 |
|
11-May-2016 |
Adam Powell <adamp@google.com> |
Less lazy child FragmentManager creation Fix a bug where child FragmentManagers moving too lazily into the CREATED state and beyond caused child fragments to not be attached/created when expected. Bug 25019275 Change-Id: Ia16f6d9075e6b611d3363ad1eac6408b896604bb
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
1802bf381380809e224c72008a400715e2e375b4 |
|
07-May-2016 |
Adam Powell <adamp@google.com> |
Fix Runnable/View leak from posting to detached views in FragmentManager The old Animation framework runs callbacks during View.draw(). During this, it's unsafe to change the layer type of that view, therefore an older bug fix began posting layer type changes as runnables to the view in question. This doesn't work well either, since that means it's too late to start using a hardware layer for animation (the first frame has been drawn and we'll likely jank the next in layer creation) and if the view is detached and we're on a non-Looper thread, prior to Android N we will post the runnable to a thread-local run queue that never gets flushed, leaking anything we've closed over like the view, its context, etc. Change FragmentManager to set layers for alpha animations before starting the animation rather than in the animation callback itself. Only post the change back to LAYER_TYPE_NONE if we're attached to a window or if we're running on at least N to avoid the bug. Otherwise, make the layer type change immediately since we're assured not to be running in a hwui drawing operation on the UI thread. Bug 28142337 Change-Id: I8819f55555cfb2b0b44a1f8a22c651429d4382fd
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
f7bdb2b37497128b8a9108eea43c17ea544c957a |
|
22-Apr-2016 |
Alan Viverette <alanv@google.com> |
Merge "Clean up deprecation tags in support libraries" into nyc-dev
|
d805095048f6be52cddbd572ee343c4639ba8187 |
|
22-Apr-2016 |
Alan Viverette <alanv@google.com> |
Clean up deprecation tags in support libraries Also fixes renderscript and recyclerview docs builds. Bug: 28339627 Bug: 28073702 Change-Id: I0f38cf82fe260de4488660c87aaed8d26265eeba
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
916455675ddb34d0eb848b2355550268d82c3ce7 |
|
21-Apr-2016 |
Adam Powell <adamp@google.com> |
Move child FragmentManager shutdown for retained fragments Support lib edition Some apps out there do some creative things in terms of calling their own onDetach methods from elsewhere. Perform the child FragmentManager shutdown for retained fragments in a package-level perform method instead of in onDetach itself. Also mark all existing fragment methods with @CallSuper. Bug 28293847 Change-Id: I5cad21589d1794034d0fd63aaf45dd2984d3c8cc
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
b054427688e7cf0475bec09da9a3fb7688881459 |
|
15-Apr-2016 |
Adam Powell <adamp@google.com> |
Retain loaders through stopped config changes Previously we would throw away any stopped LoaderManagers when we went to retain instances to pass along as nonConfigurationInstances during config changes or similar activity restarts. This causes loaders to do more work than they need to when a calling activity starts a new activity on top, a config change happens (e.g. screen rotation) and then the top activity is finished, restarting the caller in a new configuration. The loaders would go through onReset unnecessarily, potentially throwing away data to be reloaded again after the config change completes. Instead of throwing away stopped LoaderManagers in this case, restart them and retain them across the config change so they can resume where they left off. Bug 27176186 Change-Id: I6b589776fd19e0b88a1a00f6763fe8ea6d60db58
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
5fa6d3dd3f408ceb2ff7368fd0259713d9382ad8 |
|
30-Mar-2016 |
Andrii Kulian <akulian@google.com> |
Add PIP and MW mode change callbacks to support library Bug: 27365860 Change-Id: I903062d3e93882a2503cf080b9f4086c55cc2038
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
f29bf5eb0dee1c72f934b6fae8674c68cfec5d17 |
|
29-Mar-2016 |
George Mount <mount@google.com> |
Merge "Revert "Skip removing the Fragment's view if it is being animated."" into nyc-dev
|
8aa950177d9290b005f0817485f241ddc41c8026 |
|
28-Mar-2016 |
George Mount <mount@google.com> |
Revert "Skip removing the Fragment's view if it is being animated." This reverts commit 9d5a2665b76a1e87e1442d00ed699150ffbfb658. Bug 27700027 If a view is animating then it should go into the mDisappearingChildren list when it gets removed and when the animation completes, it should be removed automatically. This is related to the old animation framework and does not apply to Animators. Change-Id: I3c9a4fbbedcdb329461feda7946321357455c036
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
9375145b63d854c64aad99e6e50c5b7e5ba32b95 |
|
03-Mar-2016 |
Adam Powell <adamp@google.com> |
Fix bugs around restoring nested retained instance fragments In a few configurations the child fragment state of a retained-instance fragment would not be preserved correctly, leading to child fragments not being restored. Clean this up along with live state management issues that were leading to logged warnings during normal fragment operation. Bug 27371492 Bug 27477824 Change-Id: I6e86a7f0c158b7dea17b5c8d2b8275e3842b178b
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
1500716b2257e9f442606fe5bd992ab4e0198dcb |
|
02-Mar-2016 |
Adam Powell <adamp@google.com> |
Fragment docs for executePendingTransactions vs. commitNow Expand docs to suggest that users of FragmentManager#executePendingTransactions should prefer FragmentTransaction#commitNow in some circumstances. Bug 27365666 Change-Id: I24a5f94e84e4c97107341421b96bd7fc95c65888
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
95b47440a7a8417c7e4000c82bda81ed57279725 |
|
01-Mar-2016 |
George Mount <mount@google.com> |
Merge "Clear child fragment manager after it is destroyed." into nyc-dev
|
e880475b147312ca62bed05bbeb37ec820d693ae |
|
01-Mar-2016 |
Adam Powell <adamp@google.com> |
Correct state loss checking for FragmentTransaction.commitNow Booleans are hard Bug 27419920 Change-Id: If74b90c044dd8d446124b0258cc521f4a2db1804
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
36bd1e9880a74cc53edef99040bbb24fc1cad909 |
|
24-Feb-2016 |
Adam Powell <adamp@google.com> |
Protect FragmentManager against View.NO_ID container ids Not all code paths for FragmentManager were checking that the container view had a valid view id. As we can't correctly restore a fragment with a container without one, throw a more descriptive exception earlier. Update the FragmentPagerAdapter implementations to be even more descriptive if the host ViewPager does not have a view id and we would enter this case. Bug 27290033 Change-Id: I3e349ceaa82fbbd1f257554d9670e4c21f49ff4e
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
4706c089880423ee5929d4635c6dfc5c3151b20f |
|
17-Feb-2016 |
George Mount <mount@google.com> |
Clear child fragment manager after it is destroyed. Bug 26945643 After a child fragment manager has been destroyed, it should not be reused because it is no longer attached to the host. Clearing it ensures that it will be recreated when it is needed again when the fragment has been reattached. Change-Id: I579abf570beb62df3c3fd5ade3b74506f304b2aa
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
9d5a2665b76a1e87e1442d00ed699150ffbfb658 |
|
16-Sep-2014 |
Aurimas Liutikas <aurimas@google.com> |
Skip removing the Fragment's view if it is being animated. The animation is currently being canceled because the view is removed from its parent immediately after starting the animation, so the animation never plays. Likewise, the state never advances because the animation listener's onAnimationEnd() callback is not invoked. This change defers removal of the mAnimatingAway view until the animation finishes playing. Cherry-pick of https://android-review.googlesource.com/#/c/107740/ Change-Id: I0db9cee5a13580a8a92b6869f174a1ae2ae22c18
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
c077b4cd990a9f220a27ad5eca04828e17136064 |
|
14-Jan-2016 |
Adam Powell <adamp@google.com> |
Permit setRetainInstance(true) on nested fragments Save arbitrarily nested fragments across config changes as nonconfiguration objects. This permits the use of retain-instance child fragments as arbitrary opaque dependencies within other fragments. Change-Id: Id4f216bdc2ccbfba6410661626329f07b5015349
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
e1fad6fb0ee83d7f2dad3ec3dca6641a425e7244 |
|
13-Jan-2016 |
Adam Powell <adamp@google.com> |
FragmentTransaction.commitNow Offer commitNow and commitNowAllowingStateLoss methods on Fragment for use by encapsulated components using fragments as implementation details. This can help prevent unexpected ordering side effects at the app level when a call to a library method wants to commit and immediately initialize a fragment as an implementation detail. Note that this change still does not permit reentrant FragmentManager operations. It is still an error to add/remove/change fragments in the same FragmentManager while a fragment transaction is being executed. Have the commonly used ViewPager adapters use commitNow instead of executePendingTransactions. Change-Id: I386333899cf96c2496b084480d61063b857d8f43
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
20735a45289fdad3d5d31228992e0dccd3d5dd4f |
|
12-Jan-2016 |
Adam Powell <adamp@google.com> |
Eagerly update fragment state when moving between states Previously we would not set a fragment's new state until the move to a new target state was fully complete. This causes problems when other parts of the fragment manager infrastructure (such as lazily initializing a child fragment manager) read that state while we're dispatching a state change call to a fragment. In this situation, adding a child fragment and then calling executePendingTransactions on the child FragmentManager would not have the intended effect, as the child FragmentManager would still be in state INITIALIZING. The expected lifecycle callbacks to the child fragment would then occur later. Fix this by updating the fragment state as we go through each phase of moveToState before we dispatch to the associated onState method, matching our usual pattern of invoking onFoo methods after foo has occurred. Delete the redundant resumed field as we now can use the state directly. Bug 25019275 Change-Id: Ia637c4d67f3752e8dd591ed9a53a783690e41d80
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
c3af4b26a0e9e15a21c0a065ac3cfd2889a978bb |
|
20-Oct-2015 |
Todd Kennedy <toddke@google.com> |
Merge "Retain fragment loaders" into mnc-dr-dev am: f79417e198 am: 6415ff3a73 * commit '6415ff3a734ba86b41d49975a5d7eccc960030d1': Retain fragment loaders
|
f79417e198124e78457517ec69bf7a9f48c953ce |
|
20-Oct-2015 |
Todd Kennedy <toddke@google.com> |
Merge "Retain fragment loaders" into mnc-dr-dev
|
0f14e77f583e30fcab29269ef54790b31ba85dc4 |
|
20-Oct-2015 |
Todd Kennedy <toddke@google.com> |
Merge "Set host when restoring a fragment" into mnc-dr-dev am: f598a95930 am: 35151f7672 * commit '35151f76729a70b26f1fd0c573e3d71dc2d0d534': Set host when restoring a fragment
|
64ece2df3d6d789f7a642692acbe85fa1b998d6b |
|
20-Oct-2015 |
Todd Kennedy <toddke@google.com> |
Retain fragment loaders Remove the partial fix [it did not work for child fragment managers] and replace with a more general fix that works with all fragments. Bug: 23838271 Change-Id: Idf7decd64e344013df63359edd2d4268645eb99c
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
e4148d65bbd62585c68c5782c2081bab6b303568 |
|
19-Oct-2015 |
Todd Kennedy <toddke@google.com> |
Set host when restoring a fragment When we restore a fragment [i.e. on configuration change], we need to make sure the host is set prior to calling into lifecycle methods such as onInflate(). These use data contained within the host. Bug: 22512520 Change-Id: I54215ae7ea4b89d42cd443f7772fb6a5c5eafd55
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
b8d65fef161c7cd4bb06dc97685cf3fb3d6c3e1a |
|
02-Oct-2015 |
Chris Banes <chrisbanes@google.com> |
Fix support library build Change-Id: Icc9d67980d18f3db81bcb0e03f2bee5ecebf2c6c
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
410d77a6fbe42b0784cccd046bb8958caa723035 |
|
02-Oct-2015 |
Chris Banes <chrisbanes@google.com> |
Disable HW Layer handling in FragmentManager pre-KK BUG: 23889614 Change-Id: I9023602916a01c541ea2f51b740941316f0ea870
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
3cf5628b59b22551ca1578a27b09032b1f4c4e55 |
|
23-Sep-2015 |
Todd Kennedy <toddke@google.com> |
am 36be5c6a: am 6490e80e: Merge "save "retain loader" state" into mnc-dr-dev * commit '36be5c6adc664da215b490986b23ffd12459b97d': save "retain loader" state
|
641da2788e39dcbf17e99ae60c011500d6c5822d |
|
10-Sep-2015 |
Todd Kennedy <toddke@google.com> |
save "retain loader" state We cannot pull the "retain loader" state from the Activity; an Activity may not always be hosting a Fragment. Instead, save the "retain loader" state inside the individual fragments. Bug: 23838271 Change-Id: Ie5033be06e46488a1ecd6ee18433b1bd737be7f6
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
fa42920c65a4a11c2bae0cc8525e2f6d1d50da12 |
|
01-Sep-2015 |
Chris Banes <chrisbanes@google.com> |
am 7fe53f12: am e5579d82: am 1b84066e: Fix support Fragment attribute reading * commit '7fe53f126fe7eb8c28b3f4c8dccadaf99491c6ca': Fix support Fragment attribute reading
|
1b84066e4233b4b0c8a32fffc30f95b8cd20ced4 |
|
01-Sep-2015 |
Chris Banes <chrisbanes@google.com> |
Fix support Fragment attribute reading Caused by the fact that when onInflate() is called the host hasn't been set on the Fragment. This means that the older deprecated version on onInflate() isn't called. BUG: 23707068 Change-Id: Ie41e4f7dde03a01c278bb07d32bcc2a777e939bb
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
7e6e889eb9fdad71b015455ec9353359366f61d3 |
|
01-Sep-2015 |
Chris Banes <chrisbanes@google.com> |
resolved conflicts for merge of 1684b303 to mnc-ub-dev Change-Id: Icb32e8a3e1e01c3b6f3be9aeb745db616956227d
|
61401e37fd50cd0e3cbb9381d5f8d1295f3d7698 |
|
01-Sep-2015 |
Chris Banes <chrisbanes@google.com> |
Make sure we post setLayerType() calls from AnimationListeners Animation seems to dispatch it's listener callbacks in the main loop, which in this case is in View.draw(). This can leave View's paint in a wierd state and result in the crash. We now post the setLayerType() call avoiding the crash. BUG: 23659571 Change-Id: I0541425e08a6a471faf08e310763d869fd42cb3d
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
8e2338fcb97b64a78b8e10b7cf687950c09b948d |
|
26-Aug-2015 |
Chris Banes <chrisbanes@google.com> |
am 358765fc: am 12d9afd3: am 4776b6a9: Merge "Only use HW Layers for Fragments on JB+" into mnc-dev * commit '358765fcfde3209e75bfcaa2e1733e028c3d23aa': Only use HW Layers for Fragments on JB+
|
4a2d50d0a495f4ae568376d2d900feadd81d1acb |
|
26-Aug-2015 |
Chris Banes <chrisbanes@google.com> |
Only use HW Layers for Fragments on JB+ BUG: 23546223 Change-Id: Ia7bebc5fa1495475cda72d75521168fb657ff957
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
d02828a3781590e76fe86f2bf4ae8fbff4f5e2bd |
|
22-Aug-2015 |
Doris Liu <tianliu@google.com> |
Fix animation listener being replaced by HWLayer animation listener Previously, as an optimization, a custom animation listener is created in FragmentManager to put alpha animations on HW layer. Due to the limitation of the View.Animation, only one listener can be set on an Animation. As a result, this optimization caused user-defined animation listeners to be replaced by the custom animation listener. To fix this issue, the custom animation listener can now wrap around any user-defined listener, so that listener events can be sent first to our custom listener, and then to user-defined listener. Bug: 23404179 Change-Id: Id939178f24e900f8be8de088438c77978963ce25
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
03526560f132021f8fd7290259762ab362d4d567 |
|
28-May-2015 |
Doris Liu <tianliu@google.com> |
Support Lib: Set a HW layer for Fragment alpha animation Change-Id: I477c410f7b932e7a9d737f85fa33bef0ba7c02e8
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
21a621a996b79a9998a93561a96f1d66362d742e |
|
28-May-2015 |
Doris Liu <tianliu@google.com> |
Merge "Revert "Support Lib: Set a HW layer for Fragment alpha animation"" into mnc-dev
|
8bfc13aa27c414b549679a3f0418205851dc38c6 |
|
28-May-2015 |
Doris Liu <tianliu@google.com> |
Revert "Support Lib: Set a HW layer for Fragment alpha animation" This reverts commit 064fb71370836a8b16f021695127c043dca8c7c4. Change-Id: I25710f34646b2b6e0815e421ba4f8d7103a5bc29
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
43403817e33ddcd00a34cf50e53f6eb5f94f118f |
|
28-May-2015 |
Doris Liu <tianliu@google.com> |
Merge "Support Lib: Set a HW layer for Fragment alpha animation" into mnc-dev
|
064fb71370836a8b16f021695127c043dca8c7c4 |
|
13-May-2015 |
Doris Liu <tianliu@google.com> |
Support Lib: Set a HW layer for Fragment alpha animation This CL sets a HW layer for alpha animation to reduce the amount of overdraw. Bug: 8554227 Change-Id: Iae19ff370ed0e33614eeb520fe22aae98a0b89b1
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
b979cb86fa389effb7cd79fa045550c10b7b4819 |
|
04-May-2015 |
Todd Kennedy <toddke@google.com> |
Call Activity#onAttachFragment() This was accidentally removed during the changes to abstract a Fragment host. Bug: 20825263 Change-Id: Ib345606f8ba41ca5b1a1d3b3e6fa47d256fbb90b
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
8491eb62f621cd5de4b4caed839be09c77011f53 |
|
30-Apr-2015 |
Todd Kennedy <toddke@google.com> |
Sync API with platform While going through the main platform review, there were several changes to class and method names. Apply those changes to the support library to maintain parity with the platform. Bug: 19569096 Change-Id: Ibe36a664c40379665e3482f792220d975974abca
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
d608cf6e08769bf320c1b595cbbd9a7664160449 |
|
26-Mar-2015 |
Todd Kennedy <toddke@google.com> |
Remove dependency upon FragmentActivity The FragmentManagerImpl is intimately tied with a FragmentActivity. In many cases, we want to be able to create / manage Fragments outside of a FragmentManager. This defines a FragmentController interface that can be used by any class to host Fragments. Bug: 19569096 Change-Id: I62dee733a70577d0d3c8f96a89e4b05a3d5e18b0
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
bf0947be2ead9b3d8e5865bcd3d3652d02a2aa5a |
|
11-Mar-2015 |
Chris Banes <chrisbanes@google.com> |
Fix compat child fragment inflation Was caused by AppCompat using a Factory2, which trumps the Factory that FragmentManager was using. Fixed by making sure we use a Factory2. BUG: 19666640 Change-Id: I2f321da756a361ab7ed31aed65f0f8ce1f0d8bcd
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
0fb3ec354da6c1f3ed1777bca5270710cc537e92 |
|
14-Feb-2015 |
Scott Kennedy <skennedy@google.com> |
Mark findViewById(int) @Nullable Change-Id: I9dff1548dd1cd5f0ce69bec3a47a4153de034458
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
5e63ab9505a3a4d11374cbbec418c1aba921409d |
|
07-Oct-2014 |
Chris Banes <chrisbanes@google.com> |
Remove the intermediary ViewGroup for support-v4 fragments On Honeycomb and above the extra ViewGroup isn't needed as we can use setSaveFromParentEnabled() like the framework FragmentManager impl. BUG: 17901056 Change-Id: I7b3cb130943f8f0e9ab7c910f86f5d711bd42f7a
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
7516316ffdf6fbf7b248c615404831191daa66a4 |
|
18-Sep-2014 |
George Mount <mount@google.com> |
Fix exception when fragment container has no View. Bug 17535259 Change-Id: Ic58886e93557b8894d4754597889bd29476259de
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
9f4a046cbeb22a24d322a644323b41022ad9d15a |
|
02-Sep-2014 |
George Mount <mount@google.com> |
Change Fragment Transitions to match Activity Transitions API. Bug 17188255 Change-Id: I99897ba3c78f3f140000a719afbcfac951e43290
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
0f3dfb28a503b3fb3e51666dd565b0d17eaebfbb |
|
14-Jul-2014 |
Adam Powell <adamp@google.com> |
Port of nested fragments patch Nested fragments - fragments inflated from within another fragment - are now added to the containing fragment's child fragment manager instead of the Activity's fragment manager. Bug 12763389 Change-Id: I32b3322c9b6344c69f2fefc6e443b656b5f8fc5b
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
d9eb04dbc96599246581624c2c0e07b31eae3ca9 |
|
30-Jun-2014 |
George Mount <mount@google.com> |
Merge changes I7f18f9b9,Ic393edf3 * changes: Add support for shared elements in fragment transitions. Add support for ActivityTransitions.
|
8e4a59b54e9225b77151805dd6b8867dcd8e60a4 |
|
30-Jun-2014 |
Craig Mautner <cmautner@google.com> |
Restore saved state across config changes The saved state bundle was being saved but not restored. Normally this doesn't matter but some views (notably DialogPreference) was saving it's show/hide state and relaunching itself after a rotation based on what was in the bundle. Fixes bug 15559669. Change-Id: I06fc2f6bb4f96e1d17f7b35514de50f3e345fd89
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
4500be62dea3895a98336122a2944cc4ab024bc5 |
|
27-Jun-2014 |
George Mount <mount@google.com> |
Add support for shared elements in fragment transitions. Bug 15891071 Custom transitions in the Fragment Transaction have a higher priority than animations, transition style, or transition resource. If the API < 20, custom transitions will not be active and the other animation types will take effect. Change-Id: I7f18f9b9a75f73d58a16184a301458bdcd331098
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
e5f33a4c6bf77a3532c21062d636cdd69137f882 |
|
29-Apr-2014 |
Tor Norbye <tnorbye@google.com> |
am 5e8ef046: resolved conflicts for merge of a3ff3273 to klp-modular-dev * commit '5e8ef0460dfca1e3806b491fa886995baf0cfe9c': Add tools metadata annotations to the support library
|
5e8ef0460dfca1e3806b491fa886995baf0cfe9c |
|
29-Apr-2014 |
Tor Norbye <tnorbye@google.com> |
resolved conflicts for merge of a3ff3273 to klp-modular-dev Change-Id: Idc0fdf6c997ef63c14e4d8df417d1179cdcb1403
|
a3ff3273e976adf19770651dcf473fa67b38eb22 |
|
21-Mar-2014 |
Tor Norbye <tnorbye@google.com> |
Add tools metadata annotations to the support library Change-Id: I018ccee411da848e6ced91da316f86ae149dc218
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
fc039e9c51945dc1834b441a0f77c1bd531c898e |
|
28-Mar-2014 |
Chris Banes <chrisbanes@google.com> |
am 0b747a91: Merge "getParcelableArray* behaviour is sometimes unpredictable" * commit '0b747a91207b444a9e71fa7d2c0b93395720ccc7': getParcelableArray* behaviour is sometimes unpredictable
|
08ca9e8030eecfc473fa11ae8703d24014602803 |
|
10-Aug-2012 |
Steve Lhomme <slhomme@levelupstudio.com> |
getParcelableArray* behaviour is sometimes unpredictable in some case when the data in a savedInstance the Parcelable arrays stored by the application are not unparcel'ed correctly because the ClassLoader doesn't seem to be correct. The first getSparseParcelableArray() in the code is preceded by setClassLoader() by not the second one. The problem disappears when setClassLoader() is called in both cases. Change-Id: I2d2f42c285d9130fd543c0154e9d210d430823e3
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
6252d78085a07c9d6bb4645a4e8086bf23b0a49a |
|
28-Feb-2014 |
Tim Kilbourn <tkilbourn@google.com> |
Clear child FragmentManagers when destroying Fragments. If Fragment has instantiated a child FragmentManager and is later detached, it retains its reference to the child FragmentManager which has been destroyed. This causes an IllegalStateException in the child FragmentManager if the original Fragment is reattached. Fixes Issue 42601. Change-Id: I62155a535948a73bbbc09aefc2b15cfad58b9233
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
507f40fc4664a9e54967cedbd40b8065241c200d |
|
14-Jan-2014 |
Tony Mantler <nicoya@google.com> |
am 01df7377: Add isDestroyed() method to match framework API * commit '01df737703cceecc6b3a319ca0ee0bd64415f1cf': Add isDestroyed() method to match framework API
|
01df737703cceecc6b3a319ca0ee0bd64415f1cf |
|
14-Jan-2014 |
Tony Mantler <nicoya@google.com> |
Add isDestroyed() method to match framework API Change-Id: Ic69cb122f23d42223e4b841d7fe160911925124b
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
f6ae58d91853ad12b3a2153e6acc3f36730ed314 |
|
01-Oct-2013 |
Romain Guy <romainguy@android.com> |
am c8d671f6: am 37e2defc: Merge "Fragement, or Fragment: that is the question" * commit 'c8d671f68b7926e70f30c7ae96a579460a5daba1': Fragement, or Fragment: that is the question
|
c8d671f68b7926e70f30c7ae96a579460a5daba1 |
|
01-Oct-2013 |
Romain Guy <romainguy@android.com> |
am 37e2defc: Merge "Fragement, or Fragment: that is the question" * commit '37e2defcdb38fee7acec85747fb8afdcb0fdca7f': Fragement, or Fragment: that is the question
|
2b336307cf98ca5142db6736812178293d47c500 |
|
01-Oct-2013 |
Cyril Mottier <cyrilmottier@gmail.com> |
Fragement, or Fragment: that is the question Change-Id: I6fde7683cb83eecf96380d38fc588679d1ed1002
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
ab6e5dbcc6e05994ebb4257478c54f54085b9aa6 |
|
14-Aug-2013 |
Alan Viverette <alanv@google.com> |
Throw exception in FragmentManager when queuing after destroy Change-Id: If1efc037e543e98740ca3a5cabcc9f8081827e5a
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
80f8f434f1a5ee950084d8aedd70135de281df72 |
|
18-Jul-2013 |
Scott Main <smain@google.com> |
am 3cf73a41: am 9dcd2e58: javadoc edits for support library * commit '3cf73a4119b9b216ea22f796364ed00525ceac41': javadoc edits for support library
|
3cf73a4119b9b216ea22f796364ed00525ceac41 |
|
18-Jul-2013 |
Scott Main <smain@google.com> |
am 9dcd2e58: javadoc edits for support library * commit '9dcd2e58138ca4eb4b18f80b50e8979329e859d6': javadoc edits for support library
|
9dcd2e58138ca4eb4b18f80b50e8979329e859d6 |
|
17-Jul-2013 |
Scott Main <smain@google.com> |
javadoc edits for support library Change-Id: Ie8f228036dc9d33315430490a2e03e9c504ada71
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
67cae30c5e557e6e1a66dfd761077f77d87b9fec |
|
07-Jun-2013 |
Adam Powell <adamp@android.com> |
am 018ec423: am b036748c: am ab996046: Merge "Fix fragment flickering on hiding (support library)" * commit '018ec423c981c18d1fa4a8ccf3a3883c18aae7a1': Fix fragment flickering on hiding (support library)
|
b036748c3e21460cea4e714dfe55f047f3e0ea87 |
|
07-Jun-2013 |
Adam Powell <adamp@android.com> |
am ab996046: Merge "Fix fragment flickering on hiding (support library)" * commit 'ab996046e6b317d9744d1ba20bfbdede9ba0f5bb': Fix fragment flickering on hiding (support library)
|
495efcad8c8865e3e6f14e4ea3d79cfb1d2410f9 |
|
06-Jun-2013 |
Alexander Mironov <alexander.mironoff@gmail.com> |
Fix fragment flickering on hiding (support library) The "loadAnimation" method inside of the "hideFragment" method was called with "enter" argument set to "true". That's clearly a mistake. There is entry for this bug in issue tracker (http://code.google.com/p/android/issues/detail?id=32405) Change-Id: I826c7c668f223dbf1b3fbd0b82f7084c5657649c
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
9a0f25eee531f318d03d619403223637c353689c |
|
23-Apr-2013 |
Jeff Brown <jeffbrown@google.com> |
am f931434d: am 6d25d4c0: Merge "appcompat: Add plumbing for fragment options menus." into jb-mr2-dev * commit 'f931434d9443c29cc283c51a73a362902185795e': appcompat: Add plumbing for fragment options menus.
|
3a1a7fff9873abbf8097c96f7654a459bf34f223 |
|
19-Apr-2013 |
Jeff Brown <jeffbrown@google.com> |
appcompat: Add plumbing for fragment options menus. We make the callbacks available through an interface so that developers can implement them on any fragment without having to subclass ActionBarFragment. The plumbing is mainly transparent to v4 support although we needed access to a few properties. Bug: 8661191 Change-Id: I1abce746b7b8443efd406a3e1a4b92c948c678db
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
5565f83a45955399ab158c58de34f53460dc614d |
|
21-Mar-2013 |
Jeff Brown <jeffbrown@google.com> |
resolved conflicts for merge of ac1777e1 to master Change-Id: I76faee11167913299d6e5ce91de250c8712a76d6
|
da10fdd1400ecfd8d7f2e55651dd528d0614dfc5 |
|
19-Mar-2013 |
Jeff Brown <jeffbrown@google.com> |
Move appcompat library to v7 package. Moved most of the options menu related functionality out of v4 support lib into appcompat where it belongs. These two libraries have very different design philosophies and it is important that they remain untangled. The support action bar options menu is broken by this change but will be fixed in later patches after some refactoring to more fully express the facade-like nature of the appcompat library. Collapsed the appcompat eclair, honeycomb and ics folders into one src folder because the layering did not make any sense. All of these folders were providing portions of the API. The layering will be reconstructed and improved in later patches. Moved implementation types into an internal package within appcompat to prevent them from leaking into the API. Changed the base package name to android.support.v7, similar to the gridlayout support lib. Bug: 8175766 Change-Id: I538cbe08310e63e96a2a9fed0b8636eeda530f2c
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
e0f27d39b0a4f0ef30ef6446e7b675279961cc94 |
|
28-Feb-2013 |
Chris Banes <chrisbanes@google.com> |
Move support Menu interfaces + callbacks to v4 (DO NOT MERGE) This moves the Menu* interfaces used for the ActionBar into android-support-v4. This allows us to remove ActionBarFragment and related hackery. This commit just keeps us at the same level of functionality, but is a cleaner implementation. A future feature would be to enable the use of the support Menu when not using ActionBarActivity. Change-Id: I952ce78a378e8ec3b990f5c285a44c7fc4807f0c Signed-off-by: Chris Banes <chrisbanes@google.com>
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
5f1309fe533f644638155e79d50e23060191bf59 |
|
20-Feb-2013 |
Chris Banes <chrisbanes@google.com> |
Propogate support menu callbacks to Fragments (DO NOT MERGE) This commit adds a new Fragment subtype which contains versions of the support menu calls. A number of changes to ActionBarActivity have been needed to make this possible: - ActionBarActivity and related classes have been moved to the android.support.v4.app package. - FragmentManagerImpl instance creation has been moved to a method in both FragmentActivity and Fragment, so that we can return a new sub-type: SupportMenuFragmentManager - FragmentManagerImpl is no longer final - The compat ActionBar menu set up has been changed so that it happens in onPostCreate. This is so that any fragments can be added in onCreate. Change-Id: I591ca163762431cae9a4988cd89e0711d6b5ff21
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
c1e87ac17c772ee3c5fd3b3f08321226e2c7ffa4 |
|
01-Mar-2013 |
Chris Banes <chrisbanes@google.com> |
Fix NPE when using support menu with Fragment This should have been included in change: I3de7695d4db0b9626f2bc9ed49ad0528146dc093 but it seems to have been missed. Change-Id: I76be4eb4f327bed6f9cb9a3ef8b1370d841bab2f Signed-off-by: Chris Banes <chrisbanes@google.com>
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
461b48b4588ac21b97aa40553f04222c2c0344e7 |
|
28-Feb-2013 |
Chris Banes <chrisbanes@google.com> |
Move support Menu interfaces + callbacks to v4 This moves the Menu* interfaces used for the ActionBar into android-support-v4. This allows us to remove ActionBarFragment and related hackery. This commit just keeps us at the same level of functionality, but is a cleaner implementation. A future feature would be to enable the use of the support Menu when not using ActionBarActivity. Change-Id: I3de7695d4db0b9626f2bc9ed49ad0528146dc093 Signed-off-by: Chris Banes <chrisbanes@google.com>
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
ffe0b0cac90bf1f7cc8b5e4adca9364ca9adc7a4 |
|
20-Feb-2013 |
Chris Banes <chrisbanes@google.com> |
Propogate support menu callbacks to Fragments This commit adds a new Fragment subtype which contains versions of the support menu calls. A number of changes to ActionBarActivity have been needed to make this possible: - ActionBarActivity and related classes have been moved to the android.support.v4.app package. - FragmentManagerImpl instance creation has been moved to a method in both FragmentActivity and Fragment, so that we can return a new sub-type: SupportMenuFragmentManager - FragmentManagerImpl is no longer final - The compat ActionBar menu set up has been changed so that it happens in onPostCreate. This is so that any fragments can be added in onCreate. Change-Id: Iad4cb121ed99780ea6f207991bd65c2be4b6d69b
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
3a7571011a8f2c2e2685c4e3e7a6fa46673ee7ea |
|
27-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #7232641: ISE crash when rotating phone in label list mode This doesn't fix the problem; I think it is an app problem. It does improve a bunch of the debugging to help better identify what is going on, and introduces some checks when adding a fragment to fail immediately if we are getting into a state when a fragment is going to be in the added list multiple times (which is pretty much guaranteed to lead to a failure at some point in the future). Change-Id: Idac978eb6bd2bd38d54e50532907c40b264ac300
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
74c671b3b67000bf16b4865a8d361344310dccbe |
|
26-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix how fragment/tab interaction works to avoid list view state loss. The implementation of FragmentTabHost would cause us to toggle between the default and selected tab fragments when restoring our state. Because of an issue in ListView (fixed by another change), this would cause us to lose the state because ListView tripped over itself if you asked it to save its state immediately after restoring it. We are now more careful about switching fragments, so we don't run in to this problem at least in most cases. Also pull over framework change to not let inactive fragments be more than CREATED. Bug #7232088: ListView saved state being lost in some cases Change-Id: Id9f20c207409d2479ff8bce8ed5b0553510cdd63
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
0adacc1aa313d757ae1c517152cef838e0f35c13 |
|
09-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Nested fragments. Change-Id: I2cfd30fda55320796c8eec738f5b9b592ea2c29c
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
13fb2b96fa8464e7b8514c57e1ad5ea782b3a52c |
|
18-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Improved fragment manager debugging. Now dump the activity state for every exception thrown where this may be of interest. FragmentActivity now dumps a summary of its view hierarchy state. Change-Id: Id34509cac3912a78c0e9d35e2b72a8b2779ea336
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
ec9fb2522d42d1ff73ddffa12b318d925c10ab18 |
|
15-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Add more debug info when a container view ID can't be found. Change-Id: Ifbeefdbf13c941dd5d051f25d9f47a43c76738f3
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
464b6f3c93dda03359ec2d37c8205065922f2994 |
|
20-Jun-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #6675499: java.lang.RuntimeException: Unable to start... ...activity ComponentInfo{com.google.android.gm/ com.google.android.gm.ui.MailActivityGmail}: java.lang.NullPointerException There were a number of places in FragmentManagerImpl where we were not dealing with mAdded being null. In the original implementation, mAdded would almost always be null if mActive is null. As we have added features, this has become a less strong guarantee (and it actually was never completely guaranteed), but there are a lot of places where we would check for mActive being non-null and assume this meant mAdded is non-null. Fix these to correctly check for mAdded. Bug: 6675499 Change-Id: I9d8284a1e1dd88fb9a6b75ddd9afac79e344fff3
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
5506618c80a292ac275d8b0c1046b446c7f58836 |
|
05-Jun-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #6584942 IllegalStateException: Failure saving state... ...active SuggestFragment{419494f0} has cleared index: -1 There were issues when the same fragment was removed and then added again before completely finishing the remove (such as due to a running animation). Two fixes: - Now when you call FragmentTransaction.replace() and are replacing a fragment with the same fragment, this becomes a no-op, to avoid visual artifacts in the transition and bad states. - When we are moving the fragment state up and it is currently animating away to the INITIALIZED state, we could end up making the fragment inactive as part of the cleanup. In this case it shouldn't be made inactive; we just need to initialize it but keep it active since we are going to continue to use it. Bug: 6584942 Change-Id: I4c37a8e48b115feb0892ef0eb92316d7aeba7b1b
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
1b913519b1c03b084779851e81db2e1a11eb0b0d |
|
31-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Working on issue #6561352: java.lang.RuntimeException: Unable to start... ...activity ComponentInfo{com.google.android.googlequicksearchbox /com.google.android.googlequicksearchbox.SearchActivity} Add check for a situation where we are saving the state of a fragment with a -1 index, and fail early in that case with more debug information. Change-Id: I175b2d5a1f47934497f28dd3a2d95b3351159743
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
be2c79d9a5439922030d2a3846c81c61f0e16912 |
|
16-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Follow changes in framework. Change-Id: I424a6e8f4b8b50d421c56bb018beab1063ba2cef
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
271504dbdf494dc87a2a96ff5d108c75a3389143 |
|
19-Apr-2012 |
Christopher Tate <ctate@android.com> |
Merge "Do not dispatch context selection events to non-visible fragments."
|
f4c0cf637ba73374a206cec26c09d4dfa4c1a364 |
|
19-Jan-2012 |
Jake Wharton <jakewharton@gmail.com> |
Fix potential NPE when saving fragment state. If a fragment's saved view state is null and the user visible hint is true then the `result` bundle will have never been initialized to a value resulting in a `NullPointerException`. Change-Id: I8ba585bc6b9298841490d64bc22a8219cd261adb
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
3af7ac0c50606fabc975b5f2b8576cfe3212d65d |
|
19-Jan-2012 |
Jake Wharton <jakewharton@gmail.com> |
Do not dispatch context selection events to non-visible fragments. When used in a `ViewPager`, fragments that are present on the adjacent, cached pages will receive context selection dispatches which, depending on your fragment contents, can be difficult to determine whether or not the event truly originated from your view. By using the visible hint we restrict dispatching to only those fragments which are marked as being visible. Since the fragment pager adapter updates this setting properly most implementations will be afforded this fix without any change required. If the user is implementing their own adapter they likely already understand the implications of these cached fragments and the reponsibility for updating the boolean falls to them. Change-Id: Ie6a72c1c82c2784774373670007b6f5948fe16da
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
79398eaefea45e61d839cf4e0534f0eafee70a09 |
|
07-Nov-2011 |
Adam Powell <adamp@google.com> |
Change the "start deferred" fragment API to "user visible hint" - Support lib edition Allow a fragment to set a hint of whether or not it is currently user visible. This will be used implicitly to defer the start of fragments that are not user visible until the loaders for visible fragments have run. This hint defaults to true. Modify FragmentPagerAdapter to use the new APIs both in frameworks/base and here. Change-Id: Idb5bce8a9ddf484186942555cd3c581d833eba7c
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
6cafd27a3c89dfed10d7e226dc6168307513d4a6 |
|
02-Nov-2011 |
Adam Powell <adamp@google.com> |
Fix bug 5557267 - [ViewPager] non-primary fragments unnecessary stopped if "defer start" is enabled Only revise the target state in moveToState if it would cross the stopped/started boundary. Change-Id: I7d0ad66668729ee12c43dcf1635b270a7d0a48b7
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
1199ae7067cdf8cf3eb30c057a61ae71a0aea1e5 |
|
31-Oct-2011 |
Adam Powell <adamp@google.com> |
Bug 5535639 - Monkeys mad at FragmentManager Also check for starting deferred start fragments when a loader is destroyed. Change-Id: I58c80708f96afa2943ca1e2cae077f7ac52a064d
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
abc968f1eba800c34a4008deb43b015da5d23a5f |
|
26-Oct-2011 |
Adam Powell <adamp@google.com> |
Defer starting fragments in FragmentPagerAdapter for offscreen pages. Add FragmentCompatICSMR1 to work with deferring fragment starts. Fix some slightly dodgy layout behavior in ViewPager when extra child views are present. Add deferred start feature to support library fragment/loader framework. Change-Id: Ied454a6f3e11024eafc970ed9d091788c2d80bab
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
218c1e661578e2a17928f7dbb590b43d1c79aeb7 |
|
02-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5238823, #5100340 and #5249654. 5238823: java.lang.NullPointerException at... ...android.support.v4.view.ViewPager.pageRight(ViewPager.java:1335) 5100340 Leaking reallyStopped in FragmentActivity 5249654 ViewPager resets focus on layout when descendant of... ...fragment.getView() is focusable (FragmentPagerAdapter bug) Also there was a bug in the "really stopped" thing that was previously introduced -- fragments wouldn't stop their loaders until hitting that state, but they wouldn't go into that state if the fragment was deactivated or put on the back stack without the containing activity really stopping. To fix this, we now implement the really stop facility as an actual state, using the ACTIVITY_CREATED state, so that we can know when to do the really stop for both cases. Change-Id: Ia9bd55f41ad30c3ce07f99b6ac6d9113b15fe46d
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
2a4d8518f36346ea25a22a736453ff28f2954165 |
|
30-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issues 5158104 and 4981556 (fragment problems) 5158104: com.android.contacts: java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState at android.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:1201) The ViewPager can just commit without worrying about a state loss, since it can correctly reconstruct its state later. 4981556: Fragment.mImmediateActivity doesn't get restored on orientation change I am giving up on this thing; I just don't see how it can actually be correct. So now instead of getting an exception about a dup add/remove at point of the add/remove call, this will happen later when processing the transaction. Also add an API for controlling the visibility of menus, which ViewPager uses to have the correct menus shows. And add a method to get the name of a back stack entry. Finally fix a recent problem in ViewPager with dealing with focus, and make ViewPager smart about handling keyboard focus navigation inside itself. Change-Id: I280269ac64079d171e9c899ea1cff7e80246c924
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
4e6647fe2551985f33407acd712a4942b090207a |
|
08-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Clear saved state after it is no longer needed. Change-Id: I1b452808f53758e2bf1cbf97a32d870280a14bba
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
e8b402b00c0cbdac050c349a5fc89c34580f3185 |
|
22-Jul-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5054723: java.lang.NullPointerException at... ...android.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:1284) Make sure to commit all pending actions before completing the destroy. Change-Id: I9e88cbfef5f96d63876023b897b44b8999aa8042
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
9f491519261135d9de50b60c2182755ccb665bf5 |
|
17-Jul-2011 |
Jeff Sharkey <jsharkey@android.com> |
Release strong Fragment references after exec. When finished with a Runnable transaction in execPendingActions(), release the strong reference so that Fragment can be GC'ed. Bug: 3117761 Change-Id: I6b546eeaa8e4783009ae27f2bab5ccecb28337fb
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
2c4b5dbfee5232bcbbcb74b84ce9147b62a9d789 |
|
15-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
Merge in fixes from main platform. Change-Id: I8e63b6990022869aa033d4672018d6585355bf76
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
9c53b844bd525e6a04e17291efc38713893074cd |
|
13-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
Update to follow fixes from platform. Change-Id: I9918b084426c62a60581e3ac6e69a48e51b7cc9b
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
5c1637087453de15e31861f073eae5133c4e9f7b |
|
06-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
Move PagerView down to the v4 support lib. Adds in standard adapters for using PagerView with the fragment support library. Also bring in the most recent HC fragment API and impl changes so that the support lib matches it. Change-Id: Id8a590378b8c544a92df4f3c11af323c930aa5fd
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
ea2c91b0198855073983b4a8437aa71cbd83872f |
|
03-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
New super-spiffier ViewPager class. Replaces FragmentPager. But spiffier. Like I said. Change-Id: I8a61a2bb613c8efcb95bf458e968e4a35d156491
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
715a71e5f73cbc33f307cbd3625db8f889a05c1a |
|
20-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
DO NOT MERGE: From master -- Remove some white space. Change-Id: Ibbcf5400fb7b521c7737fcca98e5b2c86e267fe7
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
e4417c91a0bb2fba42a0aaa99edcca1b238af21a |
|
05-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
DO NOT MERGE. Integrate support work from master. First submit of FragmentPager class. This provides an easy way to build a UI where the user can swipe left or right through its elements. The elements are implemented as fragments, and the class takes care of managing those fragments as the user navigates through it. This implementation also introduces a new FragmentManager concept of a "detached" fragment -- basically a way for you to put a fragment in the same state as when it is on the back stack, where the framework is managing its current state but it is no longer actively running. Also required the introduction of new compatibility code for MotionEvent and VelocityTracker for accessing multi-touch data. Tweak view save/restore state so it will play well with list views. We need to restore the state *after* the adapter has been set; setting the adapter clears the state. To do this, we move the state restore from immediately after the view is created to after we call Fragment.onActivityAttached(). Also introduced a new Fragment.onViewCreated() callback which is nice for fragments that want to do some setup after onCreateView() but allow for subclasses to override that method. (ListFragment I'm looking at you.)
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
3137d1472f1de9eac2e9a5dbe5b8d91282b24e66 |
|
10-Mar-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #4081614: Fragment.onActivityResult() broken in support lib Change-Id: Ie21b8e63b3bf8bf7ed75a68604c7d352f9402e07
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
9277b9e4419c1f0b5236d9b573a7cc0b23d56402 |
|
09-Mar-2011 |
Dianne Hackborn <hackbod@google.com> |
Implement fragment animations. I forgot to finish the implementation of this in the support library. Currently the standard animations are very hard-coded to look the same as HC. Also bring over my MR1 fix to onInflate(). Change-Id: Ib584e158bb691986d912aea5fd3004b8b2da7a6a
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
681a6fb06bdedb8661a68a1b9e34727b6059aa39 |
|
14-Feb-2011 |
Dianne Hackborn <hackbod@google.com> |
Finish remaining key implementation. Change-Id: Idb10f45bc109e57966dd2abdf446e60c5fd32aec
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|
cba2e2c881e8e16ea5025b564c94320174d65f01 |
|
08-Feb-2011 |
Dianne Hackborn <hackbod@google.com> |
First checkin! Change-Id: Ib09737c48a144dd778efe4750452d74ac8265a29
/frameworks/support/v4/java/android/support/v4/app/FragmentManager.java
|