Tell the phone's keyboard these are secrets, and get it off the box

Five boxes on this head take a secret and every one of them was drawing dots
and saying nothing. `PasswordChar` is a screen property: Windows has no opinion
about what is being typed into a text box, so the desktop head needs nothing
more. Android's software keyboard has an opinion, and left at its default it
read a vault passphrase as prose — completions offered in the suggestion strip
above the box, and the passphrase itself learned into the IME's dictionary.
Dots on screen with a word bar over them is the worst of both: hidden from the
person typing it and offered to the room. `TextInputOptions.ContentType` is the
property the Android backend maps onto `InputType`, and it is what turns both
off. Both attributes now live in one `TextBox.secret` class rather than being
repeated per box, because they are two halves of one fact and the next box
added would have got one of them.

The keyboard also went on covering whichever box had raised it. That is in
`PhoneShell` rather than on each screen: everything the phone draws is inside
its one root panel, so a bottom margin shortens all eleven screens at once, and
a screen added later cannot forget to handle something it never had to know
about.

Two mechanisms, and it matters that neither is a backstop for the other. Before
Android 15 the activity now declares `AdjustResize` and the platform shortens
the window itself; left unspecified Android chooses, and what it chooses for a
window whose entire content is one native view — which is what an Avalonia
surface is — is to pan, sliding the window by however much it thinks the
focused native view needs and leaving the box exactly where it was. That was
the bug. From Android 15 the attribute is ignored, edge-to-edge being enforced
and the window no longer resized for the keyboard at all, and the reported
inset is what there is. Each is dead where the other applies — where the window
resizes, the inset arrives already consumed and measures zero — which is why
the margin comes from the inset alone. Both added together would strand the
interface an entire keyboard above the keyboard.

Scrolling the box back into view keys off the size change rather than off
either mechanism. `ScrollViewer` already brings a newly focused child into
view; what it cannot know is that the visible region shrank after the focus,
and both ways of losing that region end in the same resize.

None of it is reachable by a test. The software keyboard is an inset the
platform reports and a headless top level reports none, so phase 10 of
`docs/manual-checks.md` is the whole of the verification — including the note
to run it on one device each side of Android 15, since a build exercised on
only one of the two will look correct and be half broken.

src/DodoSSH.Client.Android/Views/EnrollScreen.axaml

@@ -24,11 +24,11 @@
                  Text="This passphrase encrypts your vault on this phone and on the server. Nothing can recover it — not the operator, not a reset link. A recovery code follows, and losing both makes the vault unopenable." />
 
       <TextBlock Classes="label" Text="PASSPHRASE" Margin="0,20,0,0" />
-      <TextBox Classes="field" Margin="0,6,0,0" Text="{Binding Passphrase}" PasswordChar="•"
+      <TextBox Classes="field secret" Margin="0,6,0,0" Text="{Binding Passphrase}"
                IsEnabled="{Binding !IsBusy}" />
 
       <TextBlock Classes="label" Text="CONFIRM" Margin="0,14,0,0" />
-      <TextBox Classes="field" Margin="0,6,0,0" Text="{Binding ConfirmPassphrase}" PasswordChar="•"
+      <TextBox Classes="field secret" Margin="0,6,0,0" Text="{Binding ConfirmPassphrase}"
                IsEnabled="{Binding !IsBusy}">
         <TextBox.KeyBindings>
           <KeyBinding Gesture="Enter" Command="{Binding EnrollCommand}" />

src/DodoSSH.Client.Android/Views/FilesScreen.axaml

@@ -92,8 +92,8 @@
           typed to open a terminal has not been offered here — and quietly reusing it would make a one-time
           password appear to work twice.
         -->
-        <TextBox Classes="field" IsVisible="{Binding SelectedHostAsksForAPassword}"
-                 Text="{Binding TypedPassword}" PasswordChar="•" PlaceholderText="password" />
+        <TextBox Classes="field secret" IsVisible="{Binding SelectedHostAsksForAPassword}"
+                 Text="{Binding TypedPassword}" PlaceholderText="password" />
 
         <Button Classes="primary" Content="{Binding ConnectLabel}" Command="{Binding ConnectCommand}"
                 IsEnabled="{Binding !IsBusy}" />

