summaryrefslogtreecommitdiffstats
path: root/core/java/android/app/FragmentManager.java
Commit message (Collapse)AuthorAgeFilesLines
* Fix incorrect fragment animation used for hiding fragmentsAdam Powell2013-06-101-1/+1
| | | | | | | | | | Mirror of support lib patch https://android-review.googlesource.com/#/c/60032/ into frameworks/base. AOSP Commit: https://android-review.googlesource.com/#/c/60167/ Change-Id: I8d1cb2e217721336674b8e3e2ef8722a8d9baefd
* Fix issue #7273573: Need API to find out if activity is destroyedDianne Hackborn2012-10-021-0/+11
| | | | | | Also update 17.txt with all of the recent API additions. Change-Id: I21fc669267935261a741c19e22b0bf35c3a76b81
* Work on issue #7232641: ISE crash when rotating phone in label list modeDianne Hackborn2012-09-271-8/+32
| | | | | | | | | | | 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: If3a8700763facd61c4505c6ff872ae66875afc8d
* Fix AbsListView to correctly retain its state if not layed out.Dianne Hackborn2012-09-251-1/+1
| | | | | | | | | | | | | This covers a hole where if the list view restores its state and then is asked to save its state before its layout happens, the original state is lost. Instead we just store that original state. Also tweak FragmentManager to make sure an inactive fragment can not have its state moved up out of CREATED. Bug #7232088: ListView saved state being lost in some cases Change-Id: I5b40f37c259c7bcbe17dd1330016f9531f1b5534
* A little cleanup.Dianne Hackborn2012-09-091-7/+9
| | | | Change-Id: Ie33fd1b02011606e67ce08df3cce887c07680c60
* Nested fragments.Dianne Hackborn2012-09-061-79/+68
| | | | Change-Id: I79acc19b391352c16b06afee2ca543223c38e364
* More view hierarchy, fragment debugging.Dianne Hackborn2012-08-171-107/+36
| | | | | | | | | | | | | | | | Add a View.toString() method. Rename all of the View private flags to have a PFLAG prefix to avoid going insane trying to figure out which constant goes with which flag. Activity.dump() now includes a summary of the activity's view hierarchy, using the View.toString() method. All exceptions thrown by FragmentManager now perform a dump of the owning activity state, where appropriate. Change-Id: I6482e397e10cb5a0612ab02ce6ed5131823437a6
* Add more debug info when a container view ID can't be found.Dianne Hackborn2012-08-151-3/+90
| | | | Change-Id: Ibb2afc49747bd2d0ac24605cb3ec390334f8abf8
* Remove debugging for b6829431.Craig Mautner2012-08-011-8/+5
| | | | Change-Id: If7da858722d5d0a5e7db2bc249d454bdee1ec94e
* Add debug to help with b6829431.Craig Mautner2012-07-201-1/+8
| | | | Change-Id: Id65f5c7c187072f5a5c1418c83e06c4a6767c658
* am cb1c45ed: am b6ce1f31: Merge "Fix issue #6675499: ↵Dianne Hackborn2012-06-201-12/+23
|\ | | | | | | | | | | | | java.lang.RuntimeException: Unable to start..." into jb-dev * commit 'cb1c45ed80df368051368a478fa931d3333c99f6': Fix issue #6675499: java.lang.RuntimeException: Unable to start...
| * Fix issue #6675499: java.lang.RuntimeException: Unable to start...Dianne Hackborn2012-06-191-12/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...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: I2a6a801d8bc89550fc73e12c9c3f8bb0ad6c7fa4
* | am 4a683a34: am 1ad66b2f: Merge "Fix issue #6584942 IllegalStateException: ↵Dianne Hackborn2012-06-051-14/+17
|\ \ | |/ | | | | | | | | | | Failure saving state..." into jb-dev * commit '4a683a343083ec2b8aed1ee63669dbade6c0379f': Fix issue #6584942 IllegalStateException: Failure saving state...
| * Fix issue #6584942 IllegalStateException: Failure saving state...Dianne Hackborn2012-06-051-14/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...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: I8bfd73f2d8ef8f67b541b3e2525dfa5db6c3bfa5
* | am 11855f31: am 388d4801: Merge "Working on issue #6561352: ↵Dianne Hackborn2012-05-301-1/+18
|\ \ | |/ | | | | | | | | | | java.lang.RuntimeException: Unable to start..." into jb-dev * commit '11855f31a3f7074d9fbccd1ee460b99fc47162c6': Working on issue #6561352: java.lang.RuntimeException: Unable to start...
| * Working on issue #6561352: java.lang.RuntimeException: Unable to start...Dianne Hackborn2012-05-301-1/+18
| | | | | | | | | | | | | | | | | | | | | | ...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: I03a928dde521fa06664d0036dd9f90eef3247afc
* | am b4652172: am bea7afc5: Merge "Fix issue #6284404: ↵Dianne Hackborn2012-05-151-1/+3
|\ \ | |/ | | | | | | | | | | ArrayIndexOutOfBoundsException in..." into jb-dev * commit 'b4652172404643d0a8fffbcc315cddcc733ec5ba': Fix issue #6284404: ArrayIndexOutOfBoundsException in...
| * Fix issue #6284404: ArrayIndexOutOfBoundsException in...Dianne Hackborn2012-05-151-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...FragmentManagerImpl.restoreAllState This was a bug related to the difference between the pre- and post-HC behavior of onSaveInstanceState(). Prior to HC, state was saved before calling onPause(). Starting with HC, it is saved between onPause() and onStop(). To maintain compatibility with existing applications, there is a check in ActivityThread for pre-HC to in that case emulate the behavior of old applications, still calling onSaveInstanceState() before onPause() but using the state later. One of the special cases we had to deal with in the old model of saving state before pausing was restarting an activity that is already paused. Consider, for example: you have two activities on screen, the one on top not fullscreen so you can see the one behind. The top activity is resumed, the behind activity is paused. In the pre-HC world, the behind activity would have already had its state saved. Now you rotate the screen, and we need to restart the activities. We need to destroy the behind activity and create a new instance, but the new instance has to end up in the paused state. To accompish this, we restart it with a flag saying that it should end up paused. For the pre-HC world, since it ends up paused, we need to make sure we still have its instance state kept around in case we need it because we can't regenerate it (since it is already paused). So that is what the changed code here is doing. It goes through the normal create/start/resume steps, but holds on to the current saved state so that it isn't lost when resume clears it, and then puts the activity back to paused and stuffs that old saved state back in to it. The problem is that this code was doing it for every application, even HC apps. So we end up in a bad state, when a HC app has its saved state sitting there as if it had been saved, even though it is only paused. Now if we go to restart the activity again, instead of asking it for a new saved state (as we should for a HC app as part of stopping it), we just re-use the existing saved state again. Now this wouldn't generally be a huge problem. Worst case, when we restart the activity yet again we are just instantiating it from the same saved state as we used last time, dropping whatever changes may have happened in-between. Who cares? All it has been doing is sitting there in the background, visible to the user, but not something they can interact with. If the activity made changes to its fragments, those changes will be lost, and we will restore it from the older state. However... if one of those fragements is a retained fragment, this will *not* appear in the saved state, but actually be retained across each activity instance. And now we have a problem: if the retained fragments are changed during this time, the next activity instance will be created from the most recent state for the retained fragments, but the older state for everyting else. If these are inconsistent... wham, dead app. To fix this, just don't keep the saved state for HC apps. Also includes a small optimization to ActivityStack to not push the home screen to the front redundantly. Change-Id: Ic3900b12940de25cdd7c5fb9a2a28fb1f4c6cd1a
| * DO NOT MERGE. Do not dispatch context selection events to non-visible fragments.Jake Wharton2012-04-251-1/+1
|/ | | | | | | | | | | | | | | | | | | | 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. Mirrors support library change Ie6a72c1c82c2784774373670007b6f5948fe16da Integrated from AOSP. Change-Id: I19bbbe4c8d910fb38c14d6ae5d462eb7dd44fd26
* Fix potential NPE when saving fragment state.Jake Wharton2012-04-231-0/+3
| | | | | | | | | | | 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`. Mirrors support library change I8ba585bc6b9298841490d64bc22a8219cd261adb. Change-Id: Iabd5ac293d2ece3771da9ef257479eca0dcd523c
* SDK only: now that support lib is in SDK, we can link to it.Dianne Hackborn2011-12-121-0/+7
| | | | | | | | | | | Update some of the platform documentation to directly link to relevent support lib docs. Yay! Also improve BroadcastReceiver documentation to more clearly discussion security around receivers, and how the support lib's LocalBroadcastManager can help. Change-Id: I563c7516d5fbf91ab884c86bc411aff726249e42
* Change the "start deferred" fragment API to "user visible hint"Adam Powell2011-11-071-2/+36
| | | | | | | | | 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. Change-Id: Id1349d319886a277ef07301f64f7b9e12c8729bf
* Fix bug 5557267 - [ViewPager] non-primary fragments unnecessaryAdam Powell2011-11-021-2/+3
| | | | | | | | | stopped if "defer start" is enabled Only revise the target state in moveToState if it would cross the stopped/started boundary. Change-Id: I8f6e400331157eac9343261117cf633611fc1e4d
* Bug 5535639 - Monkeys mad at FragmentManagerAdam Powell2011-10-311-0/+2
| | | | | | | Also check for starting deferred start fragments when a loader is destroyed. Change-Id: Ia17a902c579c09d7ac01079c7c1da137635aa08b
* Add API for deferring fragment start.Adam Powell2011-10-271-1/+28
| | | | | | | | | | | | | | Fragments now have the setDeferStart method to signal that a fragment has lower priority than others. Deferred start fragments will not always be started immediately; they will be started once any loaders have finished servicing any outstanding requests. This is useful if any attached fragments are not immediately visible and can wait to start until later. Disabling deferStart on a fragment that is waiting for a deferred start will start it immediately. Start. Change-Id: Ia1f004877ca5e88d4f10147d21c7e2e97f141c34
* docs: add developer guide cross-references, Project ACREJoe Fernandez2011-10-041-0/+6
| | | | Change-Id: I5df1c4e13af67ff4c4a5b22f3cb1247bf0103b09
* Fix issues 5158104 and 4981556 (fragment problems)Dianne Hackborn2011-08-291-12/+17
| | | | | | | | | | | | | | | | | | | | | | 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 can use to have the correct menus shows. And add a method to get the name of a back stack entry. Change-Id: Idcba14cfa2a172545a7a2a2c466cb49ceb789619
* Fix bug 5116342 - don't keep fragment state around once resumedAdam Powell2011-08-071-0/+3
| | | | | | | | Clear out saved fragment/view state when a fragment is resumed in case we didn't need to restore it. This keeps it from hanging around and preventing proper save/restore behavior later. Change-Id: Ie3fce5534ee4f8fdb4116281f9ac6a9cfa392561
* Fix bug 5090996 - Crash on tapping Menu on dial padAdam Powell2011-08-011-1/+16
| | | | | | | Let the FragmentManager handle deferring menu invalidation when not currently resumed. Change-Id: I6e5de9c8ab5288c7c90a59ce8e0c7bb9133b6eb5
* Various work on out of memory managment.Dianne Hackborn2011-07-291-0/+11
| | | | | | | | | | | | | - Improve how we handle processes that have shown UI, to take care of more cases where we want to push them into the background LRU list. - New trim memory level for when an application that has done UI is no longer visible to the user. - Add APIs to get new trim memory callback. - Add a host of new bind flags to tweak how the system will adjust the OOM level of the target process. Change-Id: I23ba354112f411a9f8773a67426b4dff85fa2439
* Bug 5076788 - Optimize the building and invalidation of menusAdam Powell2011-07-271-1/+1
| | | | | | | | Fix cases that weren't batching menu presenter changes correctly. Have FragmentManager invalidate the options menu less often. Change-Id: Ia66fcd09ada8b0a084ad6b08d4340a8fa0c8fc5d
* Fix issue #5054723: java.lang.NullPointerException at...Dianne Hackborn2011-07-221-0/+1
| | | | | | | | ...android.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:1284) Make sure to commit all pending actions before completing the destroy. Change-Id: I85643e5f7b1221048523bd186b48fb88fc70ca23
* Release strong Fragment references after exec.Jeff Sharkey2011-07-131-0/+1
| | | | | | | | When finished with a Runnable transaction in execPendingActions(), release the strong reference so that Fragment can be GC'ed. Bug: 3117761 Change-Id: Ica2f50e363be1bd047bf0474b293efeb814b1264
* Fix a major problem in fragment lifecycle.Dianne Hackborn2011-06-141-10/+18
| | | | | | | | | When animating away a fragment, we were not putting it through the last part of its lifecycle (onDestroy() etc). Also, retained fragments that have a target were broken. Oops. Change-Id: I5a669b77a2f24b581cde2a0959acf62edb65e326
* Fix some problems with moving in and out of detached state.Dianne Hackborn2011-06-101-3/+3
| | | | | | | | | Loaders were not being re-initialized correctly when coming back (this would also impact the back stack). The ListView also wasn't working correctly, and there were also problems with simply re-using a Fragment instance after it had been removed. Change-Id: I534b091ae09c0ef7ffffe9d68049e6840e8926b3
* Fix to not lose state when saving a deactivated fragment.Dianne Hackborn2011-06-031-8/+6
| | | | | | Also deactivating a fragment shouldn't put it in the exiting state. Change-Id: I514f3589ee7bbbee131cd7b4a48803e99b212bd0
* Add new Fragment API for explicitly saving/restoring state.Dianne Hackborn2011-06-021-21/+67
| | | | | | | | | | | | | | Also fix issue #4519821: Blank screen displayed on tapping "Battery Use" option in the settings We weren't correctly doing the full Activity resume code when coming back from delivering a new Intent or result. And fix a fragment problem where we still weren't correctly restoring the state of list views. (I think this was from a bad manual-merge from master.) Change-Id: If79dc7e998155c39ab8c04781f6c73a82238a9ef
* DO NOT MERGE. Integrate fragment work from masterDianne Hackborn2011-05-131-27/+70
| | | | | | | | | | | | | | | | | | | | | Back-port new fragment detach APIs from support lib. This allow a much cleaner implementation of things like the fragment pager class. Integrate from support lib: fix restore of list state. The FragmentManager/ListFragment impl was restoring the list state before setting its adapter. This caused the list view to lose the state, since it gets cleared as part of setting the adapter. Now the fragment manager waits on restoring the view hierarchy state until after it has done onActivityCreated(), at which point we have set the adapter. It would be nice to make list view less fragile in this regard, but that is for a different change. Change-Id: I38606ef7d0b06478995f3fb7726aead67420e172
* Fix Fragment.onInflate() to actually work correctly.Dianne Hackborn2011-03-031-0/+6
| | | | | | | | | | | | | | Like, um, it needs to be given the Activity since this is called before the activity is attached. And it was called after the entire fragment and its *view* was created when being restored from saved state. And the documentation was whacked. Also fix the IME selector to dismiss when you tap outside of it. Change-Id: Icbcafe7558965a570bdef9cda3441b1f0f7a317c
* Remove a stale line in a JavaDoc.Ben Komalo2011-02-281-4/+3
| | | | Change-Id: I2d98bf5aaa2d47adef2b31903761db3d9f7e1ac1
* Fix issue #3385839: Fragment.onCreateView is passing in activity...Dianne Hackborn2011-01-251-2/+2
| | | | | | ...context for a DialogFragment Change-Id: I434ebca64d2738da4c27321db8dbbded2cbe167d
* Maybe fix issue #3093599: java.lang.IndexOutOfBoundsException...Dianne Hackborn2011-01-241-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...Invalid index 0, size is 0 at android.app.ActivityThread.performPauseActivity(ActivityThread.java:2326) It looks like if an arrow key is dispatched between the time the list view is told its data set has changed and it does the resulting layout pass, we could try to move the position to a now invalid index. This may prevent that from happening. Also put in a better error message if saving state of a fragment whose target is no longer in the fragment manager. And fix a bug in PackageManager where we could return a null from queryIntentActivities(). And add a new API to find out whether a fragment is being removed, to help fix issue #3306021: NPE at android.app.AlertDialog.getDefaultDialogTheme(AlertDialog.java) Next, for new HC apps we can delay committing data to storage until the activity is stopped. Finally, use the new multi-threaded AyncTask executor in a few places, so we don't have worked blocked by long-running tasks from the application. Change-Id: I27b2aafedf2e1bf3a2316309889613fa539760f3
* Fix some error messages, turn off logging.Dianne Hackborn2011-01-211-3/+3
| | | | Change-Id: Ifcd2c0f0ad137485896144d2248361aeb0a05600
* Remove old APIs.Dianne Hackborn2011-01-171-11/+1
| | | | Change-Id: If676e4e7886ad71c4959d4253db99639b49218b8
* Fix a bunch of API review bugs.Dianne Hackborn2011-01-171-20/+45
| | | | | | | | | | 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
* Start renaming FragmentTransaction.openTransaction() to beginTransaction().Dianne Hackborn2011-01-171-2/+7
| | | | Change-Id: Ib4a6d824b33cca699b7b25159c491fb610d5f5da
* Fix null crash when fragments go away during animationsChet Haase2011-01-121-1/+3
| | | | Change-Id: I239cabce3ce322fcc3f1246486b4bf05f0dd322b
* Few little fragment, wm tweaks.Dianne Hackborn2011-01-041-1/+1
| | | | | | | | | | Deal with fragments being restored when their containing view is gone. Try to put in a black background during rotation. Currently commented out because it appears to cause surface flinger to hang. Change-Id: I150d061e64488356d17513f4e2d124d7c3d04f6b
* Minor fix to previous fragment change: non-animating caseChet Haase2010-12-281-0/+2
| | | | | | | | The previous change only hid the fragment when the transition animation ended. But if there is no animation, the fragment would never be hidden. This change adds an else clause that handles the non-animating case. Change-Id: Ie35b2ae98cb5c21193dadefbef71b8542fcf5f7d
* Delay hiding fragments until transition finishesChet Haase2010-12-281-1/+9
| | | | Change-Id: I616de20e7e161fe1a53cd5e72912cec48f078df5
generated by cgit v1.1 at 2024-08-12 12:36:26 +0000