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!
tc...@google.com <tc...@google.com>
ti...@google.com <ti...@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
lp...@google.com <lp...@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?
ti...@google.com <ti...@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.
lp...@google.com <lp...@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.
ti...@google.com <ti...@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)
lp...@google.com <lp...@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).
ti...@google.com <ti...@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.
lp...@google.com <lp...@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)
}
}
}
ti...@google.com <ti...@google.com> #11
ad...@google.com <ad...@google.com>
lp...@google.com <lp...@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.
ti...@google.com <ti...@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
ad...@google.com <ad...@google.com>
ti...@google.com <ti...@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.
ad...@google.com <ad...@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
lp...@google.com <lp...@google.com> #16
ad...@google.com <ad...@google.com> #17
if that's the case then either animation and ui are effectively part of the same version group, or animation and animation-core are separate version groups of their own and may not establish and use opt-in internal APIs between them.
ti...@google.com <ti...@google.com> #18
animation and ui are effectively part of the same version group
What would this look like? I'd rather not put a hard requirement to never use internal or experimental APIs across the two animation libs, which would be required by the other option.
ti...@google.com <ti...@google.com> #19
After some investigation, I think we can eliminate the dependency from ui to animation to simplify things a bit. This would require refactoring out the impl of animated-vector that depends on animation group into a separate module. Since the animated-vector features are experimental, this can be done post 1.0.
However, there is unfortunately another group level dependency cycle:
foundation (from foundation group) -> animation -> foundation-layout (from foundation group)
I don't see a good way to avoid this without creating hurdles that'd make animation feature development difficult. It is somewhat analogous to the group level dependency story between
lifecycle-extensions (from lifecycle group) -> fragment -> lifecycle-viewModel/livedata-core (from lifecycle group)
Louis is right that independent versioning would be difficult. Animation and foundation would need to be released in lock steps, similar to lifecycle and fragment. It's still lesser of the two evils, compared to splitting animation libs. The animation
lib requires animation-core
to add new low-level experimental APIs (for example: Transition.createChildTransition) to support high level animation features. Not allowing experimental API usage between these two libs would therefore hinder feature development.
lp...@google.com <lp...@google.com> #20
foundation (from foundation group) -> animation -> foundation-layout (from foundation group)
We have usages in Crossfade
and AnimatedVisibility
Crossfade
just uses a Box
as an implementation detail, we can probably refactor that out and just build our own simpler box for internal usage.
AnimatedVisibility
has (experimental) extensions for RowScope
and ColumnScope
, which seems more problematic.
Do these extensions need to live here? Or when the underlying APIs are stable, could they live in foundation-layout
? It seems reasonable that ColumnScope / RowScope animation implementations, live in the same place that they are defined, then we could remove this dependency inversion. I would really like to avoid the case where updating your animation dependency so you can make use of new animation APIs also ends up updating how Row behaves.
ti...@google.com <ti...@google.com> #21
I would really like to avoid the case where updating your animation dependency so you can make use of new animation APIs also ends up updating how Row behaves.
I understand the desire to make the two libs independent. I'm in full support of removing the dependency on animation from ui group.
Updating how Row behaves when updpating animation may be desired because going forward we'll lean more and more on foundation-layout to reuse some of the implementation so that animation doesn't need to reinvent the wheels and implement the same layout logic. For example, I'm planning on implementing AnimatedRow
, for which I'd prefer to reuse as much from the Row's static layout/spacing logic as possible, rather than duplicating the code. I won't be able to put something like AnimatedRow
outside of animation, because animating values not known until measure/layout is not supported in stable animation API yet.
Do these extensions need to live here? Or when the underlying APIs are stable, could they live in foundation-layout? It seems reasonable that ColumnScope / RowScope animation implementations, live in the same place that they are defined, then we could remove this dependency inversion.
That's a great question. We are just starting with the layout animation APIs. There will be more and more cases where we'd put out experiemental animation APIs, as well as their Row/Column specific variant. The Row/ColumnScope extension of AnimatedVisibility account for the majority API use for AnimatedVisiblity nowadays, because they are tailored to the specific layouts and therefore more convenient. We'd hurt the dev experience more than we gain if we had to take that (and future opportunities of) optimization away.
ad...@google.com <ad...@google.com> #22
Doris and I chatted; it looks like a promising path forward is aligning the compose-animation modules with the foundation version group and breaking the dependency from compose-ui on animation-core. The only usages in a quick survey are the experimental animated vector support, tests, and samples. If we move the experimental animated vector support to a foundation-level module that depends on animation, we can keep the compose-ui <-> compose-foundation version boundary strict.
ti...@google.com <ti...@google.com> #23
Yes, that was also what I meant in #21 by "removing the dependency on animation from ui group."
Yuichi has kindly agreed to take on the task to move the animated vector work out of ui, therefore removing ui's dependency on animation-core. We can cherry-pick that change into release branch once it lands. (
I'll fix the tests' and sample's dependency on animation from ui in a follow-up CL.
ap...@google.com <ap...@google.com> #25
Branch: androidx-main
commit c9db3b353eb3f114fde65b0eea0d3ed93b29fee7
Author: Yuichi Araki <yaraki@google.com>
Date: Tue Jun 29 11:39:30 2021
Remove AnimatedImageVector and related APIs
These need to be moved out of 'ui'.
Relnote: "AnimatedImageVector was temporarily removed in order to change the module structure."
Bug: 160602714
Test: Other tests run
Change-Id: I419062b1b225003ee594f4d8522b11bb024144d6
M compose/integration-tests/docs-snippets/src/main/java/androidx/compose/integration/docs/resources/Resources.kt
M compose/ui/ui/api/current.ignore
M compose/ui/ui/api/current.txt
M compose/ui/ui/api/public_plus_experimental_current.txt
M compose/ui/ui/api/restricted_current.ignore
M compose/ui/ui/api/restricted_current.txt
D compose/ui/ui/integration-tests/ui-demos/src/main/java/androidx/compose/ui/demos/AnimatedVectorGraphicsDemo.kt
M compose/ui/ui/integration-tests/ui-demos/src/main/java/androidx/compose/ui/demos/UiDemos.kt
D compose/ui/ui/integration-tests/ui-demos/src/main/res/drawable/ic_hourglass_animated.xml
D compose/ui/ui/samples/src/main/java/androidx/compose/ui/samples/AnimatedVectorSample.kt
D compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/graphics/vector/AnimatedImageVectorTest.kt
D compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/graphics/vector/compat/XmlAnimatedVectorParserTest.kt
D compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/graphics/vector/compat/XmlAnimatorParserTest.kt
D compose/ui/ui/src/androidAndroidTest/res/animator/complex_background.xml
D compose/ui/ui/src/androidAndroidTest/res/animator/object_animator_1d.xml
D compose/ui/ui/src/androidAndroidTest/res/animator/object_animator_2d.xml
D compose/ui/ui/src/androidAndroidTest/res/animator/property_values_holders.xml
D compose/ui/ui/src/androidAndroidTest/res/animator/set.xml
D compose/ui/ui/src/androidAndroidTest/res/drawable/avd_complex.xml
D compose/ui/ui/src/androidAndroidTest/res/drawable/vd_complex.xml
D compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/graphics/vector/compat/XmlAnimatedVectorParser.android.kt
D compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/graphics/vector/compat/XmlAnimatorParser.android.kt
D compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/graphics/vector/compat/XmlPullParserUtils.android.kt
D compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/res/AnimatedVectorResources.android.kt
D compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/res/AnimatorResources.android.kt
D compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/graphics/vector/AnimatedImageVector.kt
D compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/graphics/vector/Animator.kt
ap...@google.com <ap...@google.com> #26
Branch: androidx-main
commit fc869555e8d6ebab8d9f7fda20e20c1243114f53
Author: Doris Liu <tianliu@google.com>
Date: Mon Jun 28 21:30:02 2021
Sever ui's dependency on animation-core
Bug: 160602714
Test: Build and run tests
Relnote: "Moved InfiniteAnimationPolicy to :compose:ui"
Change-Id: I5eb09c7aa24a85fd2e66cc9b84ea6c906dc5210a
M compose/animation/animation-core/api/current.ignore
M compose/animation/animation-core/api/current.txt
M compose/animation/animation-core/api/public_plus_experimental_current.txt
M compose/animation/animation-core/api/restricted_current.ignore
M compose/animation/animation-core/api/restricted_current.txt
M compose/animation/animation-core/benchmark/build.gradle
M compose/animation/animation-core/build.gradle
M compose/animation/animation-core/src/commonMain/kotlin/androidx/compose/animation/core/InfiniteAnimationPolicy.kt
M compose/ui/ui-test-junit4/build.gradle
M compose/ui/ui-test-junit4/src/androidMain/kotlin/androidx/compose/ui/test/junit4/AndroidComposeTestRule.android.kt
M compose/ui/ui-test-junit4/src/test/kotlin/androidx/compose/ui/test/junit4/InfiniteAnimationPolicyTest.kt
M compose/ui/ui/api/current.txt
M compose/ui/ui/api/public_plus_experimental_current.txt
M compose/ui/ui/api/restricted_current.txt
M compose/ui/ui/build.gradle
M compose/ui/ui/samples/build.gradle
A compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/platform/InfiniteAnimationPolicy.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/window/Application.desktop.kt
ti...@google.com <ti...@google.com> #27
It'd be nice to enforce the lib group dependency so it can only be one-way from higher level groups on lower level groups. Filed feature request at
sh...@gmail.com <sh...@gmail.com> #28
In 1.0.0 the animatedvectorresource and the AnimatedImageVector is missing. please release it as soon as possible as it is causing issues with my app. please sugest some workaround as my app heavely depend on it.
ti...@google.com <ti...@google.com> #29
Re #28:
AnimatedVectorResource will be included in the next Compose release in 1-2 weeks in a new lib: animation-graphics
. Stay tuned! Sorry for the inconvenience.
sh...@gmail.com <sh...@gmail.com> #30
Thanks
Description
with the module moves we end up with a cycle between module groups.
animation
depends oncore
andcore
depends onanimation-core
This is due to the AnimationClock ambient. If we break this dependency then we clear the cycle