src/DodoSSH.Client.Android/Views/HostsScreen.axaml

@@ -419,8 +419,8 @@
           Shown only for a host that actually asks for one. A password box beside a key-authenticated host
           is an invitation to type a secret nothing will use.
         -->
-        <TextBox Classes="field" IsVisible="{Binding SelectedHostAsksForAPassword}"
-                 Text="{Binding ConnectPassword}" PasswordChar="•" PlaceholderText="password">
+        <TextBox Classes="field secret" IsVisible="{Binding SelectedHostAsksForAPassword}"
+                 Text="{Binding ConnectPassword}" PlaceholderText="password">
           <TextBox.KeyBindings>
             <KeyBinding Gesture="Enter" Command="{Binding ConnectCommand}" />
           </TextBox.KeyBindings>

src/DodoSSH.Client.Android/Views/LockedScreen.axaml

@@ -49,7 +49,7 @@
           the nearest thing to hand, and reaching past it to a button is the sort of friction that gets a
           phone client called slow.
         -->
-        <TextBox Text="{Binding Passphrase}" PasswordChar="•" PlaceholderText="vault passphrase"
+        <TextBox Classes="secret" Text="{Binding Passphrase}" PlaceholderText="vault passphrase"
                  Height="48" Padding="14,0" VerticalContentAlignment="Center"
                  Background="{StaticResource Field}" BorderBrush="{StaticResource BorderMid}"
                  BorderThickness="1" CornerRadius="6" Foreground="{StaticResource Text}"

src/DodoSSH.Client.Android/Views/PhoneShell.axaml

@@ -23,7 +23,12 @@
     are the pair a session moves between; on the desktop the terminal is not a rail entry at all.
   -->
 
-  <Panel>
+  <!--
+    Named, and the name is load-bearing: everything the phone draws is inside this one element, so its
+    bottom margin is the single place the software keyboard can be kept off the box being typed into,
+    whichever of the eleven screens is showing. See PhoneShell.axaml.cs.
+  -->
+  <Panel x:Name="Body">
 
     <!-- ============ getting in ============ -->
     <views:PendingScreen IsVisible="{Binding IsStarting}"

src/DodoSSH.Client.Android/Views/PhoneShell.axaml.cs

@@ -2,8 +2,10 @@ using global::Android.Views;
 
 using Avalonia;
 using Avalonia.Controls;
+using Avalonia.Controls.Platform;
 using Avalonia.Interactivity;
 using Avalonia.Markup.Xaml;
+using Avalonia.Threading;
 
 using DodoSSH.Client.Android.Platform;
 using DodoSSH.Client.Shell.ViewModels;
@@ -15,6 +17,9 @@ internal sealed partial class PhoneShell : UserControl
 {
     private MainWindowViewModel? shell;
 
+    /// <summary>The software keyboard, while this control is attached. Null on a platform without one.</summary>
+    private IInputPane? keyboard;
+
     /// <summary>
     /// Whether the lock screen currently showing is the one the application launched into.
     /// </summary>
@@ -32,6 +37,11 @@ internal sealed partial class PhoneShell : UserControl
     {
         AvaloniaXamlLoader.Load(this);
 
+        // Subscribed once, for the life of the control, rather than in OnAttachedToVisualTree: Body is this
+        // control's own child and cannot outlive it, and re-subscribing on every attach is how a handler
+        // ends up registered twice.
+        Body.SizeChanged += OnBodyResized;
+
         DataContextChanged += (_, _) =>
         {
             if (shell is not null)
@@ -132,6 +142,14 @@ internal sealed partial class PhoneShell : UserControl
         if (TopLevel.GetTopLevel(this) is { } top)
         {
             top.BackRequested += OnBackRequested;
+
+            keyboard = top.InputPane;
+
+            if (keyboard is not null)
+            {
+                keyboard.StateChanged += OnKeyboardChanged;
+                ApplyKeyboardInset(keyboard);
+            }
         }
     }
 
@@ -143,9 +161,99 @@ internal sealed partial class PhoneShell : UserControl
             top.BackRequested -= OnBackRequested;
         }
 
+        if (keyboard is not null)
+        {
+            keyboard.StateChanged -= OnKeyboardChanged;
+            keyboard = null;
+        }
+
         base.OnDetachedFromVisualTree(e);
     }
 
