Status Update
Comments
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #2
This is a particularly hard device to come by - do you happen to have access to the device? If so could you provide us with the output of: adb shell dumpsys media.camera > info.txt
Thanks!
ap...@google.com <ap...@google.com> #3
Stacktrace:
Caused by: java.lang.IllegalArgumentException: Can not get supported output size under supported maximum for the format: 34
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes(SupportedSurfaceCombination.java:355)
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions(SupportedSurfaceCombination.java:197)
at androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions(Camera2DeviceSurfaceManager.java:198)
at androidx.camera.core.CameraX.calculateSuggestedResolutions(CameraX.java:943)
at androidx.camera.core.CameraX.bindToLifecycle(CameraX.java:293)
at androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle(ProcessCameraProvider.java:227)
Below are some findings based on our debugging
When Dex is connected
previewConfig.getMaxResolution() is returning "731x411" as maxSize.
Inside Preview.Builder.build() -> Default_MAX_resolution is set to "CameraX.getSurfaceManager().getPreviewSize()" which is 731x411
this is being picked as maxSize.
While rendering maxSize is 731x411 and minSize is 640x480 and below are available outputSizes
0 = {Size@11860} "4032x3024"
1 = {Size@11861} "3984x2988"
2 = {Size@11862} "4032x2268"
3 = {Size@11863} "3024x3024"
4 = {Size@11864} "2976x2976"
5 = {Size@11865} "3840x2160"
6 = {Size@11866} "3264x2448"
7 = {Size@11867} "4032x1960"
8 = {Size@11868} "2880x2160"
9 = {Size@11869} "3264x1836"
10 = {Size@11870} "2160x2160"
11 = {Size@11871} "2560x1440"
12 = {Size@11872} "2224x1080"
13 = {Size@11873} "2048x1152"
14 = {Size@11874} "1920x1080"
15 = {Size@11875} "1440x1080"
16 = {Size@11876} "1088x1088"
17 = {Size@11877} "1280x720"
18 = {Size@11878} "1024x768"
19 = {Size@11879} "1056x704"
20 = {Size@11880} "960x720"
21 = {Size@11881} "960x540"
22 = {Size@11882} "720x720"
23 = {Size@11883} "800x450"
24 = {Size@11884} "720x480"
25 = {Size@11885} "640x480"
26 = {Size@11886} "352x288"
27 = {Size@11887} "320x240"
28 = {Size@11888} "256x144"
29 = {Size@11889} "176x144"
and couldn't find any size in this range.
When Dex not connected
minsize = 640x480
maxsize = 1920x1080
0 = {Size@11836} "4032x3024"
1 = {Size@11837} "3984x2988"
2 = {Size@11838} "4032x2268"
3 = {Size@11839} "3024x3024"
4 = {Size@11840} "2976x2976"
5 = {Size@11841} "3840x2160"
6 = {Size@11842} "3264x2448"
7 = {Size@11843} "4032x1960"
8 = {Size@11844} "2880x2160"
9 = {Size@11845} "3264x1836"
10 = {Size@11846} "2160x2160"
11 = {Size@11847} "2560x1440"
12 = {Size@11848} "2224x1080"
13 = {Size@11849} "2048x1152"
14 = {Size@11850} "1920x1080"
15 = {Size@11851} "1440x1080"
16 = {Size@11852} "1088x1088"
17 = {Size@11853} "1280x720"
18 = {Size@11854} "1024x768"
19 = {Size@11855} "1056x704"
20 = {Size@11856} "960x720"
21 = {Size@11857} "960x540"
22 = {Size@11858} "720x720"
23 = {Size@11859} "800x450"
24 = {Size@11860} "720x480"
25 = {Size@11861} "640x480"
26 = {Size@11862} "352x288"
27 = {Size@11863} "320x240"
28 = {Size@11864} "256x144"
29 = {Size@11865} "176x144"
and we have 12 available sizes in this range
Camera2DeviceSurfaceManager.java:: getPreviewSize()
mCameraSupportedSurfaceCombinationMap.get(cameraId).getSurfaceDefinition().getPreviewSize() = "1920x1080"
cameraId=0
ap...@google.com <ap...@google.com> #4
The issue root cause is that CameraX will default filter out sizes smaller than 640x480. For Preview, the max size will be limited to under display size. I checked the HW spec info for the issue related devices. Display size of FUJITSU F-04J/F-05J is 360x640. That will result int that no size exists in the conditions that is larger or equal to 640x480 and smaller or equal to 360x640.
A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
For device FUJITSU arrowsM04, I checked its HW spec info and its display size I found is 1280x720. It seems that the problem should not exist in the device.
Could you confirm that the problem exist on arrowsM04 device? What will be the returned value when using Display#getRealSize to obtain the display size?
ap...@google.com <ap...@google.com> #5
> A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
OK. I will try it.
> Could you confirm that the problem exist on arrowsM04 device?
We receive the crash report (Crashlytics) that this crash has occurred on arrowsM04.
We don't have this device so we can't confirm that the problem really exist on arrowsM04.
> What will be the returned value when using Display#getRealSize to obtain the display size?
We can't investigate it for the same reason.
Thank you.
ap...@google.com <ap...@google.com> #6
This issue happened on devices that the display size is smaller than 640x480. In original auto-resolution mechanism, supported sizes smaller than 640x480 will be default filter out.
The auto-resolution mechanism encodes the guaranteed configurations tables in CameraDevice#createCaptureSession(SessionConfiguration). It defines that the PREVIEW size is the small one of the device display size and 1080p. The PREVIEW size will be the maximal size limitation for Preview use case. The reason it limits the size to display size and 1080p is the stream output in display size or 1080p has been able to provide good enough preview quality. Therefore, auto-resolution mechanism will limit the selected size to be smaller than the small one of the device display size and 1080p.
With above two conditions, in this issue, all sizes smaller than 640x480 have been filter out, therefore, there is no size smaller than the display size 320x240 can be selected to use. And cause the exception.
Solution:
When the display size is smaller than 640x480, auto-resolution mechanism won't filter out those small sizes smaller than 640x480. This makes those small size be left and can be selected for the Preview use case on small display devices.
The solution has been merged and will be included in next CameraX release.
ap...@google.com <ap...@google.com> #7
Hello.
This crash still occurs.
- CAMERAX VERSION: 1.0.0-beta4
- ANDROID OS BUILD NUMBER: Android 7.1.1
- DEVICE NAME: FUJITSU F-02H
We receive following crash report from FUJITSU F-02H. So far We have received this crash report only from F-02H.
java.lang.IllegalArgumentException
Can not get supported output size under supported maximum for the format: 34
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes (SupportedSurfaceCombination.java:349)
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions (SupportedSurfaceCombination.java:197)
androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions (Camera2DeviceSurfaceManager.java:198)
androidx.camera.core.CameraX.calculateSuggestedResolutions (CameraX.java:949)
androidx.camera.core.CameraX.bindToLifecycle (CameraX.java:351)
androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle (ProcessCameraProvider.java:230)
(our application's package name).CameraFragment.bindCameraUseCases (CameraFragment.java:174)
ap...@google.com <ap...@google.com> #8
Could you help to provide the following information to clarify the issue?
1. Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
2. Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
ap...@google.com <ap...@google.com> #9
- Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
Yes
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
Since we don't have this device, we'll try to collect this information in the next version of our app. The next version will be released later this month.
ap...@google.com <ap...@google.com> #10
Hello.
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
We have collected the output of the device where the crash occurs.
Device1
- Model : arrows Be F-05J
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Device2
- Model : Fujitsu arrows M04
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Additional Information
CameraX version : 1.0.0-beta04
We collect the supported output sizes by following code.
val errorString = buildString {
append("The supported output sizes of ImageFormat.PRIVATE: ")
(requireContext().getSystemService(Context.CAMERA_SERVICE) as CameraManager).apply {
cameraIdList.forEachIndexed { index, cameraId ->
val msg = if (VERSION.SDK_INT >= VERSION_CODES.M) {
val configurationMap =
getCameraCharacteristics(cameraId).get(CameraCharacteristics.SCALER_STREAM_CONFIGURATION_MAP)
val sizes = configurationMap?.getOutputSizes(ImageFormat.PRIVATE)
"CameraId $index: ${sizes?.joinToString(" ,")}"
} else {
"CameraId $index: This device version is under M."
}
append(msg)
}
}
}
ap...@google.com <ap...@google.com> #11
ap...@google.com <ap...@google.com> #12
I tried to find the device specs and both 720x1280
size display. For the camera id 0 device, it is a different case that the display size is larger than 640x480
but the device only supports a 480x480
size. The case also caused the same IllegalArgumentException and was also fixed by 1.0.0-beta04
release. Before 480x480
size would be filtered out and then caused the IllegalArgumentException. After it was merged, the 640x480
size threshold was removed and then the 480x480
size would be kept and selected to use.
It looks like 1.0.0-beta04
release had been used to collect the supported sizes information. But the issue should have been fixed by 1.0.0-beta04
release. Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
CameraX's 1.0.0-beta04
version. Maybe you can also consider to upgrade to the latest 1.0.0-rc01
version for your application. Thanks.
ap...@google.com <ap...@google.com> #13
Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
We collect informations only from the device on which IllegalArgumentException happened.
Our latest app uses CameraX version 1.0.0-beta10
and this issue still occurres.
However we don't receive crash report from Fujitsu arrows Be F-05J
or Fujitsu arrows M04
so far. (This doesn't mean this issue is fixed on these devices because our app is heavily rely on camera so these device's user wouldn't use our app anymore.)
Instead, we receive crash report from
- Model : Fujitsu F-03K
- Android Version : 7.1.2
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0 : 480x480
CameraId 1 : 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
ap...@google.com <ap...@google.com> #14
I missed some settings when I simulated the issue by robolectric test so that I was not able to reproduce it. Now, I can reproduce the issue if the device only supports one 480x480 resolution. I'm working on the solution and target to make it included in next release.
ja...@postmates.com <ja...@postmates.com> #15
Branch: androidx-main
commit 69d15dff7bb857ee33a0f643ff42a0f8bc475ab2
Author: charcoalchen <charcoalchen@google.com>
Date: Fri Jan 08 18:30:03 2021
Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Do not filter out sizes smaller than 640x480 when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Relnote:"Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480."
Bug: 150506192
Test: SupportedSurfaceCombinationTest
Change-Id: I2a63ce8e2ad42a9cc060c8635ac3603bf440b1ec
M camera/camera-camera2/src/main/java/androidx/camera/camera2/internal/SupportedSurfaceCombination.java
M camera/camera-camera2/src/test/java/androidx/camera/camera2/internal/SupportedSurfaceCombinationTest.java
il...@google.com <il...@google.com> #16
ja...@postmates.com <ja...@postmates.com> #17
RE #16 - I can try to set up a new repo that reproduces that, although it may be a week or so until I have enough time to build it out.
il...@google.com <il...@google.com> #18
Re #17 - that'd be fine. I might suggest making a separate issue (which we can mark as blocked by this issue) when you do create the repo project just so that we can track it to completion if it turns out to be a bigger / separate issue. Just reference your original comment here in your description.
ja...@postmates.com <ja...@postmates.com> #19
Re #18 - sounds good and will do. Thank you.
ap...@google.com <ap...@google.com> #20
Branch: androidx-master-dev
commit 385938be24095f3b32c9687c9d2468c60bdb84fb
Author: Ian Lake <ilake@google.com>
Date: Wed Apr 08 15:34:33 2020
Don't start special effects when destroyed
When the FragmentManager is destroyed, we
shouldn't kick off any new special effects.
Test: failing tests use USE_STATE_MANAGER now pass
BUG: 147749580
Change-Id: Ib0ce087b81adaf87bd5e76d92a90785f6aa673a7
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
ap...@google.com <ap...@google.com> #21
Branch: androidx-master-dev
commit 0650e2e4b6e7e428970acd4fa31fe7fb44cd1b8e
Author: Ian Lake <ilake@google.com>
Date: Wed Apr 08 16:08:12 2020
Call saveViewState() in moveToExpectedState()
Ensure that saveViewState() is called before
the View's special effects start.
Test: less tests fail with USE_STATE_MANAGER
BUG: 147749580
Change-Id: I9a2b683396e1fb2efc032a4eda689e63fcf9e038
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
ap...@google.com <ap...@google.com> #22
Branch: androidx-master-dev
commit d5d98e981e20b76b09a3da4635ad3c5bfd5fdedb
Author: Ian Lake <ilake@google.com>
Date: Fri Apr 10 13:47:39 2020
Make FragmentManager state changes execute special effects
Each change to the FragmentManager's state should
result in any pending special effects operations
being executed.
This avoids fragments getting stuck in
AWAITING_ENTER_EFFECTS after a configuration change.
Test: inflatedFragmentNotInLayout now passes with USE_STATE_MANAGER
BUG: 147749580
Change-Id: I3c82373dd5fa0a4447e41a0566b5c45c959150f8
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
ap...@google.com <ap...@google.com> #23
Branch: androidx-master-dev
commit 0c3d420cc4bbb8c3c8b28ec2570a3a1d4a47e042
Author: Ian Lake <ilake@google.com>
Date: Wed Apr 15 09:52:10 2020
Move findFragmentUnder() into FragmentStateManager
Instead of moving the Fragment after the fact to
the right index in its container after the fact,
place the fragment at the right index when it is
added in the first place.
This fixes fragment ordering tests when using
USE_STATE_MANAGER.
Test: existing view ordering tests still pass
BUG: 147749580
Change-Id: I3c70ba71e8caf38f543b1601b564c1bf28d76dec
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
ap...@google.com <ap...@google.com> #24
Branch: androidx-master-dev
commit 0f294af6a0a98a55f1e6797695ccae31c62f26a6
Author: Ian Lake <ilake@google.com>
Date: Thu Apr 16 15:52:01 2020
Use under and over fragments for relative positioning
The index that a newly added fragment's view should
be added to its container should be relative to
*all* other fragments in that container. This means
it should be above any fragments that are before it
in mAdded order and below any fragments that are
after it in mAdded order.
If no other fragment exists in the container, the
fragment's view should be added at the end of the
container (i.e., an index of -1) so that the fragment
is after any non-fragment views in the same container.
Test: updated FragmentStoreTest tests
BUG: 147749580
BUG: 154241885
Change-Id: I51f5e4c5d30d2ead62c27b2d44c68d704f31713e
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentStoreTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStore.java
ap...@google.com <ap...@google.com> #25
Branch: androidx-master-dev
commit f6bc21adad203544e66b8e23b7a181598172e7cb
Author: Ian Lake <ilake@google.com>
Date: Fri Apr 17 15:52:18 2020
Fix Animation listeners with USE_STATE_MANAGER
Since an Animation can only have a single
listener, we need to wrap enter animations
in an AnimationSet to ensure that we allow any
animation listener set on the Animation passed to
DefaultSpecialEffectsController still fires.
Test: FragmentAnimationTest#animationListenersAreCalled() passes
BUG: 147749580
Change-Id: Ibca0bd00b7408bf9a06b4831a782384437f0630d
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentAnim.java
ap...@google.com <ap...@google.com> #26
Branch: androidx-master-dev
commit 263faa13f7a6f4a4a33bb404225ab776895a6350
Author: Ian Lake <ilake@google.com>
Date: Wed Apr 29 15:25:01 2020
Determine direction based on FragmentTransactions
Rather than have DefaultSpecialEffectsController
try to determine whether the set of Operations
should be considered a pop or not, pass that information
through from FragmentManager which determines
direction by looking at the the FragmentTransactions
themselves.
By using only the direction of the last
FragmentTransaction, we can ensure that all operations
being executed are going in the same direction - this is
important when using non symmetric animations (such as
sliding to the left vs right).
Test: no regressions when running tests with USE_STATE_MANAGER
BUG: 147749580
Change-Id: I458ad8e2e7f728881b76fb2bcb25c4bdecf276d4
M fragment/fragment/src/androidTest/java/androidx/fragment/app/SpecialEffectsControllerTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
ap...@google.com <ap...@google.com> #27
Branch: androidx-master-dev
commit 44240d845252dea7a7b4a2b2a1cddea3d93860e4
Author: Ian Lake <ilake@google.com>
Date: Thu May 07 14:10:50 2020
Explicitly target transitioning Views
Ensure that each Transition explicitly targets
the Views within the associated Fragment.
Test: many more tests pass with USE_STATE_MANAGER
BUG: 147749580
Change-Id: Ie3a4fee66d5490abc6234afe79f84b337a66b2b7
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentTransition.java
ap...@google.com <ap...@google.com> #28
Branch: androidx-master-dev
commit 38d6b0aea86ce6884740849b841a3604a99ad6fe
Author: Ian Lake <ilake@google.com>
Date: Tue May 12 14:59:47 2020
Early return from startTransitions
When there is no Transition implementation
that can handle all transitions, we should
early return rather than have a giant else
statement.
Test: ./gradlew bOS
BUG: 147749580
Change-Id: I92aa1a5b020c81847e2cad831494b2a206294866
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
ap...@google.com <ap...@google.com> #29
Branch: androidx-master-dev
commit 96f880a054ca70663071677b85b37b6eeba48ea8
Author: Ian Lake <ilake@google.com>
Date: Tue May 19 12:28:41 2020
Add initial support for shared element transitions
Allow DefaultSpecialEffectsController to determine
what shared element transition to run and build the
initial logic to determine what views should be
excluded from the regular transition and instead
added to the shared element transition.
Test: no regressions when USE_STATE_MANAGER = true
BUG: 147749580
Change-Id: I728194fc964b850ed9cf9f2b798dc2acdb763429
M fragment/fragment/src/main/java/androidx/fragment/app/BackStackRecord.java
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
ap...@google.com <ap...@google.com> #30
Branch: androidx-master-dev
commit 28878f23fab386fdd299338c1a1cdda87927f199
Author: Ian Lake <ilake@google.com>
Date: Wed May 20 15:41:31 2020
Compute epicenter of transitions
Use the first shared element from
the firstOut fragment and the lastIn
fragment to drive the epicenters of
the exiting+shared element and entering
transitions, respectively.
Test: more tests pass epicenter tests
BUG: 147749580
Change-Id: I2697c3af1aa3dd8551a84ef1414bde02dbcd22fb
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
ap...@google.com <ap...@google.com> #31
Branch: androidx-master-dev
commit e98420c2f846b7dc3e72efd0444a806a648d187c
Author: Ian Lake <ilake@google.com>
Date: Tue May 19 15:26:36 2020
Compute shared element views eagerly
Set up the complete set of target views
for the shared element transition before
iterating through the set of TransitionInfo
objects.
Test: no regressions when USE_STATE_MANAGER = true
BUG: 147749580
Change-Id: Iaf7cbdd80c66b7299fb41cf6a98b9a3b3823fd8a
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
ap...@google.com <ap...@google.com> #32
Branch: androidx-master-dev
commit 992af3f5dd3661929c4dc62ddbf6028799196748
Author: Ian Lake <ilake@google.com>
Date: Thu May 28 17:12:47 2020
Track entering and exiting Views separately in tests
Rather than using a single varargs list for all
Views involved in transitions, track the set of
entering and exiting Views separately to allow for
easier debugging of test failures.
This switches the verifyAndClearTransition() test API
to using a receiver scope lambda to fill in a data
class on the information to pass through to the test.
This helps only pass the exact set of information
that is needed in a readable format rather than rely on
default parameters of a method.
Test: all existing tests still pass
BUG: 147749580
Change-Id: I072882a75a7393ac0dc4ea6797a6b6a91e50b94f
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTestUtil.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTransitionAnimTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTransitionTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/PostponedTransitionTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/TrackingTransition.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/TrackingVisibility.java
M testutils/testutils-runtime/src/main/java/androidx/fragment/app/TargetTracking.kt
M transition/transition/src/androidTest/java/androidx/transition/FragmentTestUtil.kt
M transition/transition/src/androidTest/java/androidx/transition/FragmentTransitionTest.kt
M transition/transition/src/androidTest/java/androidx/transition/TrackingTransition.kt
M transition/transition/src/androidTest/java/androidx/transition/TrackingVisibility.java
ap...@google.com <ap...@google.com> #33
Branch: androidx-master-dev
commit 5b1bdc8ce900dfb6a42caf870d58619ba603e70b
Author: Ian Lake <ilake@google.com>
Date: Fri May 29 15:16:41 2020
Convert getBoundsOnScreen(View) into Kotlin property
Add a Kotlin property extension for computing
the bounds on the screen.
Test: existing tests pass
BUG: 147749580
Change-Id: Ib78ec68cca3ffa30abbe7a046fabfbcadb5d1d61
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTestUtil.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTransitionTest.kt
M transition/transition/src/androidTest/java/androidx/transition/FragmentTestUtil.kt
M transition/transition/src/androidTest/java/androidx/transition/FragmentTransitionTest.kt
ap...@google.com <ap...@google.com> #34
Branch: androidx-master-dev
commit 79fc88305070516c1329253c2b37c604f0ec44cb
Author: Ian Lake <ilake@google.com>
Date: Fri May 29 15:29:50 2020
Always verifyAndClear each transition in tests
Rather than only checking the number of
exiting and entering targets for each transition in
the PostponedTransitionTest tests, always use
verifyAndClearTransition to confirm the epicenters and
exact view instances are correct.
As the epicenter is almost always wrong if the
set of entering/exiting views is wrong, this
also changed the verify ordering so that the more
useful information is checked first.
Test: existing tests still pass
BUG: 147749580
Change-Id: I176b59ea0e6ba32300ffe3cc5d16e678ae1a4dee
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTestUtil.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTransitionTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/PostponedTransitionTest.kt
M testutils/testutils-runtime/src/main/java/androidx/fragment/app/TargetTracking.kt
M transition/transition/src/androidTest/java/androidx/transition/FragmentTestUtil.kt
M transition/transition/src/androidTest/java/androidx/transition/FragmentTransitionTest.kt
ap...@google.com <ap...@google.com> #35
Branch: androidx-master-dev
commit 77e5239eeef9445216860b03ea42c5c4ed82decd
Author: Ian Lake <ilake@google.com>
Date: Mon Jun 01 17:04:39 2020
Fix shared element name calculation
Simplify (and fix!) the logic in getting
the shared element names from the fragment
by ensuring that the source/target names
get mapped to the correct entering/exiting
fragment.
Test: FragmentTransitionTest#intermediateFragment gets farther
BUG: 147749580
Change-Id: I6096460a004831557db91032f782f30a527b8c7c
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
ap...@google.com <ap...@google.com> #36
Branch: androidx-master-dev
commit 60a364248030a43715027ba6d5fb4af57968ce17
Author: Ian Lake <ilake@google.com>
Date: Thu Jun 04 15:57:10 2020
Improve assertions to verify elements, not size
Switch more assertions from using size and isEqualTo(0)
or isEmpty() and isTrue() to using the appropriate
assertions to check the exact elements or size.
Test: existing tests still pass
BUG: 147749580
Change-Id: Ie194694f60420e2c98b140c59b5d548acdf097c3
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTestUtil.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTransitionTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/PostponedTransitionTest.kt
M transition/transition/src/androidTest/java/androidx/transition/FragmentTestUtil.kt
ap...@google.com <ap...@google.com> #37
Branch: androidx-master-dev
commit 20ed2488bd0831701a916627d892374ca3667999
Author: Ian Lake <ilake@google.com>
Date: Thu Jun 04 15:40:39 2020
Ensure all transitions target a View
If the set of transitioningViews (the set not
handled by the shared element transition) is
empty, the enter/exit transition needs to
target the nonExistentView as otherwise it'll
fall back to the default of targeting all Views.
Test: tests proceed farther
BUG: 147749580
Change-Id: If2a2048e4a1caa5c4f7202d46c529668def6607e
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
ap...@google.com <ap...@google.com> #38
Branch: androidx-master-dev
commit 0c0c837d1f72590e639a69e756da5134bfc6fa8c
Author: Ian Lake <ilake@google.com>
Date: Thu Jun 04 14:58:10 2020
Always find the lastIn Fragment
Due to how ordered transactions occur, we should
always look for the lastIn Fragment, even if it
occurs before the firstOut Fragment.
This has a side effect of sometimes there being
a lastIn Fragment but no firstOut Fragment
(such as is the case for the first add()), so
we ensure that we only compute the shared
element transition when there's both a
firstOut and lastIn Fragment.
Test: tests get slightly farther
BUG: 147749580
Change-Id: I5dc060b2b4ba6c200b772fd7a6dcfd251e8bdb25
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
ap...@google.com <ap...@google.com> #39
Branch: androidx-master-dev
commit 7b7bba5cf0dc9dc14ed9d87117a7a96edcfaf222
Author: Ian Lake <ilake@google.com>
Date: Thu Jun 04 16:43:26 2020
Generate and use a mapping of shared element names
The whole point of shared element transitions is to
match up views from the firstOut Fragment with the
lastIn Fragment. In order to support missing Views and
a 1:1 matching of Views, we need to build a mapping
from the firstOut Views to the lastIn Views.
This mapping allows us to exclude Views that don't
exist in both Fragments as well as exclude shared
element transitions entirely that have no Views that
are shared (i.e., an empty mapping).
By applying this mapping, we can correctly swap
from the set of outgoing firstOut shared element Views
to the incoming lastIn shared element Views at the
appropriate times relative to beginDelayedTransition().
Test: considerably more shared element tests pass
BUG: 147749580
Change-Id: Id9159c510fd9af51954abc6d5564f9729089a736
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentTransition.java
ap...@google.com <ap...@google.com> #40
Branch: androidx-master-dev
commit b22db2d9e5fc751936d921f9dd763679a66841ef
Author: Ian Lake <ilake@google.com>
Date: Thu Jun 04 16:18:04 2020
Find all shared element Views first
We should find the possible shared element
Views from both the firstOut and lastIn
Fragment first before capturing any Views.
Corrects the inline comments to better clarify
what is actually going on.
Test: existing tests pass
BUG: 147749580
Change-Id: I724996d1f51a4fb60c2930c6c641d8861f2a1f60
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
ap...@google.com <ap...@google.com> #41
Branch: androidx-master-dev
commit 75e39d8d47387dcf0da3e9ba7ebb71a91cb78f5f
Author: Ian Lake <ilake@google.com>
Date: Wed Jun 10 11:20:14 2020
Add initial implementation of show/hide effects
Integrate show() and hide() operations into
SpecialEffectsController.
Test: more tests pass with USE_STATE_MANAGER
BUG: 147749580
Change-Id: I1fced4f4881f4caac6ea7024a506b1a54365d097
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
ap...@google.com <ap...@google.com> #42
Branch: androidx-master-dev
commit 3ac68157a36925715dd3f181a3296f7b926de61a
Author: Ian Lake <ilake@google.com>
Date: Mon Jun 15 16:02:06 2020
Postpone effects at a container level
Rather than the global postponement that
involves rolling back transactions, integrate
postponement into SpecialEffectsController to
simply delay any effects from starting until the
container is no longer postponed (i.e., the last
ADD or SHOW operation is on a Fragment that is not
postponed).
Test: many more postponed tests pass
BUG: 147749580
Change-Id: I3d4983d2d637641730c0386de8d51c3317a99f84
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentAnimationTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentAnimatorTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/PostponedTransitionTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/SpecialEffectsControllerTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
ap...@google.com <ap...@google.com> #43
Branch: androidx-master-dev
commit 36389e987facf2e97e1ad2e56b671330f85a9674
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 13 17:00:44 2020
Use onMapSharedElements in DefaultSpecialEffectsController
Integrate in the Fragment's SharedElementCallback
and its onMapSharedElements() into
DefaultSpecialEffectsController so that Fragments can
override the mapping of shared elements.
Test: onMapSharedElementIn()/Out() tests now pass
BUG: 147749580
Change-Id: Idc799d14c210ea6335edd13023f9419a1c930caf
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentTransition.java
ap...@google.com <ap...@google.com> #44
Branch: androidx-master-dev
commit 1ce8b9353dcd682eca759d73f14b1549ea22750b
Author: Ian Lake <ilake@google.com>
Date: Tue Jul 14 11:42:19 2020
Call onSharedElementStart/End() in DefaultSpecialEffectsController
Ensure that onSharedElementStart() and
onSharedElementEnd() are called on the appropriate
SharedElementCallback at the appropriate
times in DefaultSpecialEffectsController.
Test: callStartEndWithSharedElements() test now passes
BUG: 147749580
Change-Id: Icf9a83daac38ade390925ac68da7dcbea3c9eef0
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
ap...@google.com <ap...@google.com> #45
Branch: androidx-master-dev
commit a719fba6b63d6081e7b69de1a70e2d1e81bf52bf
Author: Ian Lake <ilake@google.com>
Date: Fri Jul 17 15:06:39 2020
Add experimental API for enabling FragmentStateManager
Provide an experimental API for controlling whether
the FragmentStateManager and new special effects system
should be enabled.
Currently this new system defaults to off, but will
be changed to true by default once all internal tests
pass. This API will then exist only to verify that
a regression is due to the new code path.
Test: tested in a sample app
BUG: 147749580
BUG: 139536619
Relnote: "Added a new *experimental* API for controlling
whether FragmentManager uses the new internal state
manager for controlling dispatching lifecycle methods,
animations and transitions, and handling postponed
transactions."
Change-Id: I7b6ee13ea89f3989beafe7c474455e8a04e929a3
M fragment/fragment/api/public_plus_experimental_1.3.0-alpha07.txt
M fragment/fragment/api/public_plus_experimental_current.txt
M fragment/fragment/build.gradle
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
A fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManagerControl.java
ap...@google.com <ap...@google.com> #46
Branch: androidx-master-dev
commit d471ae700ee80a9893c09fddff1f20a85dc80b91
Author: Ian Lake <ilake@google.com>
Date: Thu Jul 23 10:26:39 2020
Merge multiple operations on the same fragment
When a SpecialEffectsController already has a
pending Operation for a given Fragment, it now
intelligently merges the new Operation into the
previous one rather than creating an entirely new
Operation.
This ensures that at any time, there's at most one
pending Operation for a fragment that captures two
important pieces of information:
- What the final state of the Fragment should be
after the Operation. This can one of the normal view
visibilities (VISIBLE, GONE, or INVISIBLE) or REMOVED
for the cases where the view should be removed entirely
from the container
- What impact that Operation has on the lifecycle
of the fragment which is used by FragmentStateManager's
computeExpectedState()
By moving to this model rather than explicit types,
we ensure that pairs of actions (such as a postponed
add + remove due to popping the back stack) do not result
in any special effects.
Test: many postponed tests that pop postponed ops now pass
BUG: 147749580
Change-Id: I7a0bdef0e0ba25d0eeca4b3c12222b6ccab776ba
M fragment/fragment/src/androidTest/java/androidx/fragment/app/SpecialEffectsControllerTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
ap...@google.com <ap...@google.com> #47
Branch: androidx-master-dev
commit 781397ddce37be950d570d236ce833b06c41c720
Author: Ian Lake <ilake@google.com>
Date: Thu Jul 23 14:07:21 2020
Handle Fragments that manually set themselves to INVISIBLE
Fragments technically have the ability to manually
change their view's visibility up through
onViewCreated(). We should respect what visibility they
set for themselves and pass that as the final state
to SpecialEffectsController.
Test: tests using invisible fragments now pass
BUG: 147749580
Change-Id: I11ea84a89076fd72535c1855e72bdbef6855d173
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
ap...@google.com <ap...@google.com> #48
Branch: androidx-master-dev
commit df1b6509720cbda8149b14fe62667d5def1275d8
Author: Ian Lake <ilake@google.com>
Date: Thu Jul 23 16:00:35 2020
Properly clean up transition targets
Ensure that any targets set on a Transition
are cleaned up after the Transition runs
so that no state is left over in cases where
the Transition is reused.
Test: many Postponed tests now pass
BUG: 147749580
Change-Id: Id251f2bd4e0e43dd7b649457564d15cd7d792856
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
ap...@google.com <ap...@google.com> #49
Branch: androidx-master-dev
commit d0e8440dcc8ddb53e8e1e4f0a87a3a671a248492
Author: Ian Lake <ilake@google.com>
Date: Fri Jul 24 09:33:38 2020
Only call executeOperations with a non-empty list
Test: noExecuteIfEmpty() test passes
BUG: 147749580
Change-Id: Ic6b3a63d52a66f4f7883f8275a7ab07ae77894c8
M fragment/fragment/src/androidTest/java/androidx/fragment/app/SpecialEffectsControllerTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
ap...@google.com <ap...@google.com> #50
Branch: androidx-master-dev
commit 9cf490f8efd92b208d0a2228b098b9397039d67e
Author: Ian Lake <ilake@google.com>
Date: Fri Jul 24 11:19:17 2020
Force complete special effects on state changes
Whenever the FragmentManager's state changes, it
is important that both the FragmentManager's internal
state, and the state of its Fragments and their views
be in a consistent state.
Test: saveWhilePostponed() and removeParentWithAnimation()
tests now pass
BUG: 147749580
Change-Id: Ia8bce51b7ef7b38a117660bf3935bd865a1985c7
M fragment/fragment/src/androidTest/java/androidx/fragment/app/SpecialEffectsControllerTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
ap...@google.com <ap...@google.com> #51
Branch: androidx-master-dev
commit 78f6c0185f148a8e8a9119c5de7fd6e97006240d
Author: Ian Lake <ilake@google.com>
Date: Fri Jul 24 13:23:55 2020
Fix replacePostponedFragment() test with state manager
Update the replacePostponedFragment() test for
USE_STATE_MANAGER - as postponed transactions aren't
rolled back when using the new state manager, the
expected set of change events is different between
the two cases.
Test: test now passes
BUG: 147749580
Change-Id: I50e1961608ad35fed82c90c10d4618a5bf0d255f
M fragment/fragment/src/androidTest/java/androidx/fragment/app/PrimaryNavFragmentTest.kt
ap...@google.com <ap...@google.com> #52
Branch: androidx-master-dev
commit 19f45aadaef63f7aa14ef66adf554b8a9ed7cb09
Author: Ian Lake <ilake@google.com>
Date: Fri Jul 24 14:02:34 2020
Wait for initial animations before continuing tests
When using FragmentStateManager, animations can
be cancelled or combined even when not reordering.
By waiting for the intial animation to complete, we
ensure that the replace animation later runs in
isolation.
We check the nullability of child views immediately
after kicking off the parent transaction since
Animation's waitforEnd() is based on sleep calls
which do not accurately catch the end before the
onDestroyView() happens synchronously with the
Animation ending.
Test: tests pass now
BUG: 147749580
Change-Id: Ib1572a82e70e62932482cae0ea9fc1e9ca704791
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentAnimationTest.kt
ap...@google.com <ap...@google.com> #53
Branch: androidx-master-dev
commit 1c8e89effc36ed211218a034f16faa0dfcb55a54
Author: Ian Lake <ilake@google.com>
Date: Fri Jul 24 16:10:08 2020
Fix PostponedTransitionTests for state manager
Fix tests that postpone multiple fragments
at a time to test the correct states when
USE_STATE_MANAGER is true. In those cases,
postpone works at a container level and not
at a transaction level.
Test: tests now pass
BUG: 147749580
Change-Id: I44f11e07e3fa5c818fb259779247aee2e1b8bb06
M fragment/fragment/src/androidTest/java/androidx/fragment/app/PostponedTransitionTest.kt
ap...@google.com <ap...@google.com> #54
Branch: androidx-master-dev
commit d1b80f0d53675b8bdb8c617e63856b390b34a7f1
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 15:32:34 2020
Fix postponeDoesNotAllowReentrancy() with state manager
Postponed transactions are synchronously
commited in the USE_STATE_MANAGER world, so
there is no ability to be reentrant like was
possible in the previous world.
This updates the test to apply the correct logic.
Test: postponeDoesNotAllowReentrancy() passes
BUG: 147749580
Change-Id: I27a27fd747f3a71897b02fc405f25216d4f74b90
M fragment/fragment/src/androidTest/java/androidx/fragment/app/PostponedTransitionTest.kt
ap...@google.com <ap...@google.com> #55
Branch: androidx-master-dev
commit aa4cf01985212d1e1476921dbec77d35405772d2
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:36:30 2020
Fix shared element names when popping
When popping fragments with mismatching
shared element transition names, we should
always use the source names as the exiting
names and target names as the entering
names instead of trying to swap them
based on whether it is a pop or not.
Test: crossContainer() test now passes
BUG: 147749580
Change-Id: Ibcf14e45003e07b56a570cad277e7bb04c681908
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
ap...@google.com <ap...@google.com> #56
Branch: androidx-master-dev
commit 175fad0f0f6dbfae4f5a8c2c0a12882fe4c2e37e
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue Jul 28 16:14:19 2020
Ensure fragment views are re-added to the container
When using the new move to state (USE_STATE_MANAGER=true), if a fragment
has started animating out its view is removed from the container. If
the fragment is re-added to the fragment manager before the animation
has a chance to finish, the exit animation is cancelled and the
fragment reuses the same view. This view should be added back to the
container or there can be animation issues.
Test: FragmentContainerViewTest pass in new world (8 tests failing)
Bug: 147749580
Change-Id: Ie267edc514c53260fd9219f8fa99171f831149d2
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentContainerViewTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
ap...@google.com <ap...@google.com> #57
Branch: androidx-master-dev
commit f90440e0cfca0f3cbbddca65c4136f5577099e53
Author: Ian Lake <ilake@google.com>
Date: Tue Jul 28 16:56:43 2020
Fix tests failing when using reordered transactions
When USE_STATE_MANAGER is true, tests that made
assumptions about what can/can't be handled when
performing reordered transactions need to be updated
as the new system is more capable.
Test: affected tests now pass
BUG: 147749580
Change-Id: I5d78104271b814c05da7355303fe4d74e1423f7a
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTransitionTest.kt
ap...@google.com <ap...@google.com> #58
Branch: androidx-master-dev
commit 25619f84f11efcb88069499c20b2051984635935
Author: Ian Lake <ilake@google.com>
Date: Thu Jul 30 15:56:26 2020
Fix removeThenAddBeforeTransitionFinishes()
Ensure that the removeThenAddBeforeTransitionFinishes()
test passes when using ordered transactions and
USE_STATE_MANAGER. In this configuration, the
transition gets correctly cancelled before completion.
Test: test now passes
BUG: 147749580
Change-Id: Ie3297754f792110884a5d44bf89ce8781ee20bce
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTransitionTest.kt
ap...@google.com <ap...@google.com> #59
Branch: androidx-master-dev
commit 552a2f34ba97004d8b0a8bb24a9185c6d7908d04
Author: Ian Lake <ilake@google.com>
Date: Fri Jul 31 15:30:40 2020
Fix transitions with hide()
Ensure that transitions associated with
hide() work as expected.
Test: showHideTransition() test now passes
BUG: 147749580
Change-Id: I46662fcad3b3d95f3ab329db7232540d09ce0770
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
ap...@google.com <ap...@google.com> #60
Branch: androidx-master-dev
commit 68785f1076beba95f2df10c822d87e3d13e641f2
Author: Ian Lake <ilake@google.com>
Date: Fri Jul 31 18:01:22 2020
Re-map shared element transitions for multiple transactions
When multiple transactions are done as part of
one executeOperations(), we may need to re-map
the shared element names rather than only using
the names from one of the transactions.
Test: intermediateFragment() test now passes
BUG: 147749580
Change-Id: I1785cf4665fb29f1b33fe5ad9b9277d885339d85
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
ap...@google.com <ap...@google.com> #61
Branch: androidx-master-dev
commit 1052c3662c40176f7f02da9e06b989dcab21d500
Author: Ian Lake <ilake@google.com>
Date: Fri Jul 31 16:55:38 2020
Restore the focused view after special effects complete
By making views invisible until their special
effects run, any view that was focused from
requestFocus() or the <requestFocus/> tag was
cleared. By saving that view and calling
requestFocus() on it manually after the Operation
completes, we can ensure that the focus is not
lost.
Test: focusedView() test now passes
BUG: 147749580
Change-Id: I0436efb07c1015708430b196321465d20f7aa6f2
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
ap...@google.com <ap...@google.com> #62
Branch: androidx-master-dev
commit 281235d26e08b136a32cb5051f89df4786975135
Author: Ian Lake <ilake@google.com>
Date: Sun Aug 02 15:23:18 2020
Ensure that cancelled operations have no lifecycle impact
When using forceCompleteAllOperations(), operations
are cancelled prior to calling complete(). The complete()
call that calls through to FragmentStateManager's
moveToExpectedState() synchronously calls through to
getAwaitingCompletionLifecycleImpact() to determine the
final state of the fragment. Since the operation is
already cancelled, it should not be considered in
terms of lifecycle impact.
This fixes an issue where changes in the FragmentManager's
state (specifically the destruction of the view due to
a parent fragment going on the back stack) would not be
properly reflected in the fragment's state, effectively
never moving below AWAITING_EXIT_EFFECTS.
Test: updated SpecialEffectsControllerTest tests pass
BUG: 147749580
Change-Id: I5a13e8674f9537aaef8c773b49749feb89492eb3
M fragment/fragment/src/androidTest/java/androidx/fragment/app/SpecialEffectsControllerTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
il...@google.com <il...@google.com> #63
All the work has completed with this effective complete rewrite of the internals of FragmentManager and how it handles animations and transitions. The new state manager is enabled by default for the Fragment 1.3.0-alpha08 release.
You can verify this by following the 6732061
and switching your fragment dependency to 1.3.0-SNAPSHOT
.
We'll be verifying the fix of each blocked issue and closing them one by one after verification.
Description
Component used: Fragment Version used: 1.2.0-rc05 as well as all previous versions of Fragments
When a Fragment is postponed using
postponeEnterTransition()
, the expected behavior is that the container the Fragment is added to does not run any enter animations or previously queued up exit animations (i.e., for areplace()
operation) until the Fragment callsstartPostponedEnterTransition()
. It is also expected that the Fragment does not reach theRESUMED
state while its container is postponed.However, it seems like FragmentManager isn't just doing that, but instead is moving the Fragment and the whole FragmentManager into a weird, inconsistent state.
Namely, any FragmentTransaction that touches the container of the postponed Fragment is 'rolled back' (i.e., done in reverse), but those Fragments aren't actually moved to their proper state.
This leads to cases where:
isAdded()
returns false)findFragmentById()
doesn't return the newly added Fragment over the one it replaces, even when usingcommitNow()
onCreateView()
can be called a second time (Ideally, the FragmentManager should always be in its final state once the transaction is executed and not rolled back and the Fragments should remain in the correct state as they wait for
startPostponedEnterTransition()
to run. This should really, really only affect the Fragments in that specific postponed container instead of doing things at the transaction level.