Status Update
Comments
da...@google.com <da...@google.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()) {
m....@gmail.com <m....@gmail.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> #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
m....@gmail.com <m....@gmail.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>
da...@google.com <da...@google.com>
ap...@google.com <ap...@google.com> #6
Project: platform/frameworks/support
Branch: androidx-main
Author: Daniel Santiago Rivera <
Link:
Lazily load SQLite's native library when a connection is opened.
Expand for full commit details
Lazily load SQLite's native library when a connection is opened.
Moving the load call into an inner object effectively makes it so that the library is loaded lazily when the object's class is loaded, i.e. when instantiated and accessed during the open call.
Bug: 363985585
Test: BundledSQLiteDriverTest.kt
Change-Id: I72fa01618169cb3225ea9d5d5e9f9ae59c6d4b09
Files:
- M
sqlite/integration-tests/driver-conformance-test/src/androidInstrumentedTest/kotlin/androidx/sqlite/driver/test/BundledSQLiteDriverTest.kt
- M
sqlite/sqlite-bundled/src/jvmAndroidMain/kotlin/androidx/sqlite/driver/bundled/BundledSQLiteDriver.jvmAndroid.kt
Hash: 4f69d19088dae47b6a7bcf454ea22f7e2da78e92
Date: Tue Jan 21 17:51:32 2025
da...@google.com <da...@google.com>
na...@google.com <na...@google.com> #7
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.sqlite:sqlite-bundled:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-android:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-iosarm64:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-iossimulatorarm64:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-iosx64:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-jvm:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-linuxarm64:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-linuxx64:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-macosarm64:2.5.0-alpha13
androidx.sqlite:sqlite-bundled-macosx64:2.5.0-alpha13
Description
Following the steps outlined in the official KMP Room docs (https://developer.android.com/kotlin/multiplatform/room ) , I see 5 strict mode violations in my code.
They dont seem to cause any noticable lag but i was wondering if this violation is expected?