ClassCastException in view measurement on Samsung tablet / Android 16 (v0.1.16)

[willwade]

From PostHog crash reporting (real user, Samsung SM-F946U1 Galaxy Tab, Android 16, v0.1.16 build 1001):

ClassCastException: android.widget.LinearLayout$LayoutParams cannot be cast to
android.widget.FrameLayout$LayoutParams
Thread: main

Stack is entirely framework (ZygoteInit → ActivityThread → Choreographer.doFrame → ViewRootImpl.performTraversals → DecorView.onMeasure → FrameLayout.onMeasure → LinearLayout.measureVertical → View.measure → crash). No app frames visible because the ProGuard map wasn't uploaded (see companion issue).

What this means

A view with LinearLayout.LayoutParams ended up inside a FrameLayout (or vice versa) during the measurement pass. Classic causes:

1. Programmatic view reparenting — adding a view to a different container type than its LayoutParams were created for
2. Layout inflation mismatch — inflating a layout with <FrameLayout> root but the parent expects LinearLayout children (or using inflate(layout, parent, false) where parent is the wrong type)
3. IME service surface — the DasherImeService creates its views programmatically; if any view is moved between the IME's input area and a floating window (different container types), this fires
4. Samsung/foldable-specific: DeX mode or multi-window triggers a different DecorView layout path on some devices

Repro unknown

• One occurrence so far (device: Samsung tablet, Android 16, API 36)
• Handled ($exception_handled: true) — the app didn't hard-crash; the exception was caught by the crash handler
• Happened during doFrame — a layout pass, likely after a configuration change, keyboard show/hide, or IME visibility toggle

What we need

The ProGuard mapping file (companion issue) to resolve the stack — right now every frame is resolve_failure: "No proguard map uploaded". With the mapping, the app frames between the framework calls would name the exact view/code path.

Also worth checking: the IME service's view creation (DasherImeService.kt) for any addView calls that could put LinearLayout children inside FrameLayouts (or vice versa), especially around the floating-mode overlay permission flow.

[willwade]

Root-caused and fixed in #45 — was the one remaining path setting on the docked root (the parent is the IME window's FrameLayout DecorView). One-line fix. The bug had been found and fixed twice before ( and the shrink), but the exit path was missed.