Fixed
Status Update
No update yet.
Comments
se...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: George Mount <
Link:
Fix focus move within child AndroidViews
Expand for full commit details
Fix focus move within child AndroidViews
Fixes: 389994198
Fixes: 391378895
Relnote: "Fixes focus travel within child AndroidViews where it
can sometimes jump out of the child to the ComposeView"
Sometimes the native FocusFinder doesn't act properly and finds
the wrong View when searching. This CL changes the FocusFinder to
use a newer copy of FocusFinder for all focus search operations
in AndroidComposeView.
Test: new test, manual testing
Change-Id: I678c864afe086879c5c45b018dd82da4f23be440
Files:
- M
compose/ui/ui/src/androidInstrumentedTest/AndroidManifest.xml - M
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/focus/FocusListenerTest.kt - A
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/test/TestActivity2.kt - A
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/viewinterop/MixedFocusChangeTest.kt - M
compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidComposeView.android.kt - M
compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/FocusFinderCompat.android.kt
Hash: b028bcc322095634123da91c7146bac9e23c13c7
Date: Tue Jan 14 13:48:11 2025
mm...@commonsware.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Ralston Da Silva <
Link:
Disabling isViewFocusFixEnabled and isRemoveFocusedViewFixEnabled
Expand for full commit details
Disabling isViewFocusFixEnabled and isRemoveFocusedViewFixEnabled
Disabling these flag to unblock 1.8 RC.
These were features/bug-fixes that were not regressions
from 1.7
Bug: 406327273
Bug: 369256395
Bug: 378570682
Bug: 376142752
Bug: 384056227
Bug: 388590015
Bug: 389994198
Bug: 391378895
Test: Ran presubmits and added TODOs to the affected tests
Change-Id: I5ffb7ff27c662838c8b464560d1df830751f015c
Files:
- M
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/focus/FocusViewInteropTest.kt - M
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/focus/OwnerFocusTest.kt - M
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/focus/RequestFocusTest.kt - M
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/viewinterop/MixedFocusChangeTest.kt - M
compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/ComposeUiFlags.kt
Hash: 1a33d21734ef7f68d4cad37c8d333831f304a339
Date: Tue Apr 01 17:46:50 2025
yb...@google.com
this missed the deadline for 1.0.0. We'll fix it, meanwhile, you can just provide an empty migration that does not do anything.
yb...@google.com
this is actually partially correct as someone can write a query like:
select * from foo group by 1;
but we don't enforce column order for migrations and writing a query like that does not seem like the right thing to do so we'll fix this.
select * from foo group by 1;
but we don't enforce column order for migrations and writing a query like that does not seem like the right thing to do so we'll fix this.
yb...@google.com
this is fixed for the next version.
note that, you still need a version upgrade to get the new behavior since we didn't want to change the existing schema files.
note that, you still need a version upgrade to get the new behavior since we didn't want to change the existing schema files.
Description
Version used: 1.0.0-alpha8
If I change the order of the member variables within an @Entity Class, I am forced to provide a migration.
Before:
@Entity(tableName = "contacts")
public class ContactEntity {
@PrimaryKey(autoGenerate = true)
private Long id;
@ColumnInfo(name = "phone")
private String phone;
@ColumnInfo(name = "name")
private String name;
@ColumnInfo(name = "mail")
private String mail;
}
After:
@Entity(tableName = "contacts")
public class ContactEntity {
@PrimaryKey(autoGenerate = true)
private Long id;
@ColumnInfo(name = "name")
private String name;
@ColumnInfo(name = "phone")
private String phone;
@ColumnInfo(name = "mail")
private String mail;
}
Is this intended behaviour?
If yes, how would such a migration look like?