mirror of
https://github.com/wu736139669/hapi.git
synced 2026-11-07 01:21:37 +00:00
be5f37b9bf
* feat(android): render chat markdown math with offline KaTeX Port the web math pipeline to Android chat markdown. A new MarkdownMath pre-pass in :core:protocol extracts math with web semantics (remark-math singleDollarTextMath:false + remark-latex- bracket-math): $$ display flows, $$ text math only when the closer run equals the opener and stays inside the paragraph, single $ never triggers math (currency stays prose), \(..\)/\[..\] bracket pairs, backslash-escaped delimiters stay literal, and code spans, fences, links and link reference definitions are fully protected. Matches are lifted behind private-use placeholder tokens and re-inserted as MathInlineNode/MathBlockNode custom nodes, hoisting display math out of paragraphs while blockquote/list containers survive the reparse. 37 JVM tests mirror the web suite's cases. Rendering is a shared offline WebView (ui/markdown/MathWebView.kt) fed a self-built HTML document (MathDocument.kt) against bundled assets/katex/ (KaTeX 0.16.45, same version as web). The view is network-blocked (blockNetworkLoads + shouldInterceptRequest refuses http/https/ws/wss) with file/content access disabled; asset URLs still resolve through the file:///android_asset/katex/ base URL. Theme color and font size are injected per render and the document reports its height through a JS bridge (ResizeObserver + onPageFinished re-measure). KaTeX failures follow the web's three-tier semantics, degrading to monospace raw TeX. Inline \(..\) and single-paragraph $$ math degrades to monospace TeX for v1: AnnotatedString cannot host a WebView and one WebView per fragment is too costly in chat lists. The parser still emits MathInlineNode so a future renderer can upgrade inline rendering without touching the extraction layer. Co-Authored-By: Claude Code <noreply@anthropic.com> via [HAPI](https://hapi.run) Co-Authored-By: HAPI <noreply@hapi.run> * fix(android): convert CSS pixels correctly at the math WebView boundary The JS bridge reports scrollHeight in CSS pixels, but KaTeXMathBlock treated the value as Android physical pixels and divided it by the screen density when sizing the modifier: on a density-3 device a reported 90 CSS px block collapsed to 30dp instead of ~90dp. The font conversion had the opposite mismatch — 16sp chat text went through TextUnit.toPx() (physical pixels) and was injected as `font-size: 48px` CSS, making formulas render ~3x too large on the same screen. Define the two boundary conversions explicitly as pure functions next to the document builder and unit-test them: - spFontToCssPx: CSS px and sp are both density-independent, so only the user's font-scale preference crosses the boundary; density never enters (16sp stays 16 CSS px at any density, 21 at fontScale 1.3). - cssPxToDp: reported CSS px map 1:1 to dp at the default WebView scale, multiplied by WebView.scale when the view is zoomed. The document now also pins the viewport with `width=device-width, initial-scale=1`, making the 1 CSS px = 1 dp default scale an explicit property of the document rather than a WebView default, with a regression test asserting the meta tag. Co-Authored-By: Claude Code <noreply@anthropic.com> * fix(android): refresh the math WebView height callback across spec changes KaTeXMathBlock keyed its height state with remember(spec) but assigned MathWebView.onHeightChanged inside AndroidView.factory, which runs only when the Android view is created. The callback therefore captured the initial spec's state object: when LaTeX, theme color or font size changed, remember(spec) minted a new state while AndroidView retained the existing view and its stale callback, so every measurement from the reloaded document updated the orphaned state and the current block stayed at its 22dp minimum. Keep one stable holder (MathViewHeightState) remembered unkeyed for the mounted view, reset it explicitly in onRender when the spec changes, and re-point the view's callback plus reset the height inside AndroidView.update before rendering — the creation-time callback then always feeds live state. JVM tests drive the holder through spec changes on one mounted view (the pre-fix wiring cannot compile against this shape: the factory-captured remember(spec) state is exactly the orphan the holder removes). Co-Authored-By: Claude Code <noreply@anthropic.com> * fix(protocol): bound dollar flow math closing to the enclosing container findFlowClose kept scanning after the opening line left its container and accepted an unprefixed closing run, so `> $$\n> x\n\nOrdinary prose\n\n$$\ny\n$$` paired the quoted opener with the later top-level `$$`: the prose was swallowed into the formula and the final `$$` lost its own opener. remark-math (verified against micromark-extension-math, whose math flow is `concrete` and dies with its container) renders the quote's math, the prose and a separate top-level equation instead. Bound matching to the opening container, distinguishing container shapes: a closer is only accepted from a line that still carries the container prefix; a blank line ends a blockquote (a following `> $$` opens a NEW quote, while a `>`-only line is an in-quote blank the container survives); a list item may resume after blank lines (loose lists), so blanks are skipped and the next content line decides; an unrecognized prefix is plain <= 3 space indentation, not a container, and keeps the unbounded scan (blank lines and fences stay math content). Regression tests: the quoted example (prose stays prose, the later equation keeps its own opener), a list-container variant, a blank-line/new-quote guard, plus two in-container close locks — the first three fail on the pre-fix scan. Co-Authored-By: Claude Code <noreply@anthropic.com> * feat(android): render mermaid fences as offline diagrams Port the web MermaidDiagram component to Android chat markdown. A fence whose language is exactly `mermaid` (case-sensitive, like the web's MARKDOWN_COMPONENTS_BY_LANGUAGE key) now dispatches to MermaidDiagramView instead of the plain code block; every other fence keeps the CodeBlock path. Rendering runs in a hardened offline WebView fed a self-built HTML document against bundled assets/mermaid/mermaid.min.js (Mermaid 11.14.0, curl-fetched, sha256-identical to the web app's locked dependency). That dist file is a self-contained classic script assigning globalThis mermaid - no imports, no runtime fetches - so no ES-module/CORS workaround is needed. The view shares the KaTeX skeleton: network stack blocked, file/content access off, asset URLs through the file:///android_asset/mermaid/ base URL (OfflineMathWebViewClient generalized to OfflineMarkdownWebViewClient, no behavior change). Behavior mirrors the web component line by line: initialize with startOnLoad:false, securityLevel:'strict', suppressErrorRendering:true and the web's dark/light themeVariables palettes verbatim (theme flips re-render); the validate-then-render gate parses with suppressErrors first and never calls render() after a failed validation, re-parsing once without suppression only to surface a human-readable reason; svg element ids are per-instance (`mermaid-<n>`, web useId) so the scoped styles mermaid emits cannot collide across diagrams in one message; wide diagrams scroll horizontally inside the document while the svg is centered at max-width:100% and height:auto. The code header (language chip + copy) stays above the body like the web's retained DefaultCodeBlock header; until the diagram renders - and on failure - the raw source is shown below it (the block's source exit), with the failure notice appearing only for actual errors so the loading window never flashes a render-error line. mermaidFallbackUi maps state to those surfaces as a pure function. 15 JVM tests cover dispatch, offline-ness, palettes, security flags, the validation gate structure, id uniqueness, generation filtering, script-breakout safety and the fallback mapping; the driver's runtime semantics were additionally validated against the real bundle in jsdom (flowchart/sequence render, invalid source surfaces the parse reason, hostile labels are rejected/sanitized under strict). Co-Authored-By: Claude Code <noreply@anthropic.com> via [HAPI](https://hapi.run) Co-Authored-By: HAPI <noreply@hapi.run> * fix(android): convert CSS pixel heights correctly in the mermaid WebView Both height reporters feeding MermaidDiagramView — the document bridge's report() (documentElement/body scrollHeight) and OfflineMarkdownWebViewClient's onPageFinished re-measure — return CSS pixels, but the rendered branch ran the value through with(density) { heightPx.toDp() }, which treats it as Android physical pixels and divides by display density: on a 3x display a diagram measuring 180 CSS px received a 60dp box and was clipped into an unnecessarily scrolling WebView. Fix it exactly like the KaTeX base now does: the document pins `width=device-width, initial-scale=1` (making 1 CSS px = 1 dp at the default WebView scale an explicit property of the document rather than a WebView default), and the reported value crosses the boundary through the shared density-independent cssPxToDp helper — extracted as the pure mermaidRenderedHeightDp so the composable no longer holds any density conversion at all, keeping both markdown renderers on one boundary contract. (The KaTeXMathBlock repeat of the same bug is fixed by the rebased base; MathWebView.kt arrives converted already.) JVM tests: the viewport pin is asserted against the built document (demonstrated failing on the pre-fix template) and the conversion math is driven through the pure helper — 180 CSS px stays 180dp because the boundary carries no density parameter, mirroring the base's MathDocumentTest contract. Co-Authored-By: Claude Code <noreply@anthropic.com> * feat(android): generalize generated media blocks to video/audio/file The hub's /generated-images/:id endpoint already serves any mime type (video, audio, arbitrary files arrive as the same generated-image wire block with a mimeType), but the Android chat rendered every block as an image. This ports the web GeneratedImageCard generalization so the card routes by display intent, exactly like web generatedInlineMedia.ts: - mimeType routing is the web's literal prefix check: video/… gets a player, audio/… an audio player, image/… or null keep the existing image treatment (unchanged AsyncImage thumbnail + tap-to-zoom dialog), everything else is a file card (no separate "unsupported" class — unknown mimes ARE the file UI, matching web G3/G8). - non-image media never downloads on its own: "Load video" / "Load audio" / "Prepare download" gate buttons (web's explicit-intent rule G4; English labels verbatim from the web card), pulsing skeleton while fetching (G7), and the shared "{label} is unavailable. {error}" error line (G8). The wire carries no tiny/poster fields, so video renders bare — nothing to special-case. - every kind now sits in the web's G14 card shell with the localized "{label}: {fileName}" hint header; images additionally surface the error line on Coil failure instead of a silent empty hole. - downloads go through the same authed OkHttp client Coil uses (JWT + silent 401 re-auth + ETag disk cache), staged into a temp file and atomically renamed under cache/generated-media/; a completed file short-circuits later fetches (immutable, ETag-stable content) and non-2xx maps to "HTTP <code>" exactly like the web's ApiError. - video plays in-app via framework VideoView + MediaController (no new media dependencies: Media3 is not on the classpath and pulling it in for this card is not worth the MB); audio is a compact play/pause + scrub + m:ss row over MediaPlayer (web's native <audio> chrome degraded: volume/speed omitted, no waveform — web has none); files get Open (ACTION_VIEW over the existing FileProvider, new generated-media cache path) and Save (ACTION_CREATE_DOCUMENT picker) outlets in place of the browser download link. - ChatMedia gains a nullable fetchGeneratedMedia field (default null: previews/tests degrade to the unavailable line, so stack-only call sites merge unchanged). 17 new strings added to en/ru/zh-CN in one commit, mirroring en key order (KEYSYNC clean; zh count equal — its pre-existing regional order drift is untouched). 10 JVM tests cover routing (including case sensitivity and null-mime), mount-gating, label/action mapping, cache file name sanitizing (path traversal), the MockWebServer round-trip with status mapping + cached-file short-circuit, and the time formatter. Gate: :app:testDebugUnitTest :core:data:test :core:protocol:test :app:lintDebug :app:compileDebugAndroidTestKotlin BUILD SUCCESSFUL. Co-Authored-By: Claude Code <noreply@anthropic.com> via [HAPI](https://hapi.run) Co-Authored-By: HAPI <noreply@hapi.run> * fix(android): refine generic file MIME types from the filename The file card passed the wire mimeType straight through to ACTION_VIEW, substituting application/octet-stream only when the wire type was null (r4370795783). Passing octet-stream explicitly defeats Android's viewer matching: a PDF viewer registered for application/pdf is not matched by an intent whose type says application/octet-stream, so PDFs (and every other ordinary file whose hub type was octet-stream or missing) opened with no eligible activity. resolveFileMimeType now passes a specific wire type through untouched, but when the wire type is missing, empty, or octet-stream (compared case-insensitively) it re-derives the type from the original filename's extension through an injected resolver — android.webkit.MimeTypeMap at the call site, following the established AttachmentPreparer / AndroidShareIntake pattern (lowercased extension, slash/wildcard sanity check on the resolved value). Unknown extensions keep the generic octet-stream fallback. The resolved type feeds both outlets: the Open ACTION_VIEW intent and the Save ACTION_CREATE_DOCUMENT contract. The resolver is a required parameter rather than a default, which keeps GeneratedMedia.kt free of android.* imports and forces the seam: 3 JVM tests drive it with a fake table (pdf->application/pdf via extension for null/octet-stream/empty wire types; unknown extension and no extension -> octet-stream fallback; specific wire types pass through untouched even when the extension would map elsewhere). All three fail on the pre-fix code by construction — resolveFileMimeType did not exist and the null-wire PDF case asserted the old octet-stream handoff. Gate: :app:testDebugUnitTest --tests GeneratedMediaTest BUILD SUCCESSFUL (13 tests, 0 failures). Co-Authored-By: Claude Code <noreply@anthropic.com> * fix(android): bound generated media cache names by UTF-8 bytes sanitizedGeneratedMediaFileName capped the stem at 96 UTF-16 chars and relied on that alone (r4370795787). Android filename limits are byte limits (NAME_MAX 255): 80 hanzi + ".pdf" is a 122-char / 281-byte component once the UUID imageId prefix is attached (verified against the pre-fix logic: 36-byte id + 1 + 240 + 4 = 281 bytes), so long Chinese names failed the atomic cache rename outright. The complete component — id prefix + stem + extension — is now assembled under a 255-byte UTF-8 budget, with pathological ids and extensions capped at 64/32 bytes so the stem always keeps room. The stem keeps its historical 96-char cap (ASCII names keep their exact prior shape), bytes beyond the budget are cut from the stem only, on code-point boundaries, and the extension always survives intact. The char-level whitelist already drops surrogate halves (a lone half is never a letter), so every surviving char is one complete BMP code point; the truncation helpers are additionally pair-safe for any future code-point-aware whitelist. JVM tests: the reviewer's UUID + 80-hanzi ".pdf" case lands at <= 255 bytes with the extension and id prefix preserved (red on the pre-fix logic, which produced exactly 281); ".tar.gz"-style extensions survive stem truncation; a battery of multibyte names re-decode byte-identically under the cap; ASCII names keep their historical shapes ("i-" + 96 a's, "img-1-media", "id-x.bin", "i-截图01.png"). Gate: :app:testDebugUnitTest --tests GeneratedMediaTest BUILD SUCCESSFUL (16 tests, 0 failures). Co-Authored-By: Claude Code <noreply@anthropic.com> * test(android): cover audio playback wiring and the file outlets' types The play/pause/seek decisions and the MediaPlayer lifecycle lived inline in the audio composable, which made them unreachable from JVM tests (no emulator here; androidTest only compile-checks). Extract them into GeneratedAudioSession over a GeneratedAudioPlayer seam — the app side adapts android.media.MediaPlayer, tests pass a scriptable fake — and the card now collects the session's flows, with DisposableEffect.onDispose forwarding to session.release(). JVM coverage through the fake: - prepare wires the data source + prepareAsync and reports duration on the prepared callback; pre-preparation toggles/seeks stay inert; - the toggle maps to start/pause (turbine on the playing flow) and natural completion parks the row; - seekToFraction lands fraction*duration and clamps to [0, duration], reading the position back afterwards; - pollPosition only reads while playing (the 250 ms LaunchedEffect); - release — the dispose hook — releases the framework player exactly once across double-dispose, stops playback, and every later control call is inert (a released MediaPlayer throws); - player errors and a failing data source both map to the failed line and the row goes dead. The file card's Open/Save construction moves behind generatedFileOutlets so a JVM test pins that ACTION_VIEW and ACTION_CREATE_DOCUMENT both carry the *resolved* MIME type (inferred pdf, generic fallback, specific wire passthrough) plus the suggested save name — android.content.Intent is not on the unit-test classpath. A MockWebServer fetch with the reviewer's 80-hanzi + UUID name proves the byte-bounded component really round-trips the local filesystem: under 255 bytes, extension kept, no staging litter beside the final file. These tests fail on the pre-change code by construction: the session, seam, and outlets did not exist and the logic was not reachable from the JVM. Explicit loading (loadsOnMount gate), authenticated caching (hubGraph.session.imageClient: JWT + silent 401 re-auth + ETag cache), and download cleanup (staged temp deleted on failure, atomic rename on success) are untouched — only their test surface grew. Gate: :app:testDebugUnitTest --tests GeneratedMediaTest BUILD SUCCESSFUL (24 tests, 0 failures). Co-Authored-By: Claude Code <noreply@anthropic.com> --------- Co-authored-by: Claude Code <noreply@anthropic.com> Co-authored-by: HAPI <noreply@hapi.run>