2 Commits

Include renames

Author	SHA1	Message	Date
jaap-janandClaude Opus 5	57d4b30557	Put the app's own mark on the launcher ... The sign-in and locked screens both draw the same thing — a square outline in the accent with >_ inside it — and the launcher was still showing the stock Android silhouette, so the icon somebody taps and the icon the app opens onto had nothing to do with each other. Redrawn as a vector rather than exported from the screen as a bitmap. There is one geometry here and no set of density buckets to update four of and forget the fifth, and the accent stays a number that can be diffed against Palette.axaml rather than a colour baked into a PNG. The hex is written out because an Android resource cannot reference a XAML dictionary — the same duplication colors.xml already carries for the window background, with the same obligation attached. Adaptive only, no raster fallback. Adaptive icons landed in API 26 and this head requires 28, so there is no device it ships to that would need the bitmaps; density buckets exist to choose between PNGs and there is nothing to choose. The background layer is the same @color/dodo_window as the window and the status bar, so the mark sits on the app's own near-black rather than on a second one almost like it. Two departures from the screen, both because a launcher is looked at much smaller than a sign-in header. The box is 42 across rather than the 48 that first suggested itself: 72 of the 108 survives masking, but that is a width, and a square meets a circular mask at its corners — at 48 they land 33.9 out against a radius of 36 and read as clipped despite technically clearing it. And the strokes are 2.2 and 2.8 where proportional fidelity to a 1px border on 44px would be 1.0, which a launcher drawing this at 48dp would render as half a pixel of nothing. A monochrome layer too, for the Android 13+ themed-icon setting. Without one a launcher with themed icons on falls back to the full-colour icon, which would leave this the single green thing on an otherwise recoloured home screen. Verified in the packaged APK: the icon resolves at all five densities, the three layers resolve, and the compiled vector carries the geometry above. The launcher rendering itself was checked against local renders under circular and squircle masks at 144 and 64 px, not on the device — the phone was locked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 13:46:40 +02:00
jaap-jan	fe9d7fc289	Give DodoSSH a phone, and a shared shell for both heads to drive ... The Android head from docs/android-port.md, taken as far as its step 6. Step 3, the spike, is answered and its throwaway screen is gone: libsodium.so and libe_sqlite3.so are both in the arm64 APK, so NSec resolves its native half on Android despite shipping no Android build, and the local cache opens. Two findings the audit could not have had: Avalonia.Controls.WebView only ships net10.0-android36.0, which settles the open "which Android versions" question at targetSdk 36; and Android has blocked cleartext HTTP since API 28, so the terminal renderer needs a network security config scoped to 127.0.0.1 or the WebView loads nothing. DodoSSH.Client.Shell is new and is why the phone can exist: the view models, the terminal renderer files and the palette moved there so both heads drive one state machine and draw from one set of tokens. The desktop head is otherwise untouched and its 144 tests still pass. The platform pieces behind interfaces that already existed: the profile directory from filesDir, a device key wrapped by a StrongBox-backed key that a fingerprint releases, and a foreground service so a shell outliving a vault lock stays true on a platform that stops backgrounded processes. Sign-in is deliberately absent rather than approximated. It needs an app link, because reusing the desktop loopback listener is the attack RFC 8252 section 8.3 names.	2026-07-31 20:58:48 +02:00