SearchBar keeps a TextFieldValue so that the cursor ends up behind text that was
changed from the outside (a search started by typing on a physical keyboard, or
a reset search). That value was updated during composition, which is an
anti-pattern: the value read earlier in the same composition is what gets drawn,
so the write only schedules another recomposition pass of the search bar - and
it can be dropped entirely if the composition does not complete.
Do the same update in a SideEffect, after the composition. No behaviour change
for the user.
A widget can advertise WIDGET_FEATURE_RECONFIGURABLE without providing a
configure activity (or the app providing it was uninstalled since). Tapping
"Configure widget" then made
AppWidgetHost.startAppWidgetConfigureActivityForResult throw, which killed the
launcher:
android.content.ActivityNotFoundException: No Activity found to handle null
at android.app.Activity.startIntentSenderForResult
at android.appwidget.AppWidgetHost.startAppWidgetConfigureActivityForResult
at ConfigureWidgetSheetKt.ConfigureAppWidget$lambda$10$1$0(ConfigureWidgetSheet.kt:812)
This happened three times on the Titan 2 on 2026-09-10 (19:55, 19:57 and 20:03,
the last one 28 seconds after boot). Catch ActivityNotFoundException, and
SecurityException for a configure activity that refuses to be started, and log
instead. Upstream main still has the same unguarded call.
Two fixes on top of the type-to-search feature:
- The search no longer survives leaving the launcher. Upstream only resets the
search when the launcher was in the background for more than five seconds, so
a quick app switch or a fast return from a launched app left the old query on
screen. The search page is now always reset, whatever the pause was.
- Dismissing the search page ends the keyboard driven search. Without that the
flag stayed set, so opening the search later (gesture or search bar) did not
focus the text field and the soft keyboard stayed away.
Version 1.40.2-typing.2.
Typing on a physical keyboard while the home screen is shown now opens the
search page and inserts the typed character, so the launcher can be used
without touching the screen. It works for any printable key, appends the
characters in order even when the user types faster than the launcher can
recompose, and the search bar can still be tapped to edit the query with
the on-screen keyboard as usual.
While the search is driven by the keyboard, the search bar's text field is
left unfocused on purpose: a focused text field would make the system show
the on-screen keyboard, which is not wanted when there is a physical
keyboard. The handler therefore inserts and deletes characters itself,
including backspace and enter (to launch the best match).
The behaviour is controlled by a new "Search on typing" preference in
Settings -> Search, which is enabled by default.
Implementation notes:
- The key events are intercepted in SharedLauncherActivity.dispatchKeyEvent,
which is the only place that sees hardware key events while no view has
focus. The scaffold installs the handler while it is shown.
- Key events are not forwarded to the search bar's text field, so the
characters are inserted into the search view model directly.
- SearchBar keeps a TextFieldValue instead of a String so that the cursor
moves to the end of the text when the value is changed from the outside.
Without this the next typed character ended up in front of the text.
