Two papercuts in the search added in the previous commits, both found by using it.
BrowserContent decided between the volume list and a folder listing on path == null alone, so on the "Storage" screen the roots were drawn over the answer: a search everywhere from there was computed and never shown. The switch now also asks whether a search is running - its results are full paths, so nothing has to be open first - and the volume list is drawn only when there is neither a folder nor a search.
Opening the field on that screen also switches the scope to everywhere, since "this folder" has no meaning with no folder open and the field's hint would otherwise invite a query that could never match. The view model makes the same fallback on its own, so a query typed from the volume list is answered everywhere whether or not the scope was switched.
Tapping the search action now focuses the field and brings the keyboard with it, waiting for the frame the field appears in, because focusing a node that is not attached yet does nothing. Asking the user to tap the box they just opened was a tap of pure ceremony.
The wide layout no longer focuses the first root while a search is running, which would have moved the detail pane under the results.
289 JVM tests, lint clean, release APK builds. No device pass: /dev/kvm is still absent from this environment, so the emulator cannot start - the focus change in particular is verified by compile and by reading the API contract, not by watching a keyboard appear.
SoftwareApp
90806fa3cc