Status Update
Comments
so...@google.com <so...@google.com>
rh...@gmail.com <rh...@gmail.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!
rh...@gmail.com <rh...@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
rh...@gmail.com <rh...@gmail.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?
an...@google.com <an...@google.com>
se...@gmail.com <se...@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.
[Deleted User] <[Deleted User]> #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.
se...@gmail.com <se...@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)
se...@gmail.com <se...@gmail.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).
lu...@perrystreet.com <lu...@perrystreet.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.
zh...@gmail.com <zh...@gmail.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)
}
}
}
jo...@muzz.com <jo...@muzz.com> #11
lu...@gmail.com <lu...@gmail.com> #12
lu...@gmail.com <lu...@gmail.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
lu...@gmail.com <lu...@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.
rh...@gmail.com <rh...@gmail.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
lu...@gmail.com <lu...@gmail.com> #16
lu...@gmail.com <lu...@gmail.com> #17
fl...@polarsteps.com <fl...@polarsteps.com> #18
So this essentially means that every app out there, which is in any of its activities using ComposeView(s)
will leak those activities. Seems like a P1 to me.
ve...@gmail.com <ve...@gmail.com> #19
Could be related to
There is a small demo project simulating any number of leaks (using fragment and further activities). This is a major issue, which blocking us from releasing many features using compose. They have reproducibility 100%, and have potentially huge impact on memory and performance. Could you please bump this issues to P1?
mo...@gmail.com <mo...@gmail.com> #20
ve...@gmail.com <ve...@gmail.com> #21
From
on 14/02/2023: issue 264389670
Please note that ComposeView is not the prerequisite for this leak, but the changing of the mutable state during hiding of composition in first activity. Although, the root cause could be the same, but this issue doesn't assume any root cause, but provides the setup for replication. Fragment is also not required. I will attach new setup, which does use only just 3 activities. And that's enough for memory leak.
Replication
- From MainActivity go to IntermediateActivity
- From IntermediateActivity go to ComposeActivity
- From ComposeActivity go back
- Checking profiler. Have memory leak
se...@journiapp.com <se...@journiapp.com> #22
ve...@gmail.com <ve...@gmail.com> #23
Any mutable state change during composition hiding is enough for replication. The impact is drastic: all subsequent compose activities are stucking in the memory, and just piling up.
wu...@gmail.com <wu...@gmail.com> #24
lu...@gmail.com <lu...@gmail.com> #25
See $lambda-1$1 in the profiler
ComposableSingletons$Maintiner1Activitykt$lambda-1$1
ComposableSingletons$Maintiner1Activitykt$lambda-2$1
mg...@a-bly.com <mg...@a-bly.com> #26
as...@google.com <as...@google.com> #27
The memory leak is caused by an edge case, when the activity is stopped while Recomposer
is holding some pending state for composition. By default, MonotonicClock
used in Recomposer
is Recomposer
has already queued an update before activity was stopped, and it continues to accumulate states from other activities until the first activity is restarted or destroyed. The issue is quite deeply rooted, as the fix is likely to change how compositions record states in background, so we are targeting next release for the fix.
If you are affected by this issue in the meantime, consider specifying a custom WindowRecomposerFactory
in your app that doesn't pause MonotonicClock
(or unpauses it periodically). The side effect of such custom Recomposer
is that compositions will continue running animations when activity is in background.
ap...@google.com <ap...@google.com> #28
Branch: androidx-main
commit 66fef38b1d11e0c48b11137e6c3d007909f4a2d1
Author: Chuck Jazdzewski <chuckj@google.com>
Date: Wed Mar 29 13:51:01 2023
ON_STOP should pause the frame clock broadcasts instead of composition
When an Android window receives an ON_STOP noficiation it would pause
the pausable clock it created for its recomposer. This has the effect
of pausing all compositions and causes the recomposer to collect change
nofications from the snapshot sustem in an unbounded collection.
With this change, windows that receive ON_STOP will now only pause the
frame clock broadcasts which has the effect of blocking withFrameNanos
that is used by animations. This means animations stop advancing but
composition is allowed to continue allowing the recomposer to drain the
notifications from the snapshot system.
Relnote: """The recomposer created for an Android window will now
only block calls to `withFrameNanos` instead of all composition when it
receives an ON_STOP notification. This means windows associated with
stopped activites will continue to recompose for data changes but the
animations, or any other caller of withFrameNanos, will block."""
Fixes: 240975572
Test: ./gradlew :compose:r:r:tDUT
Change-Id: Id9e7fe262710544a48c2e4fc5fcbf1d27bfaa1ba
M compose/runtime/runtime/api/current.txt
M compose/runtime/runtime/api/public_plus_experimental_current.txt
M compose/runtime/runtime/api/restricted_current.txt
M compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/Recomposer.kt
M compose/runtime/runtime/src/commonTest/kotlin/androidx/compose/runtime/RecomposerTests.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/WindowRecomposer.android.kt
ma...@xapo.com <ma...@xapo.com> #29
This leak is happening for us on every screen migrated to Compose and would like to check any alpha version for the fix.
ch...@google.com <ch...@google.com> #30
This is in android-main
which is now the 1.5 branch. It should be out with the next alpha of 1.5 but not stable until 1.5 is stable.
pr...@google.com <pr...@google.com> #31
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.runtime:runtime:1.5.0-alpha03
androidx.compose.ui:ui:1.5.0-alpha03
lu...@gmail.com <lu...@gmail.com> #32
androidx.compose.runtime:runtime:1.5.0-alpha03
androidx.compose.ui:ui:1.5.0-alpha03
But the problems still exists
ComposableSingletons$Activitykt$lambda-1$1. never are released . The Activity is released. but the composables are always keep it in memory, so its seems to be a kind of memory leak
lu...@gmail.com <lu...@gmail.com> #33
aa...@gmail.com <aa...@gmail.com> #34
How does version 1.4.x handle this bug?
xu...@gmail.com <xu...@gmail.com> #35
[Deleted User] <[Deleted User]> #37
ch...@google.com <ch...@google.com> #38
Lambdas like ComposableSingletons$Maintiner1Activitykt$lambda-1$1
, as the name implies, are lazy allocated singleton instances that are stored globally. They will only be allocated once. This is not addressed by the above fix because it is not a leak but a singlton.
lu...@gmail.com <lu...@gmail.com> #39
lu...@gmail.com <lu...@gmail.com> #40
lu...@gmail.com <lu...@gmail.com> #41
ComposableSingletons$Activitykt$lambda-1$1. that keep in memory
I think is part of the composable framework
Description
Jetpack Compose version: 1.2.0
Android Studio Build: Android Studio Chipmunk | 2021.2.1 Patch 1
Kotlin version: 1.7.0
Steps to Reproduce or Code Sample to Reproduce:
Opening and closing an Activity that uses
ComposeView
causes memory leak. Here's sample code used:LeakCanary points to
Recomposer.snapshotInvalidations
.Stack trace: