Status Update
Comments
ni...@gmail.com <ni...@gmail.com> #2
The issue turns out to be a problem with how the requestFocus()
was being called. in updateFocusRectInWindowSnapshot
, there is a check for isFocused
that should also consider hasFocus()
. The line should be changed from:
if (!view.isFocused) {
to
if (!view.isFocused && !view.hasFocus()) {
da...@google.com <da...@google.com> #3
Resolved the original issues by using the correct rect value. However the focus shouldn't skip focus even with incorrect value. re-open the issue for investigation purpose. Thank you!
da...@google.com <da...@google.com>
da...@google.com <da...@google.com> #4
Project: platform/frameworks/support
Branch: androidx-main
Author: George Mount <
Link:
Fix requestFocus with bad previous rectangle
Expand for full commit details
Fix requestFocus with bad previous rectangle
Fixes: 388590015
When requestFocus() is called on a ComposeView with a previousRect
set to something that doesn't make sense (empty rectangle from the
wrong direction, for example), the previous behavior would not
find a matching component in that direction. Instead, it would
find the next View to focus on and pass the focus on.
With this CL, if the ComposeView isn't currently focused and a
focusSearch fails to find something focusable in relation to the
previous rectangle, an attempt is made irrespective of the
previous rectangle.
Relnote: "Fixed focus issue where requestFocus() with a
nonsensical previouslyFocusedRect parameter (related to
the focus direction) would skip past a ComposeView."
Test: new test, manual testing
Change-Id: Ifdc2f17b23620d1ae14848624f447f84cc1b0b5d
Files:
- M
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/focus/RequestFocusTest.kt
- M
compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidComposeView.android.kt
Hash: 8501eec732d61bd71c385a90f58a194191816d57
Date: Fri Jan 10 11:04:59 2025
ap...@google.com <ap...@google.com> #5
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.ui:ui-android:1.8.0-beta01
androidx.compose.ui:ui-jvmstubs:1.8.0-beta01
androidx.compose.ui:ui-linuxx64stubs:1.8.0-beta01
da...@google.com <da...@google.com>
pr...@google.com <pr...@google.com> #6
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.room:room-runtime:2.7.0-alpha12
androidx.room:room-runtime-android:2.7.0-alpha12
androidx.room:room-runtime-iosarm64:2.7.0-alpha12
androidx.room:room-runtime-iossimulatorarm64:2.7.0-alpha12
androidx.room:room-runtime-iosx64:2.7.0-alpha12
androidx.room:room-runtime-jvm:2.7.0-alpha12
androidx.room:room-runtime-linuxarm64:2.7.0-alpha12
androidx.room:room-runtime-linuxx64:2.7.0-alpha12
androidx.room:room-runtime-macosarm64:2.7.0-alpha12
androidx.room:room-runtime-macosx64:2.7.0-alpha12
Description
Component used: Room Version used: 2.2.6 Devices/Android versions reproduced on: Samsung Galaxy 8(Android 8.0/9.0) Samsung Galaxy 9(Android 8.0/9.0)
InvalidationTracker
uses in memory temp table( "CREATE TEMP TABLE ....") to notify about changes in tables; Declaring temp table for sqlite in WAL mode on some Samsung devices results inSQLiteConnectionPool.mMaxConnectionPoolSize
being set to 1 (although, It should be at least 2 in WAL mode)So accessing to database in multiple threads cause to lock of threads. See logs:
SQLiteConnectionPool: The connection pool for database '<name of database>' has been unable to grant a connection to thread with flags 0x5 for 30.0010004 seconds. Connections: 0 active, 1 idle, 0 available