5af42fc3052ecaf35c937278a986143a65f6ce5f |
|
25-Mar-2017 |
Winson Chung <winsonc@google.com> |
Ensuring multi-window callbacks contain new configuration and are in order - This CL has two main changes: 1) It modifies the activity multi-window and picture-in-picture mode changed callbacks to provide the configuration of the activity with the mode applied. 2) It modifies the order in which the multi-window and picture-in-picture mode callbacks are made, to ensure that when going in and out of picture-in-picture: first PiP, then MW, and then the config change. - Previously, the ordering of the two callbacks was inconsistent. When calling moveActivityToPinnedStack(), we reparent the task into the pinned stack (triggering the picture-in-picture mode change), followed by the resize animation (causes configuration changes). Inversely, when we expand the task to fullscreen (and not just remove it), we run the animation first, which resizes the task to the final size (causes configuration changes) then reparent after the animation completes (triggering the picture-in-picture mode change). In this CL, we ensure that for both the transition in and out of PiP, we defer to the bounds animation to trigger the PiP mode change. Normal calls to reparent or adding a new task are unchanged. When the PiP mode change is called from the animation, it provides the final target bounds which we use to calculate the target configuration of the activity for the callback. If the bounds animation is interrupted, an update will also be scheduled if we change the fullscreen state we are animating to. To work around the issue where we are scheduling MW/PiP mode changes in both the animation and the configuration change, we also now keep track of each state internally in the ActivityRecord. Bug: 36099777 Test: android.server.cts.ActivityManagerPinnedStackTests Test: #testConfigurationChangeOrderDuringTransition Change-Id: I03513bc3a4d4a72c250983f22f079ce9d7a2cb40 Signed-off-by: Winson Chung <winsonc@google.com>
/frameworks/base/core/java/android/app/FragmentController.java
|
514c5ef8d5774d8820ed1bf90fe53af1606cf106 |
|
25-May-2016 |
Aurimas Liutikas <aurimas@google.com> |
Add missing @Deprecated annotations. Add missing @Deprecated annotations for methods with @deprecated tag in javadoc. Change-Id: I35b78ccb97832d86b914c21a300444ba29e33844
/frameworks/base/core/java/android/app/FragmentController.java
|
933076d80561751618f462b26309ce9e4c3ff3bf |
|
30-Mar-2016 |
Andrii Kulian <akulian@google.com> |
Refactor usages of Picture In Picture and Multi Window (1/4) Bug: 27365860 Change-Id: I1590e430a12ceb84cb83da295e0bf7e4378fea96
/frameworks/base/core/java/android/app/FragmentController.java
|
44ba79e47d6db54e5501f994880fa09eb880c185 |
|
05-Feb-2016 |
Adam Powell <adamp@google.com> |
Permit setRetainInstance(true) on nested fragments, framework edition 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: Ia6640b76cfcf7ec28ba252628957a0c14863e957 (cherry picked from commit 7466be66263d5ebffb786ea402d9ed6e36c254f0)
/frameworks/base/core/java/android/app/FragmentController.java
|
7c796811c040a3b9c189d49f138028c5e44466a4 |
|
30-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added onMultiWindowChanged and onPictureInPictureChanged methods to Fragement class Bug: 26688489 Change-Id: I611444b29199b4686c9f78dbdd33c9b71820aec4
/frameworks/base/core/java/android/app/FragmentController.java
|
2ee19c7f46ab488f19380f4c70904a1ac00fee9a |
|
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: I88b465f6a06a6ad627b9651b9e2eea41fae08972
/frameworks/base/core/java/android/app/FragmentController.java
|
e16fb554dd49db118327ece0d9aac8eb788c7c54 |
|
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: I8358183a7689b5a571ea7be03d769186b2812600
/frameworks/base/core/java/android/app/FragmentController.java
|
a5fc6f006f67867417b7a427de6e7394c4312dec |
|
15-Apr-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: 19569654 Change-Id: I6816a5c1815122d206062b9f4584ad460b3d41dd
/frameworks/base/core/java/android/app/FragmentController.java
|