Status Update
Comments
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
vi...@google.com <vi...@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.
ap...@google.com <ap...@google.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
ap...@google.com <ap...@google.com> #16
vi...@google.com <vi...@google.com> #17
ap...@google.com <ap...@google.com> #18
Branch: androidx-master-dev
commit c06fb9f4d3334701bc1de8ee85c7a4e6149addcf
Author: Ian Lake <ilake@google.com>
Date: Mon Nov 11 10:32:31 2019
Move <fragment> tag state handling to FragmentStateManager
Move the logic for handling <fragment> tag added
Fragments that are not in the layout to
FragmentStateManager's computeMaxState() with the
other state logic.
Test: newly added FragmentLifecycleTest
BUG: 139536619
Change-Id: Ieaabdac16786418f89279a17bbe5661e12c11290
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentLifecycleTest.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> #19
Branch: androidx-master-dev
commit ac963796fb52c1556be07a9dae91ee4034f20715
Author: Ian Lake <ilake@google.com>
Date: Mon Nov 11 11:03:15 2019
Move initState() call into FragmentStateManager
Instead of doing this work in moveToState(), it
can be moved into FragmentStateManager since it
only depends on the Fragment's internal state.
Test: all existing Fragment tests pass
BUG: 139536619
Change-Id: I100be37c69f3d9274db308a44bfb4c8df09a3062
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> #20
Branch: androidx-master-dev
commit fd68f92de244735a6b6eccb73474d952d287b0d3
Author: Ian Lake <ilake@google.com>
Date: Tue Nov 19 16:01:35 2019
Move active and added fragments to FragmentStore
Instead of FragmentManager directly storing and
managing the set of active and added fragments, move
that functionality to a separately testable
FragmentStore object.
This will make it possible to have FragmentStateManager
access other FragmentStateManagers without directly
knowing about FragmentManager.
Test: new FragmentStore tests, all existing tests pass
BUG: 139536619
Change-Id: I69cefc8b2422f809e1498c5c9e4b09edd9026840
A fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentStoreTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
A fragment/fragment/src/main/java/androidx/fragment/app/FragmentStore.java
an...@google.com <an...@google.com> #21
ap...@google.com <ap...@google.com> #22
Branch: androidx-master-dev
commit 9268d14672abfd46bbcb9563fb87e7ff3cfd1c58
Author: Ian Lake <ilake@google.com>
Date: Wed Nov 20 13:09:00 2019
Remove usages of mocks in FragmentStoreTest
Instead of using mock Views, construct a
real View instance to avoid Mockito spin up
time.
Test: test still passes
BUG: 139536619
Change-Id: I27831f134f5aa7a1ff4474c64b0f9f35dd51eeb3
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentStoreTest.kt
ap...@google.com <ap...@google.com> #23
Branch: androidx-master-dev
commit a2070a6b604f845c8bde4319a378bc3ece401eb8
Author: Ian Lake <ilake@google.com>
Date: Fri Nov 22 13:12:08 2019
Remove FragmentManager dependency from FragmentTransition
Rather than passing in the FragmentManager itself
directly into FragmentTransition.startTransitions(),
pass in only the objects we need (a Context and
a FragmentContainer).
This allow further decoupling of the transitions
from FragmentManager itself.
Test: all existing tests pass
BUG: 139536619
Change-Id: I06b2c6ca6ef2b7d5a8566fc75194169a686aef13
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentTransition.java
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #24
Branch: androidx-master-dev
commit 4a2e625f3a6887a737081bce3abd58f975c6f2f0
Author: Ian Lake <ilake@google.com>
Date: Mon Dec 02 13:33:22 2019
Dispatch manager state changes to FragmentStateManagers
Instead of assuming that a FragmentStateManager
can go up to RESUMED by default, dispatch the
FragmentManager's state changes to each
FragmentStateManager and use that to set
the maximum state of the FragmentStateManager.
The one exception is when using the <fragment>
tag, which allows Fragments to move to CREATED
before the FragmentManager itself moves to
CREATED.
Test: new tests pass, all existing tests pass
BUG: 139536619
Change-Id: I748bb0afc8ffe956dcd6fa695437a0a0d54e8762
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentStateManagerTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
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 a4659c8f26bed57802cc7ee75c575c9c3cc90ebf
Author: Ian Lake <ilake@google.com>
Date: Wed Dec 04 13:58:22 2019
Make mHost and mContainer private
The internal state of FragmentManager should
not be directly accessed. Create package
private setters for the cases where they are
absolutely required.
Test: Fragment compiles
BUG: 139536619
Change-Id: I02ac9ca55899423544e597421c498707e33c71f1
M fragment/fragment/src/main/java/androidx/fragment/app/BackStackRecord.java
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentLayoutInflaterFactory.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentTransition.java
ap...@google.com <ap...@google.com> #26
Branch: androidx-master-dev
commit 12b33f91aa82443896194bc59c5051453f2aa7ad
Author: Ian Lake <ilake@google.com>
Date: Wed Dec 04 14:23:19 2019
Retrieve lifecycle parameters from FragmentManager
Instead of being explicitly passed parameters for
attach, createView, etc., retrieve them from
the FragmentManager already set on the Fragment.
Test: all existing tests pass
BUG: 139536619
Change-Id: If011688280a3c6736374b5d6e9def6d1da6f7066
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentLifecycleCallbacksDispatcher.java
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> #27
Branch: androidx-master-dev
commit 62de6890627e3d81dbc89509960149243cb44811
Author: Ian Lake <ilake@google.com>
Date: Wed Dec 04 15:17:40 2019
Remove FragmentContainer from loadAnimation
The mContainer is already set on the Fragment
by the time loadAnimation is called, so we
can use that rather than getting the container
from FragmentContainer.
Test: all existing tests pass
BUG: 139536619
Change-Id: If7e1bce5bdd0a7c7a3ddb6e495866835f7265bb6
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentAnim.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
ap...@google.com <ap...@google.com> #28
Branch: androidx-master-dev
commit 0454ddec1befa0ace1242700bf00f85e0aee5ad3
Author: Ian Lake <ilake@google.com>
Date: Thu Dec 05 11:19:01 2019
Explicitly pass nonConfig to FragmentStateManager
Instead of passing in the FragmentManagerViewModel
into specific lifecycle methods, explicitly pass
it into the constructor.
Test: all existing tests pass
BUG: 139536619
Change-Id: I020b1b0f446c76217e2bdb95731457f03b14c2c3
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentStateManagerTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentStoreTest.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> #29
Branch: androidx-master-dev
commit d10ec06d7f998e1ab74ad3fbee6f5168f29f528f
Author: Ian Lake <ilake@google.com>
Date: Thu Dec 05 16:06:43 2019
Move add/removeRetainedFragment logic to non config
Instead of splitting the logic of
add/removeRetainedFragment between FragmentManager
and FragmentManagerViewModel (the non config),
move it all to non config.
This requires forwarding signals on whether the
state is saved to FragmentManagerViewModel so
that it can properly ignore changes after the
state is saved.
Test: newly added tests pass
BUG: 139536619
Change-Id: I5301c02534d0da4c9b5a57efc96d4b7b6382b9b4
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentManagerViewModelTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManagerViewModel.java
ap...@google.com <ap...@google.com> #30
Branch: androidx-master-dev
commit 792f47b59c1c6bbc017757d202a5c24caade98fe
Author: Ian Lake <ilake@google.com>
Date: Fri Dec 06 13:52:18 2019
Move makeActive/Inactive entirely to FragmentStore
Instead of splitting makeActive and makeInactive's
functionality between FragmentManager and
FragmentStore, move all of the logic to
FragmentStore.
Test: new FragmentStore tests, existing tests pass
BUG: 139536619
Change-Id: I5769273fe402a254b9437ced05cd3943cbd88e70
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentStoreTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStore.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentTransition.java
ap...@google.com <ap...@google.com> #31
Branch: androidx-master-dev
commit 1e2d4c45ef615d979aebf525dc22bc1350d96ead
Author: Ian Lake <ilake@google.com>
Date: Mon Dec 09 12:27:42 2019
Move remaining attach logic to FragmentStateManager
Use FragmentStateManager's access to FragmentStore
and its moveToExpectedState() to move all of the
logic for moving to the attached state to
FragmentStateManager.
Test: existing tests pass
BUG: 139536619
Change-Id: Icd63b447febcb4b1b4fae07aa7fa2a68d79730be
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> #32
Branch: androidx-master-dev
commit 57f2f664df270547e97ea806067683581c52b6d4
Author: Ian Lake <ilake@google.com>
Date: Mon Dec 09 10:20:34 2019
First draft of FragmentStateManager moveToExpectedState()
Allow components to work directly with
FragmentStateManager when moving a Fragment to its
expected state instead of going through
FragmentManager's moveToState().
This is currently only used for the case for
restoreRetainedInstanceFragmentWithTransparentActivityConfigChange
which does not rely on any of the TODOs listed in
moveToExpectedState().
Test: new tests pass
BUG: 139536619
Change-Id: Ibb1d51ea70cc00b5ff21936c74b565447391c0a4
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentStateManagerTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentStoreTest.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> #33
Branch: androidx-master-dev
commit 07cc34f9a88067c26634a575587cfe55132360c4
Author: Ian Lake <ilake@google.com>
Date: Wed Dec 11 11:06:26 2019
Use FragmentStateManager for <fragment> tag
Use FragmentStateManager's moveToExpectedState
for the <fragment> tag instead of relying on
FragmentManager's moveToState.
Test: existing tests pass
BUG: 139536619
Change-Id: I77778b3d7e634a4ea7c9d228819a9f2936e347f1
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentLayoutInflaterFactory.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
ap...@google.com <ap...@google.com> #34
Branch: androidx-master-dev
commit 3eb8650f005697c8a036605bf5170b9d8177b761
Author: Ian Lake <ilake@google.com>
Date: Thu Dec 12 13:48:29 2019
Remove getStateAfterAnimating()
FragmentStateManager already knows what the
correct state should be so we don't need to
track it separately with setStateAfterAnimating()
and getStateAfterAnimating().
Test: all existing tests pass
BUG: 139536619
Change-Id: I5d48edbf47aca4f57fda0553cf767dfbfc21d642
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
ap...@google.com <ap...@google.com> #35
Branch: androidx-master-dev
commit fb4893d9baba2f759a3ebba61f228a48e11fd72c
Author: Ian Lake <ilake@google.com>
Date: Thu Dec 12 14:08:08 2019
Simplify moveToState logic for FragmentTransition
FragmentTransition's moveToState() logic only
applies to newly added Fragments, so we can simplify
the logic used to rely on computeExpectedState().
Test: existing tests pass
BUG: 139536619
Change-Id: I1568791a7aaa3a8a3dfb14a75fa121a32884e443
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentTransition.java
an...@google.com <an...@google.com> #36
Release Track: (
Created: 2019-12-18 21:08:39.436017+00:00
Changes: aosp/1178750, aosp/1171290, aosp/1170093
ap...@google.com <ap...@google.com> #37
Branch: androidx-master-dev
commit 3e885783ef9bf3d7717cc55ae4ccf857d74965f8
Author: Ian Lake <ilake@google.com>
Date: Tue Feb 18 15:29:20 2020
Handle re-entrant calls to moveToExpectedState()
As moveToExpectedState() runs user code that can
potentially change the external state, it is possible
for re-entrant calls to moveToExpectedState() to
happen. In this case, we can ignore the re-entrant
call, knowing that after the current state transition
completes FragmentStateManager will call
computeExpectedState() after each transition and pick
up the updated state.
Test: this isn't technically possible yet, but it will be
BUG: 139536619
Change-Id: I500e6f0e78d20355ab21a1f21fc66067f72e46a9
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
ap...@google.com <ap...@google.com> #38
Branch: androidx-master-dev
commit 4d3bac24c5a77c5ab5624795afa709b3f265bf74
Author: Ian Lake <ilake@google.com>
Date: Tue Feb 25 15:47:06 2020
Add infrastructure to fully switch to FragmentStateManager
Add the initial logic to fully replace all usages of
moveToState() with FragmentStateManager and its
moveToExpectedState().
Enabling this flag currently causes many tests to fail
(due to work not being completed on
this infrastructure will allow us to confirm our fixes
are actually applied while iterating through those
outstanding issues.
Test: tests all pass with USE_STATE_MANAGER = false
BUG: 139536619
Change-Id: I84340091ce1b0bcc3e26051e25a12d7b38b860c4
M fragment/fragment/src/main/java/androidx/fragment/app/BackStackRecord.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStore.java
ap...@google.com <ap...@google.com> #39
Branch: androidx-master-dev
commit b58d84209a566d60dbec35670fd3d977adcea1cf
Author: Ian Lake <ilake@google.com>
Date: Wed Feb 26 16:11:21 2020
Stop using findFragmentManager in SpecialEffectsController
Instead of relying on findFragmentManager() in
SpecialEffectsController, pass the FragmentManager
in directly. This works around issues where developers
nest fragments without using the childFragmentManager.
findFragmentManager() now correctly throws in those
cases.
Test: new tests pass
Test: SpecialEffectsController tests pass with USE_STATE_MANAGER = true
BUG: 139536619
Change-Id: I7de94fa6275fe8a5e67736194d7fc099539dd395
M fragment/fragment/src/androidTest/java/androidx/fragment/app/DefaultSpecialEffectsControllerTest.kt
A fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentManagerTest.kt
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/FragmentStateManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
ap...@google.com <ap...@google.com> #40
Branch: androidx-master-dev
commit c643f98908f3d5ee5f48b37e3edcc113a16a6bbc
Author: Ian Lake <ilake@google.com>
Date: Mon Mar 02 09:54:45 2020
Move makeInactive() out of moveToState()
Instead of calling makeInactive() as part
of moveToState() / moveToExpectedState(),
run that logic *after* the state settles.
Updating the target fragments correctly can
then be moved solely to FragmentStateManager's
destroy(), ensure it runs at the right time.
Special care had to be made when restoring
retained fragments that aren't in mActive so
that they are manually removed from the mNonConfig
(as before that would have been take care of
by moveToExpectedState()).
Test: all existing tests pass
BUG: 139536619
Change-Id: Ie33e01622f5edf212822f9c75f60c532a352a2d1
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStore.java
fi...@google.com <fi...@google.com> #41
il...@google.com <il...@google.com> #42
Re #41 - as soon as the
fi...@google.com <fi...@google.com> #43
Is this fixed?
Thanks,
Fiona
il...@google.com <il...@google.com> #44
See
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 c4e66e2a8b86db77158d21527b6eceb27290097b
Author: Ian Lake <ilake@google.com>
Date: Fri Jul 31 22:43:47 2020
Change reordering parameter from boolean to sealed class
Instead of using a boolean reorderingAllowed
parameter that only shows as 0 or 1 in test naming,
convert it to using a sealed class that makes it
more clear which type of ordering is being used.
Test: tests still pass
BUG: 139536619
Change-Id: I3e7f433d20b13f7bb5882b85d67a0c8267fd4da4
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 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> #47
Branch: androidx-master-dev
commit 67ea65bcb2190d8be41e8896ab7b2fbd67c6f56b
Author: Ian Lake <ilake@google.com>
Date: Sun Aug 02 11:33:37 2020
Parameterize tests to use both old and new state manager
Parameterize a number of test suites affected
by the usage of FragmentStateManager so that they
run both under the old state manager and the new
system to avoid regressions during the cross over
time period.
Changed the focusedView() test to not run on the
UI thread, fixing flaky issues when running as part
of a parameterized test suite.
Changed the testTimedPostponeEnterPostponedCalledWithZero()
test to wait for the transition to finish before
finishing the test, ensuring that you don't
enable/disable the state manager while a
transition is running.
Test: tests pass
BUG: 139536619
Change-Id: I1e7bd6f5b135345a9a60c95fe5127b00ff3e69df
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentReorderingTest.kt
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
ap...@google.com <ap...@google.com> #48
Branch: androidx-master-dev
commit c8263b1e1289276da1b691ac05b7a1808931101c
Author: Ian Lake <ilake@google.com>
Date: Sun Aug 02 11:51:07 2020
Mirror changes in FragmentTransitionTest to transition
Update the FragmentTransitionTest suite in the
transition module to match the updated code in the
fragment module, ensuring that the tests are
parameterized to run with both the old state manager
and the new state manager.
Test: tests still pass
BUG: 139536619
Change-Id: I8c8afac8e384e1f93a44b7d7e940de374c0b8494
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> #49
Branch: androidx-master-dev
commit 8c6081e883569b5620f03d5d89648bf9b38289a9
Author: Ian Lake <ilake@google.com>
Date: Sun Aug 02 12:11:43 2020
Enable the new state manager by default
Add a note to FragmentManager.enableNewStateManager()
noting that the new state manager is enabled by default
and providing a link to the issue tracker to ensure
that developers know where to file any possible
regressions with the new state manager.
Test: all existing tests still pass
BUG: 139536619
Change-Id: I80d275cad0a2e0f4cc15c34820f63c71720e3f56
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTestUtil.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M transition/transition/src/androidTest/java/androidx/transition/FragmentTestUtil.kt
il...@google.com <il...@google.com> #50
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've filed FragmentManager.enableNewStateManager()
experimental API. Please file any regressions found with the new system as soon as possible.
sa...@gmail.com <sa...@gmail.com> #51
This seems to work (the returnTransition
) with the new state manager
Description
This would allow us to very explicitly test all of the state transitions a Fragment goes through and would make it a lot easier to make further improvements / changes to those state transitions in a sustainable way.
This should have no effect to consumers of the Fragment API as it would all be internal work.