The key event handler was installed on the activity together with the state
instance it captured, so it could keep talking to a state that is no longer the
one that is drawn. That happens in practice: the scaffold state is recreated
when one of its rememberSaveable keys changes, which it does right after the
launcher starts (the window is measured, and the state is restored after the
configuration change), and the activity then still holds the handler of the
previous state. Typing on the home screen set the search query and started the
page transition on the detached state, so the search page never appeared, while
the query showed up in the search bar.
The handler is now created without the state as a key and asks for the current
state through a provider, and the activity's handler is refreshed on every
composition instead of only when the handler instance changes.
Verified on the Titan 2: typing on the home screen opens the search page with
the character inserted, further characters append, the text field stays
unfocused and the on-screen keyboard stays hidden.
Fixes on top of -typing.2: the widget configure activity crash, the search bar
keeping the keyboard focus (and the IME) on the home screen after an app switch,
and the TextFieldValue update in SearchBar moving out of the composition.
Returning to the launcher from another app left the search bar's text field
focused, with the on-screen keyboard up. Typing on the physical keyboard then
went into the search bar - the IME commits characters to the focused text field
- while the search results never appeared, because the key event handler
deliberately leaves keys alone while the text field has the focus. Coming home
looked like the launcher had stopped responding to the keyboard; it happens with
a freshly started launcher and a plain app switch, with no search ever opened.
Give that focus up again one frame after the launcher is resumed, and hide the
on-screen keyboard, as long as the home screen is what is shown. Only on a
resume (pauseTime > 0), so that a search component used as the home screen can
still focus itself when the launcher starts.
Also set isSearchBarFocused back to false when the text field loses the focus,
like upstream does. LauncherSearchBar requests focus whenever that flag is true,
so only ever setting it to true made the text field focus itself again after it
had been unfocused - which is what kept the on-screen keyboard around.
Clear the search query before resetting the page in the resume path, so that a
stale query is gone even if the page transition is interrupted.
Note: the focus fix is a workaround for the framework/IME handing the focus back
to the text field; it is not verified on the device yet.
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.
