Status Update
Comments
mg...@google.com <mg...@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!
gr...@gmail.com <gr...@gmail.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
ma...@marcardar.com <ma...@marcardar.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?
sj...@gmail.com <sj...@gmail.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.
ha...@gmail.com <ha...@gmail.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.
th...@gmail.com <th...@gmail.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)
mg...@google.com <mg...@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).
mg...@google.com <mg...@google.com>
th...@tempo.co.nz <th...@tempo.co.nz> #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.
ju...@veepee.com <ju...@veepee.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)
}
}
}
mg...@google.com <mg...@google.com> #11
sj...@gmail.com <sj...@gmail.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
bo...@gmail.com <bo...@gmail.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.
ra...@gmail.com <ra...@gmail.com> #15
ma...@gmail.com <ma...@gmail.com> #16
fi...@gmail.com <fi...@gmail.com> #17
The ./gradlew app:dependencies --configuration releaseRuntimeClasspath
I couldn't find any Compose library resolved to alpha versions, the highest version was 1.6.5.
Is the statement correct? Or do I misinterpret it?
sj...@gmail.com <sj...@gmail.com> #18
@
Lifecycle does not have a transitive dependency on Compose since it's not strictly related to Compose. It's more like Compose 1.7 has been adjusted to Lifecycle 2.8.0. So you need to explicitly update your Compose dependencies.
mg...@google.com <mg...@google.com> #19
lifecycle-runtime-compose
2.8.* does not explicitly depend on compose-ui
1.7.* but there is a behavior compatibility issue between the versions - meaning standard POM dependency version checks will not detect the problem.
To understand the issue better, let’s go step by step on what happened:
- We have introduced a new
LocalLifecycleOwner
insidelifecycle-runtime-compose
. - We have inverted the dependency between
compose-ui
andlifecycle-runtime-compose
.- Before:
lifecycle-runtime-compose
- depends on ->compose-ui
. - After:
compose-ui
- depends on ->lifecycle-runtime-compose
.
- Before:
- We have changed the “old”
LocalLifecycleOwner
fromcompose-ui
to return the new one inlifecycle-runtime-compose
for binary compatibility.compose-ui
1.6.*, sets up the “old”LocalLifecycleOwner
at runtime.compose-ui
1.7.*, sets up the “new”LocalLifecycleOwner
at runtime.
lifecycle-runtime-compose
2.7.* needs the “old”LocalLifecycleOwner
.lifecycle-runtime-compose
2.8.* needs the “new”LocalLifecycleOwner
.
Now, when combining compose-ui
1.6.* and lifecycle-runtime-compose
2.8.* or compose-ui
1.7.* and lifecycle-runtime-compose
2.7.*, they will reference to different LocalLifecycleOwner
instances at runtime.
Since there's no direct dependency between them, standard POM checks cannot detect this issue. A call chain analysis would have been required to identify the behavior incompatibility between stable versions.
fi...@wartek.belajar.id <fi...@wartek.belajar.id> #20
mg...@google.com <mg...@google.com>
ap...@google.com <ap...@google.com> #21
Branch: androidx-main
commit 59dd212495f4378911cbb310367743b2aae734a3
Author: Marcello Galhardo <mgalhardo@google.com>
Date: Wed May 29 17:49:02 2024
Make `LocalLifecycleOwner` backward compatible with Compose 1.6.*
Lifecycle 2.8.* requires Compose 1.7.* for correctness, but
Compose 1.7.* have not yet reached stable.
For allowing Lifecycle 2.8.* to be used with Compose 1.6.*, we are
introducing the following measures:
* When Lifecycle 2.8.* detects it's running with Compose 1.6.*, it
uses reflection to access the previous version of
`androidx.compose.ui.platform.LocalLifecycleOwner`.
* A custom Proguard rule has been added to prevent the obfuscation of
`androidx.compose.ui.platform.LocalLifecycleOwner` when using
Compose 1.6.*. This ensures the reflection approach works correctly.
We have tested these backward compatibility measures in various
scenarios, including:
* Projects with and without Navigation Compose integrated.
* Compose versions 1.6.* and 1.7.*.
* Builds both with and without Proguard obfuscation applied.
Please note that backward compatibility reflection will be removed once
Compose 1.7.* is stable. A Gradle dependency constraint should be
put in place to ensure smooth migration for clients.
Fixes:
Test: manual
Change-Id: I3d0666a88eb309aae9a5c60eacc6818f52dd0bfd
M lifecycle/lifecycle-runtime-compose/build.gradle
A lifecycle/lifecycle-runtime-compose/proguard-rules.pro
A lifecycle/lifecycle-runtime-compose/src/androidMain/kotlin/androidx/lifecycle/compose/LocalLifecycleOwner.android.kt
M lifecycle/lifecycle-runtime-compose/src/commonMain/kotlin/androidx/lifecycle/compose/LocalLifecycleOwner.kt
A lifecycle/lifecycle-runtime-compose/src/desktopMain/kotlin/androidx/lifecycle/compose/LocalLifecycleOwner.desktop.kt
ca...@careem.com <ca...@careem.com> #22
Looking at the
mg...@google.com <mg...@google.com> #23
Lifecycle 2.8.1 was released last week (May 29, 2024). The workaround was merged yesterday (June 4, 2024), so it is not included in version 2.8.1. Please note that the "Date: Wed May 29" in the CL header above is a metadata that indicates when the CL was created, not when it was merged.
We intend to include it in the very next release, Lifecycle 2.8.2.
va...@cloudkitchens.com <va...@cloudkitchens.com> #24
pr...@google.com <pr...@google.com> #25
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.lifecycle:lifecycle-runtime-compose:2.8.2
androidx.lifecycle:lifecycle-runtime-compose-android:2.8.2
androidx.lifecycle:lifecycle-runtime-compose-desktop:2.8.2
li...@gmail.com <li...@gmail.com> #26
eg...@gmail.com <eg...@gmail.com> #27
Can confirm, the issue reproduces on release build
[Deleted User] <[Deleted User]> #28
ma...@gmail.com <ma...@gmail.com> #29
kr...@gmail.com <kr...@gmail.com> #30
Same for me too. I updated the Lifecycle lib to v2.8.2 and Compose BOM to v2024.06.00 which incorporate v1.6.8 of Compose libs. Still, the app got this exception and crashed, but only in the release mode and not in debug mode. Unfortunately, I got the crash in the production app after its release. After downgrading the Lifecycle lib to v2.7.0, it is working fine in the production app. Immediately, I had to release another patch version, so the users do not complain about app not working.
mg...@google.com <mg...@google.com> #31
We have received a similar report at -keep class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt { *; }
to your ProGuard rules).
Although we have included a custom ProGuard rule as part of our fix, the rule is not working as intendend across all projects. We are currently investigating the problem, see
ba...@gmail.com <ba...@gmail.com> #32
Updating to 2.8.2 with Compose BOM "2024.06.00" the app is crashing on Release build with the error "CompositionLocal LocalLifecycleOwner not present".
A proguard rules should be provided or another version with fix.
su...@gmail.com <su...@gmail.com> #33
However, for the visitors
"-keep class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt { *; }"
Add this to your app proguard file and it'll work fine.
ih...@enverus.com <ih...@enverus.com> #34
mo...@gmail.com <mo...@gmail.com> #35
I can confirm it's still an issue for me with Compose BOM "2024.06.00" and lifecycle 2.8.2.
I added these lines to proguard to fix the issue:
-if public class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt {
public static *** getLocalLifecycleOwner();
}
-keep public class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt {
public static *** getLocalLifecycleOwner();
}
mg...@google.com <mg...@google.com> #36
Following up on the issue mentioned in
mg...@google.com <mg...@google.com> #37
Following up on the issue mentioned in
mg...@google.com <mg...@google.com> #38
Lifecycle 2.8.3 is now available on
pr...@google.com <pr...@google.com> #39
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.lifecycle:lifecycle-runtime-compose:2.9.0-alpha01
androidx.lifecycle:lifecycle-runtime-compose-android:2.9.0-alpha01
androidx.lifecycle:lifecycle-runtime-compose-desktop:2.9.0-alpha01
Description
Version used:
lifecycle-runtime-compose:2.8.0-alpha03
androidx.compose.ui:ui-android:1.7.0-alpha03
When
Devices/Android versions reproduced on: Android14
When running collectAsStateWithLifecycle in setContent inside the fragment, the following error occurs.
Could any of the changes in lifecycle 2.8.0-alpha03 be caused by LocalLifecycleOwner's has different directory?
"LocalLifecycleOwner moved from Compose UI to lifecycle-runtime-compose so that its Compose-based helper APIs can be used outside of Compose UI"
java.lang.IllegalStateException: CompositionLocal LocalLifecycleOwner not present
at androidx.lifecycle.compose.LocalLifecycleOwnerKt$LocalLifecycleOwner$1.invoke(LocalLifecycleOwner.kt:26)
at androidx.lifecycle.compose.LocalLifecycleOwnerKt$LocalLifecycleOwner$1.invoke(LocalLifecycleOwner.kt:25)
at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
at androidx.compose.runtime.LazyValueHolder.getCurrent(ValueHolders.kt:29)
at androidx.compose.runtime.LazyValueHolder.getValue(ValueHolders.kt:31)
at androidx.compose.runtime.CompositionLocalMapKt.read(CompositionLocalMap.kt:90)
at androidx.compose.runtime.ComposerImpl.consume(Composer.kt:2135)
at androidx.lifecycle.compose.FlowExtKt.collectAsStateWithLifecycle(FlowExt.kt:180)