Status Update
Comments
st...@google.com <st...@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!
fe...@gmail.com <fe...@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
st...@google.com <st...@google.com>
st...@google.com <st...@google.com>
ss...@google.com <ss...@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?
fe...@gmail.com <fe...@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.
st...@google.com <st...@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.
st...@google.com <st...@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)
st...@google.com <st...@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).
st...@google.com <st...@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.
st...@google.com <st...@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)
}
}
}
ys...@google.com <ys...@google.com> #11
st...@google.com <st...@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.
pe...@google.com <pe...@google.com> #13
Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
We collect informations only from the device on which IllegalArgumentException happened.
Our latest app uses CameraX version 1.0.0-beta10
and this issue still occurres.
However we don't receive crash report from Fujitsu arrows Be F-05J
or Fujitsu arrows M04
so far. (This doesn't mean this issue is fixed on these devices because our app is heavily rely on camera so these device's user wouldn't use our app anymore.)
Instead, we receive crash report from
- Model : Fujitsu F-03K
- Android Version : 7.1.2
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0 : 480x480
CameraId 1 : 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
ap...@google.com <ap...@google.com> #14
I missed some settings when I simulated the issue by robolectric test so that I was not able to reproduce it. Now, I can reproduce the issue if the device only supports one 480x480 resolution. I'm working on the solution and target to make it included in next release.
pe...@google.com <pe...@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
st...@google.com <st...@google.com> #16
fe...@gmail.com <fe...@gmail.com> #17
fe...@gmail.com <fe...@gmail.com> #18
ref:
st...@google.com <st...@google.com> #19
Nothing seems obviously wrong. This is our demo, which definitely allows the user to tap first time:
@Composable
fun PagerWithIndicator(swipeState: SwipeToDismissBoxState) {
val pagesCount = 3
val pagerState = rememberPagerState { pagesCount }
var background by remember { mutableStateOf(Color.Black) }
var selectedPage by remember { mutableIntStateOf(0) }
val animatedSelectedPage by animateFloatAsState(
targetValue = pagerState.targetPage.toFloat(), label = "page-indicator",
) {
selectedPage = it.toInt()
}
val pageIndicatorState: PageIndicatorState = remember {
object : PageIndicatorState {
override val pageOffset: Float
get() = animatedSelectedPage - selectedPage
override val selectedPage: Int
get() = selectedPage
override val pageCount: Int
get() = pagesCount
}
}
Box(modifier = Modifier.background(background)) {
HorizontalPager(
modifier = Modifier.fillMaxSize().edgeSwipeToDismiss(swipeState),
state = pagerState,
flingBehavior =
PagerDefaults.flingBehavior(
pagerState,
snapAnimationSpec = tween(150, 0),
)
) { page ->
val scrollState = rememberScalingLazyListState()
ScalingLazyColumn(
state = scrollState,
modifier = Modifier.fillMaxWidth()
) {
item {
ListHeader { Text("Page $page") }
}
items(4) {
Row(
modifier = Modifier.fillMaxWidth(),
horizontalArrangement = Arrangement.Center
) {
Chip(
onClick = {
background =
if (background == Color.Black) Color.DarkGray else Color.Black
},
label = {
Text(text = "Click", color = Color.Black)
},
enabled = !pagerState.isScrollInProgress
)
}
}
}
}
HorizontalPageIndicator(
pageIndicatorState = pageIndicatorState,
)
}
}
fe...@gmail.com <fe...@gmail.com> #20
I tried your code, but it keeps crashing after a swipe (to change page).
FATAL EXCEPTION: main
Process: com.feduss.horizontalpagerbug, PID: 6215
java.lang.IllegalStateException: The offset was read before being initialized. Did you access the offset in a phase before layout, like effects or composition?
at androidx.wear.compose.foundation.SwipeableV2State.requireOffset(SwipeableV2.kt:299)
at androidx.wear.compose.foundation.SwipeableV2State.settle(SwipeableV2.kt:457)
at androidx.wear.compose.foundation.SwipeToDismissBoxState$Companion$edgeNestedScrollConnection$1.onPostFling-RZ2iAVY(BasicSwipeToDismissBox.kt:380)
at androidx.compose.ui.input.nestedscroll.NestedScrollNode.onPostFling-RZ2iAVY(NestedScrollNode.kt:105)
at androidx.compose.ui.input.nestedscroll.NestedScrollDispatcher.dispatchPostFling-RZ2iAVY(NestedScrollModifier.kt:221)
at androidx.compose.foundation.gestures.ScrollingLogic$onDragStopped$performFling$1.invokeSuspend(Scrollable.kt:810)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.internal.ScopeCoroutine.afterResume(Scopes.kt:32)
at kotlinx.coroutines.AbstractCoroutine.resumeWith(AbstractCoroutine.kt:102)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:46)
at kotlinx.coroutines.internal.ScopeCoroutine.afterResume(Scopes.kt:32)
at kotlinx.coroutines.AbstractCoroutine.resumeWith(AbstractCoroutine.kt:102)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:46)
at kotlinx.coroutines.UndispatchedCoroutine.afterResume(CoroutineContext.kt:270)
at kotlinx.coroutines.AbstractCoroutine.resumeWith(AbstractCoroutine.kt:102)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:46)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
at androidx.compose.ui.platform.AndroidUiDispatcher.performTrampolineDispatch(AndroidUiDispatcher.android.kt:81)
at androidx.compose.ui.platform.AndroidUiDispatcher.access$performTrampolineDispatch(AndroidUiDispatcher.android.kt:41)
at androidx.compose.ui.platform.AndroidUiDispatcher$dispatchCallback$1.run(AndroidUiDispatcher.android.kt:57)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7898)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [androidx.compose.ui.platform.MotionDurationScaleImpl@133984, androidx.compose.runtime.BroadcastFrameClock@3cde56d, StandaloneCoroutine{Cancelling}@9e015a2, AndroidUiDispatcher@84cc233]
---------------------------------
implementation ("androidx.wear.compose:compose-ui-tooling:1.3.0-beta02")
implementation("androidx.wear.compose:compose-foundation:1.3.0-beta02")
implementation("androidx.wear.compose:compose-material:1.3.0-beta02")
implementation("androidx.wear.compose:compose-navigation:1.3.0-beta02")
I also tested with latest stable version 1.2.1, and i got the same error.
st...@google.com <st...@google.com>
ag...@google.com <ag...@google.com>
st...@google.com <st...@google.com>
le...@google.com <le...@google.com> #21
Project: platform/frameworks/support Branch: androidx-main
commit 418f3a6588d2384e49d996cebcb2d5678ceeb3ea
Author: Levi Albuquerque
Click on moving list initial issue
Due to an early fix we were prioritizing continuing the scroll of nested lists in any direction when taping on a parent list. The actual intended behavior was to consider nested children that scroll -on the same direction- if the click happened on the said child. In this CL I'm reverting those changes as we will revisit the nested scrolling UX and there will be more benefits to having the original behavior without the issues the fix introduced.
Test: Added test to check behavior.
Relnote: N/A
Fixes: 293777304
Fixes: 289685606
Fixes: 296064317
Bug: 175010956
Bug: 179417109
Change-Id: Ia71ed02e06603c6c27ad4648cfc8e32587397d63
M compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/ScrollableTest.kt M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/Scrollable.kt
le...@google.com <le...@google.com> #22
Hey @stevebower @pedrobatista could you verify if this fixes the issue for wear foundation? Thanks!
st...@google.com <st...@google.com> #23
Ok, I'll take a look at this.
st...@google.com <st...@google.com> #24
Still not fixed, if we remove our custom animation override, the pager takes a while to settle:
(edited to upload a gif for ease of reference)
st...@google.com <st...@google.com>
le...@google.com <le...@google.com> #25
Hi @stevebower just bringing the chat conversation we've had to this bug for visibility. In order to update the behavior in Foundation Pager with some good default spring animation (that also works for wear devices) we need wear compose to provide a good visibility threshold to be used here.
st...@google.com <st...@google.com>
ap...@google.com <ap...@google.com> #26
Branch: androidx-main
commit 1f395a390184dad8164957e44bfc1483ffe3f53e
Author: Levi Albuquerque <levima@google.com>
Date: Thu May 09 09:28:40 2024
Improve Pager default snapping animation.
Specifying a visibility threshold for Pager improves the alignment of the visual representation of the end of a snapping operation with the actual PagerState interpretation of a scrolling Pager. It takes now twice less time between the time the Pager "looks settled" with the indication that it stopped scrolling "isScrollInProgress=false" which should signal to the user that they can interact with the screen.
Test: Previous tests should pass.
Fixes: 338710348
Bug: 303807950
Relnote: N/A
Change-Id: I9627a48d53604a0919951fa4dbb74717ba30bd28
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/pager/Pager.kt
ak...@google.com <ak...@google.com>
ap...@google.com <ap...@google.com> #27
Project: platform/frameworks/support
Branch: androidx-main
Author: Aman Khosa <
Link:
Change Wear Compose foundation pager snapAnimationSpec
Expand for full commit details
Change Wear Compose foundation pager snapAnimationSpec
Currently the snapAnimationSpec is set to a tween with a duration
of 150ms. This was set to ensure the Pager settles quickly so that
contents are focused and clickable, see b/345191109.
However a tween animation causes an ugly double jump when flinging
fast to the top or bottom of a SLC inside of a VerticalPager, see
b/349781047.
Changing to a Spring animation with no bounciness and high
stiffness achieves the same behaviour of settling quickly, and
avoids the double jump. Added a test to ensure this is the case.
Bug: 303807950
Bug: 345191109
Bug: 350466286
Bug: 349781047
Test: Added test case to PagerTest.kt
Change-Id: I9bfefca9998e856279d63d2595f3bed0d67639bb
Files:
- M
wear/compose/compose-foundation/src/androidTest/kotlin/androidx/wear/compose/foundation/PagerTest.kt
- M
wear/compose/compose-foundation/src/main/java/androidx/wear/compose/foundation/pager/Pager.kt
Hash: 335faecba455a29d7a21c5e369b7c95ee4a5c1ce
Date: Thu Oct 24 12:42:02 2024
ak...@google.com <ak...@google.com> #28
Please use the Wear HorizontalPager component which settles with a faster animation than the default Compose Foundation HorizontalPager.
gr...@google.com <gr...@google.com> #29
ap...@google.com <ap...@google.com> #30
Project: platform/frameworks/support
Branch: androidx-main
Author: Aman Khosa <
Link:
Change Wear foundation pager snapAnimationSpec
Expand for full commit details
Change Wear foundation pager snapAnimationSpec
Currently the snapAnimationSpec is set to a tween with a duration
of 150ms. This was set to ensure the Pager settles quickly so that
contents are focused and clickable, see b/345191109.
However a tween animation causes an ugly double jump when flinging
fast to the top or bottom of a SLC inside of a VerticalPager, see
b/349781047.
Changing to a Spring animation with no bounciness and high
stiffness achieves the same behaviour of settling quickly, and
avoids the double jump. Added a test to ensure this is the case.
Test to ensure the Pager settles quickly can be ran locally.
Bug: 303807950
Bug: 345191109
Bug: 350466286
Bug: 349781047
Test: Added test case to PagerTest.kt
Relnote: "Change pager snapAnimationSpec from Tween to Spring"
Change-Id: I10d0275b7f3b957af279893d2ed52d63e42b8115
Files:
- M
wear/compose/compose-foundation/api/current.txt
- M
wear/compose/compose-foundation/api/restricted_current.txt
- M
wear/compose/compose-foundation/src/androidTest/kotlin/androidx/wear/compose/foundation/PagerTest.kt
- M
wear/compose/compose-foundation/src/main/java/androidx/wear/compose/foundation/pager/Pager.kt
Hash: 2850a0327fe61851a8f53f70add7b5a0e3b11228
Date: Thu Oct 24 12:42:02 2024
gr...@google.com <gr...@google.com> #31
na...@google.com <na...@google.com> #32
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.wear.compose:compose-foundation:1.5.0-alpha06
Description
Version used: horologist 0.5.7 (Wear Compose 1.3 alpha)...the bug is compose 1.2 stable (horologist v.0.4.x)
Devices/Android versions reproduced on: wear os emulator (sdk 26, 30 and 33)
If this is a bug in the library, we would appreciate if you could attach:
- Sample project to trigger the issue. -->
- A screenrecord or screenshots showing the issue (if UI related). --> See the attachment
Description:
I have a pagerscreen with 4 pages, 3 of those have a scaling lazy column.
I manually implemented 3 differents column state to maintain the scroll state, but i have a focus problem.
In particular, when i switch page with an horizontal swipe, the elements in the page are tappable only after a vertical scroll instead of with the first tap on screen.