+    private void OnKeyboardChanged(object? sender, InputPaneStateEventArgs e)
+        => ApplyKeyboardInset(e.NewState is InputPaneState.Open ? e.EndRect.Height : 0);
+
+    private void ApplyKeyboardInset(IInputPane pane)
+        => ApplyKeyboardInset(pane.State is InputPaneState.Open ? pane.OccludedRect.Height : 0);
+
+    /// <summary>
+    /// Holds the phone's whole interface clear of the software keyboard.
+    /// </summary>
+    /// <remarks>
+    /// <para>
+    /// <b>Here rather than on each screen, because the keyboard is not a screen's business.</b> Five of them
+    /// have a box that can be typed into and every one of them would need the same handler; a sixth added
+    /// later would silently not have it. Everything the phone draws is inside <c>Body</c>, so one bottom
+    /// margin shortens all of them at once — which is the same thing the window resizing would have done,
+    /// and is why the two paths below never both apply.
+    /// </para>
+    /// <para>
+    /// <b>Two paths, one of which is dead on any given device.</b> Before Android 15, the activity's
+    /// <c>AdjustResize</c> makes the platform shorten the window itself and the keyboard inset reaches
+    /// Avalonia already consumed — this measures zero and the margin stays where it is. From Android 15 the
+    /// window is no longer resized for the keyboard at all, edge-to-edge being enforced, and the inset is
+    /// reported instead: that is the number applied here. Adding a margin on top of a window that had
+    /// already shrunk would strand the interface an entire keyboard above the keyboard, which is why the
+    /// value is taken from the inset alone and never from both.
+    /// </para>
+    /// <para>
+    /// Scrolling the box back into view is deliberately not done here. <c>ScrollViewer</c> already brings a
+    /// newly focused child into view, and every screen with a box on it is inside one; what it cannot know
+    /// is that the visible region shrank *after* the focus. So the trigger is the resize this margin causes
+    /// — see <see cref="OnBodyResized"/> — and not this method, which would run a layout pass too early to
+    /// have anything to scroll to.
+    /// </para>
+    /// </remarks>
+    private void ApplyKeyboardInset(double occluded)
+    {
+        var inset = double.IsFinite(occluded) ? Math.Max(occluded, 0) : 0;
+
+        if (Math.Abs(Body.Margin.Bottom - inset) > 0.5)
+        {
+            Body.Margin = new Thickness(0, 0, 0, inset);
+        }
+    }
+
+    /// <summary>
+    /// Scrolls whatever has the keyboard back into view once the room left for it is known.
+    /// </summary>
+    /// <remarks>
+    /// <para>
+    /// The one moment this is needed is the one no other handler sees: the box was focused while the whole
+    /// screen was available, and the space it sits in shrank afterwards. Both ways of losing that space end
+    /// here — the margin applied above, and the platform shortening the window on Android 14 and earlier —
+    /// which is why the resize is the trigger rather than either of the two things that cause it.
+    /// </para>
+    /// <para>
+    /// Posted rather than called, and at <c>Loaded</c> priority, because the size change is raised during
+    /// the layout pass that caused it: asking a <c>ScrollViewer</c> to scroll to a child whose new bounds
+    /// have not been written yet scrolls to where the child used to be.
+    /// </para>
+    /// <para>
+    /// Only while the keyboard is up. Every rotation and every screen change resizes this control too, and
+    /// a shell that scrolled to the focused control on each of them would be a shell that moves under you.
+    /// </para>
+    /// </remarks>
+    private void OnBodyResized(object? sender, SizeChangedEventArgs e)
+    {
+        if (keyboard is not { State: InputPaneState.Open })
+        {
+            return;
+        }
+
+        Dispatcher.UIThread.Post(
+            () =>
+            {
+                // Whatever holds focus, not the passphrase box by name: this runs for eleven screens and
+                // the one the keyboard is up for is the only one that can answer which box that is.
+                if (TopLevel.GetTopLevel(this)?.FocusManager?.GetFocusedElement() is Control focused)
+                {
+                    focused.BringIntoView();
+                }
+            },
+            DispatcherPriority.Loaded);
+    }
+
     /// <summary>
     /// Takes the system back gesture up the hierarchy rather than out of the application.
     /// </summary>