The Sixth Entry Point: New Forensic Evidence Confirms STA Remains Unpatched in Android 16
New forensic evidence from a full Android 16 bugreport confirms that Structured Text Amplifica
1. Executive Summary
A full Android 16 bugreport (Redmi Note 14 5G, September 6, 2026) provides direct forensic evidence of two distinct failure mechanisms affecting Chromium-based browsers:
- Text‑layout ANRs involving
libminikin::LineBreakOptimizer::computeBreaks()during long-press and address-bar focus. - Oversized Binder transactions resulting in
TransactionTooLargeExceptionand browser process termination viaShare/VIEWworkflows.
Both Chrome 152.0.7977.82 and Edge 152.0.4191.53 reproduce the same failures on Android 16 (build BP2A.250605.031.A3 / HyperOS 3.0.301.0).
Key finding: A sixth entry point into libminikin has been identified Paint.measureText() → HarfBuzz shaping, reproduced in Google Docs (com.google.android.apps.docs.editors.docs). This is the first documented entry point that enters libminikin through the glyph shaping path rather than line-breaking.
2. The Sixth Entry Point STA-031
The previously documented entry points into libminikin all pass through line‑breaking algorithms (LineBreakOptimizer::computeBreaks, breakLineOptimal, breakLineGreedy). The new evidence reveals a sixth entry point:
android.graphics.Paint.measureText()
↓
libhwui (PaintGlue / MinikinUtils)
↓
libminikin (Layout::measureText)
↓
Layout::doLayoutRunCached
↓
Layout::doLayoutWord
↓
LayoutCache::getOrCreate<LayoutAppendFunctor>
↓
LayoutPiece::LayoutPiece
↓
libharfbuzz_ng (hb_shape_full, _hb_ot_shape)
↓
hb_font_t::get_glyph_h_origin_with_fallback
↓
Main thread blocked → InputDispatcher timeout → ANR
This stack was captured from a production ANR in Google Docs (com.google.android.apps.docs.editors.docs), which was not previously in the catalogue of applications with forensically confirmed libminikin ANRs.
The trigger path passes through AlertDialogLayout.onMeasure, consistent with an oversized structured payload being measured inside a dialog component, the same class of UI surface implicated in other STA vectors.
3. Forensic Evidence STA-003 (Share / Intent Binder Crash)
The bugreport records an ActivityTaskManager transition involving Google Files as the calling package:
19:40:03.713
START u0 {
act=android.intent.action.VIEW
dat=content://com.google.android.apps.nbu.files.provider/...
typ=text/html
...
cmp=com.microsoft.emmx/com.google.android.apps.chrome.IntentDispatcher
}
The Intent is explicitly reported as (has extras). Although the actual extra contents are redacted by the bugreport, in controlled reproduction the variable content supplied through this workflow is the crafted STA pattern.
3.1. Large Bundles
For Edge, the bugreport records:
Large Bundle: length=1531092
Large Bundle: length=1532640
3.2. Binder Transaction Failure
Immediately before the crash:
Binder transaction failure
ID: 12562575
error: -28 (No space left on device)
Large outgoing transaction of 1533260 bytes
interface descriptor: android.app.IActivityTaskManager
code 1
3.3. TransactionTooLargeException
android.os.TransactionTooLargeException:
data parcel size 1533260 bytes
android.app.Instrumentation.execStartActivity
android.app.Activity.startActivityForResult
org.chromium.ui.base.WindowAndroid
android.app.IActivityTaskManager$Stub$Proxy.startActivity
android.os.BinderProxy.transact
3.4. Process Termination
wm_finish_activity:
com.microsoft.emmx/...ChromeTabbedActivity, force-crash
am_proc_died:
com.microsoft.emmx
3.5. Chrome Confirmation
The same phenomenon is reproduced in Chrome:
TransactionTooLargeException:
data parcel size 1533240 bytes
wm_finish_activity:
com.android.chrome/...ChromeTabbedActivity, force-crash
am_proc_died:
com.android.chrome
The two Chromium implementations fail at almost exactly the same serialized transaction size:
- Chrome: 1,533,240 bytes
- Edge: 1,533,260 bytes
- Difference: only 20 bytes
This is particularly significant because both browsers reach the same Chromium Activity-start path and both fail at the Android Binder boundary.
4. STA-017 / STA-020 Text-Layout ANRs
The same bugreport contains multiple ANR reports in which Chrome and Edge enter the Android text-layout stack:
TextView
StaticLayout
LineBreaker
libhwui
libminikin
minikin::LineBreakOptimizer::computeBreaks
breakLineOptimal
android::nComputeLineBreaks
In Chrome, the stack includes:
minikin::getPrevWordBreakForCache
StyleRun::getLineMetrics
MeasuredText::getLineMetrics
LineBreakOptimizer::computeBreaks
breakLineOptimal
android::nComputeLineBreaks
TextView.onMeasure
The ANR reason is an input dispatch timeout:
ChromeTabbedActivity is not responding.
Waited 5000ms for MotionEvent(action=DOWN)
The Activity is subsequently force-finished by the system. This demonstrates that the problem is not specific to a single Chromium implementation. The same Android text-layout subsystem is reached by both browsers.
4.1. STA-020 — Address Bar / Omnibox ANR
A separate reproduction occurs when the crafted URL is present in browser history and the address bar is subsequently focused. The omnibox suggestion rendering path again reaches Android's text measurement and libminikin line-breaking implementation:
OmniboxSuggestionsContainer.onMeasure
RecyclerView.onMeasure
TextView.onMeasure
StaticLayout.generate
libhwui
libminikin
LineBreakOptimizer::computeBreaks
This provides a second independent entry point into the same native text-layout subsystem.
5. Chromium Patches — Not Enough
The Chromium-specific mitigations introduced in 2026 do not address the underlying Android text-processing paths involved in these reproductions.
| Patch | Mechanism | Covers STA-003? | Covers STA-017/020? |
|---|---|---|---|
| SelectionUtils / 100 KB | Truncates PDF selection text | ❌ No | ❌ No |
| LargePayloadSupport (FD) | File descriptors for large IPC | ❌ No | ❌ No |
| SharedMemory (Union) | Redesigns Native Messaging transport | ❌ No | ❌ No |
| Oversized Clipboard (ContentProvider) | Redirects large clipboard payloads | ❌ No | ❌ No |
| PdfView anchors | Replaces SelectionModel with placeholders | ❌ No | ❌ No |
The root cause is not in Chromium. It is in Android's libminikin.so text layout engine, which lacks a global length gate before entering expensive paths like LineBreakOptimizer::computeBreaks() and Layout::measureText().
6. September 2026 Android Security Bulletin
The September 2026 Android Security Bulletin (published September 8) contains no patches for libminikin, Binder, SavedState, TransactionTooLargeException, or any of the STA vectors documented in this research.
A search of the bulletin reveals zero mentions of:
libminikinBinderSavedStateTransactionTooLargeStaticLayout,TextView,LineBreakOptimizer
This confirms that the architectural gap in libminikin remains publicly unpatched.
7. The Bigger Picture
The evidence now supports the following conclusions:
| Finding | Status |
|---|---|
| Sixth entry point to libminikin (HarfBuzz shaping) | ✅ Confirmed (Google Docs) |
| STA-003 (Share crash) — Edge and Chrome | ✅ Reproducible in 2026 |
| STA-017 (Long-press ANR) — Edge and Chrome | ✅ Reproducible in 2026 |
| STA-020 (Focus ANR) — Edge and Chrome | ✅ Reproducible in 2026 |
| Chromium patches | ❌ Do not cover STA-003/017/020 |
| September 2026 bulletin | ❌ No patches for libminikin |
| Xiaomi STA-015b | ✅ Patched (no CVE public) |
8. Conclusion
New forensic evidence from a full Android 16 bugreport confirms that Structured Text Amplification (STA) vectors remain reproducible in the latest versions of Chromium-based browsers.
A sixth entry point into libminikin has been identified Paint.measureText() → HarfBuzz shaping, reproduced in Google Docs. This demonstrates that the problem is not confined to line-breaking; it also affects glyph shaping and text measurement paths.
Despite multiple Chromium patches in 2026 (LargePayloadSupport, SharedMemory, 100 KB selection limits, etc.), none of them address the underlying Android text-processing paths involved in STA-003, STA-017, and STA-020.
The September 2026 Android Security Bulletin contains no patches for libminikin, Binder, SavedState, or TransactionTooLargeException.
The evidence indicates a platform-level resource-exhaustion gap: Android text-processing entry points do not enforce a sufficiently early global length limit before entering expensive operations such as line breaking, shaping and measurement.
This indicates that the issue is not browser-specific and cannot be fully addressed through Chromium-only patches. A platform-level fix in AOSP appears necessary
Posts
