Upstream Android and Chromium Changes in 2026: Converging with the STA Model

Friday, August 14, 2026

Upstream Android and Chromium Changes in 2026: Converging with the STA Model

Structured Text Amplification — Upstream Correlation Analysis

This post analyses changes made in Chromium and AOSP/AndroidX during 2026 that intersect with the surfaces studied by Structured Text Amplification (STA).

The analysis is organised around the 32 vectors documented in the STA whitepaper v5, correlating each with upstream commits or architectural changes where a relationship exists.

Methodological note: This is a correlation analysis, not a claim that any referenced change was caused by the STA research. The goal is to identify whether the same architectural boundaries that STA studies — text selection, context menus, Intent/IPC transfer, UTF-16 serialization — are being modified by Android and Chromium engineers with explicit size limits, policy checks, or allocation controls.

1. The full correlation matrix: STA vectors ↔ upstream changes

Each vector is classified using four levels:

Direct - The change modifies precisely the surface or mechanism of the vector.
Strong — Same boundary/mechanism, though the commit does not say it fixes STA.
Architectural — Evidence that Android/Chromium is working on that class of problem.
None — No sufficiently specific upstream change found in this review.

STA	Description	Upstream change	Level
001	Chrome — long-press context menu	`0065224e` — ShowContextMenu IPC / kLongPress (11 Jun 2026)	Direct
002	Context menu (long-press)	`0065224e` — same commit; documents long-press → ShowContextMenu IPC path	Direct
003	Share link	`84b615a0` — SelectionUtils, Share/Web Search/Translate, MAX_SHARE_QUERY_LENGTH=100000 (5 May 2026)	Direct
004	Google Maps — oversized geo: URI	Intent/URI → Binder boundary (architecture)	Architectural
005	WhatsApp — large text → SavedState crash loop	androidx.savedstate 1.5.0; LargePayloadSupport (AOSP CL 3989977)	Strong
005b	WhatsApp Business — shared inbox	Same SavedState/Binder boundary	Strong
005c	WhatsApp + Meta AI	Same SavedState/Binder boundary	Strong
005d	WhatsApp deep link	Deep link → Intent → Binder (architecture)	Strong
006	Google App — Select text → Translate	`84b615a0` — ACTION_TRANSLATE added to selection menu	Direct
007	Google Drive — PDF → Translate	`84b615a0` — PDF viewer selection menu with Translate action	Direct
008	System services — sync IPC + oversized payload	General Binder/IPC architecture	Architectural
009	Google Drive — DOCX → Print Preview	Print Service → Bundle → Binder → SystemUI (architecture)	Strong
010	Drive → Print Service → SystemUI	Print Service → Binder boundary (architecture)	Strong
010b	Drive → cloud printer	Same Print Service/Binder boundary	Strong
011	Clipboard → assisted paste → SystemUI	ClipData → IPC → SystemUI (architecture)	Architectural
012	Threads — deep link /search?q=[payload]	Deep link → Fragment args → SavedState → Binder (architecture)	Strong
012e	Threads via WhatsApp — WebView → deep link	Same Intent/SavedState/Binder boundary	Strong
013	Microsoft Bing — address-bar history crash	Chromium omnibox/history pipeline (architecture)	Architectural
015	SystemUI — RecentTasksController	TaskPersister → SystemUI → Binder (architecture)	Strong
015b	HyperOS — OEM Task State Interactor	Same TaskPersister/SystemUI boundary	Strong
015-DL	Google Drive → Browser → SystemUI crash loop	Browser → TaskPersister → SystemUI (architecture)	Strong
016	Opera — onResume RuntimeException	Chromium/Binder architecture	Architectural
017	Cross-engine libminikin ANR	No public 2026 commit found introducing length limits in LineBreakOptimizer	None
018	Drive + Print Service + SystemUI	Print/SystemUI/Binder architecture	Strong
019a-d	Firefox — address bar, ClipboardManager, Compose TextLayout	No public 2026 commit found — libminikin lacks structural length limits	None
020	Chrome + Edge — address-bar history ANR	Chromium Omnibox/history pipeline activity (2026)	Strong
021	Brave — address bar ANR	Chromium/Omnibox architecture (inherited)	Architectural
022	DuckDuckGo — 920 KB URL → 965 KB Parcel	`8882927e` — PdfView "Fix transaction too large crashes" (Jul 2026)	Direct
022b	DuckDuckGo — history suggestion ANR	No public 2026 commit found — libminikin/history pipeline lacks limits	None
023	Samsung Internet — Share crash	Chromium Share/Intent architecture	Architectural
023b	Samsung Internet — tab group freeze	Chromium tab/UI architecture	Architectural
023c	Samsung Internet — address bar ANR	Chromium Omnibox/history pipeline	Strong
027	Edge Ask Copilot — initialText NavGraph crash	Edge/Chromium deep link surface (no public Chromium fix found)	Architectural
028	UTF-16 serialization density	AOSP Parcel::writeUtf8AsUtf16(); Chromium native UTF-16 size handling	Direct

2. Three upstream convergences worth highlighting

🔹 Convergence 1: Selection → Intent — STA-003 / 006 / 007

Chromium has explicitly created SelectionUtils, added Share/Web Search/Translate to the selection menu, and introduced a size limit (MAX_SHARE_QUERY_LENGTH = 100000) to prevent large selections from crossing the Intent boundary directly.

selected text
     ↓
SelectionUtils
     ↓
Share / Web Search / Translate
     ↓
Intent.EXTRA_TEXT / ACTION_TRANSLATE
     ↓
Binder / IPC boundary

Why this matters: This is an independent validation that the surface STA-003/006/007 studies is considered sensitive enough for explicit defensive limits.

🔹 Convergence 2: SavedState → Binder → TransactionTooLargeException — Class A

AndroidX commit 8882927e (July 2026) is titled "Fix transaction too large crashes". The cause: a 1.2 MB SelectionModel serialized via onSaveInstanceState.

1.2 MB SelectionModel
       ↓
onSaveInstanceState
       ↓
Binder transaction
       ↓
TransactionTooLargeException
       ↓
CRASH

The fix avoids serializing the full object, keeping only lightweight anchors (~44 bytes) and reconstructing asynchronously.

Why this matters: This is an upstream mitigation of exactly the architectural pattern Class A STA vectors describe — oversized state crossing Binder.

Limitation: It does not fix FragmentManager.restoreAllState() or TaskPersister. Those remain unpatched.

🔹 Convergence 3: UTF-8 → UTF-16 → allocation — STA-028

AOSP's Parcel::writeUtf8AsUtf16() explicitly calculates UTF-16 length and allocates (utf16Len + 1) * sizeof(char16_t).

UTF-8 input
     ↓
utf8_to_utf16_length()
     ↓
UTF-16 code-unit count
     ↓
(utf16Len + 1) * sizeof(char16_t)
     ↓
Parcel storage allocation

The reverse path similarly calculates size before conversion. Chromium also uses std::u16string / UTF-16 representation for size decisions in selection paths.

Why this matters: This provides direct experimental grounding for STA-028: equal code-point counts can produce different UTF-16 footprints, and those footprints affect allocation decisions.

3. The asymmetry that matters: Class A vs Class B

⚠️ A striking pattern emerges from this review:

Class A (IPC / SavedState / Binder) — upstream mitigations are appearing: LargePayloadSupport, PdfView fix, AOSP Intent handling. These boundaries are receiving active defensive work.
Class B (libminikin / UI thread) — no public 2026 commit introduces structural length limits in LineBreakOptimizer::computeBreaks, breakLineOptimal, or breakLineGreedy. The pipeline remains without a global defensive limit.

This aligns with the STA whitepaper's observation that libminikin's line-breaking paths have not been structurally hardened, despite the existence of historical CVEs (e.g., CVE-2017-0755) and documented ANR behaviour across multiple Android versions.

Conclusion: The upstream evidence confirms that Class A is being addressed, while Class B remains an open gap.

4. What this analysis does — and does not — validate

Supported:

Upstream Android and Chromium changes increasingly introduce defensive boundaries around the same text, IPC and state-propagation surfaces identified by STA.

Not supported by this analysis:

That any referenced change was caused by STA research
That all STA vectors share one root cause
That Class B has been structurally fixed (it has not)

5. The next experiment

STA-028 now has a particularly clear experimental question:

Can the same observed threshold be reached with fewer Unicode code points by changing the UTF-16 representation of the payload?

Record:

Code points
UTF-16 units
UTF-16 bytes
UTF-8 bytes
Device
Android version
Observed threshold/outcome

Only after correlating the threshold with representation should the research attribute causality to a particular serialization or IPC layer.

6. Conclusion

The most interesting result of this review is not a single commit, but convergence around the same architectural boundaries:

Selection
   |
   +--> Context menu (STA-002) — direct upstream change
   |
   +--> Share / ProcessText (STA-003) — direct upstream change
   |
   +--> Web Search / Translate (STA-006/007) — direct upstream change
   |
   +--> Intent / IPC (STA-028, Class A) — upstream mitigations emerging
   |
   +--> UTF-16 representation (STA-028) — AOSP allocation evidence
   |
   +--> libminikin / UI thread (STA-017/019) — NO public upstream fix found

STA was created to study what happens when structured input crosses these kinds of boundaries and its effective processing cost changes along the way.

The 2026 Chromium and Android changes do not prove the STA model on their own, but they provide useful external evidence that:

These boundaries are real engineering constraints
They are areas of active defensive work
The specific surfaces studied by STA are exactly the surfaces being modified with limits and policy checks
Class A is being addressed; Class B is not

For STA-028 in particular, the combination of the AOSP Parcel conversion path and Chromium's native UTF-16 size handling makes serialization density a hypothesis worth testing rigorously.

Complete whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout — v6 (August 2026)

📌 About this series
This post is part of a series documenting the 32 vectors of Structured Text Amplification (STA).

Published:
✅ Upstream Android and Chromium Changes in 2026 (this post)

Coming next:
⬜ STA-005 — WhatsApp
⬜ STA-015-DL — Google Drive → SystemUI
⬜ STA-017 — Cross-engine ANR

Whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout — v5

— Lostmon · lostmon.blogspot.com

STA - UTF-16 Serialization Density Experiment v0.2 Structured Text Amplification

STA — UTF-16 Serialization Density Experiment v0.2

Structured Text Amplification

This post is part of the series documenting the 32 vectors of Structured Text Amplification (STA). The experiment presented here explores a fundamental property of Android: how the choice of characters in a string affects its in-memory size and, consequently, its ability to exhaust Binder limits and saturate the libminikin text engine.

The complete whitepaper, version v6, covers the research, methodology, evidence, and full vector catalog.

The experiment

Android stores strings internally in UTF-16. This means that the in-memory size of a string does not directly correlate with the number of characters (code points) or its UTF-8 size. The same number of characters can have very different UTF-16 footprints.

For example:

70,000 ASCII characters (/) occupy 140,000 bytes in UTF-16 (×2).
70,000 emojis (non-BMP, 😀) occupy 280,000 bytes in UTF-16 (×4).

This raises a key question for STA:

Can an attacker choose characters that maximize the UTF-16 footprint to reach the Binder limit (1 MB) with less input, or to saturate libminikin with more UTF-16 units?

The experiment I present here answers this question. The interactive tool I developed (v0.3) allows you to measure the UTF-16 density of any character, estimate Parcel/Binder size, and systematically explore thresholds.

The interactive tool

The following tool (PoC) measures the encoding properties of different characters and estimates the size they would occupy in a Binder transaction.

⏳ Status: Experimental

This tool measures encoding density and estimates Android Parcel / Binder size. It does not assert that these differences cause resource amplification. The goal is to quantify differences and explore correlation with STA behaviour.

🔬 Hypothesis under investigation:

Differences in UTF-16 representation (especially non-BMP characters) may shift the effective thresholds for Binder transaction limits, FragmentManager, libminikin and TaskPersister.

Character:

Code points:

(or click a character)

Generated string (70,000 code points):

📦 Estimated Parcel / Binder size

📐 Code-point equivalence: —

Number of code points of another character needed to match the current UTF-16 footprint.

📊 Comparison at same code-point length

Character	Code points	UTF-16 units	UTF-16 bytes	UTF-8 bytes	Ratio	Bytes / CP	Est. Parcel

🔍 Threshold exploration (Binder)

Current test: —

ASCII baseline (code points): (70k ASCII ≈ 140 KB UTF-16)

Equivalent code points of current character to match baseline UTF-16: —

📈 UTF-16 units vs code points

● BMP | ● Non-BMP | dashed line = 1:1 identity

📘 About this tool (v0.3 improvements):

Added estimated Parcel size (writeString + Bundle overhead + 4-byte padding).
Clear Binder risk levels: Safe (<100 KB), Warning (100-500 KB), Danger (>500 KB practical limit).
Custom character support + dark mode.
Export observations as JSON for collaborative #STAresearch.
More accurate equivalence and threshold calculations.
This remains a measurement tool. Security conclusions belong to the full STA research.

⬆ Back to the experiment

Key results

1. Different characters, different footprints

The following table shows the UTF-16 footprint of different characters for the same number of code points (70,000):

Character	Code points	UTF-16 bytes	UTF-8 bytes	UTF-16 / UTF-8 ratio
`/` (ASCII)	70,000	140,000	70,000	2.00×
`€` (Euro)	70,000	140,000	210,000	0.67×
`中` (CJK)	70,000	140,000	210,000	0.67×
`😀` (Emoji)	70,000	280,000	280,000	1.00×
`𝄞` (Musical)	70,000	280,000	280,000	1.00×

Key observation: ASCII characters double in size when converted to UTF-16. Non-BMP characters (emojis) are more compact in UTF-16 relative to UTF-8, but they occupy 4 bytes per character in memory.

2. Code-point equivalence

To match the UTF-16 footprint of 70,000 ASCII characters (140,000 bytes):

You need 35,000 emojis (😀) to reach the same 140,000 bytes.
You need 70,000 Euro characters (€) to reach the same 140,000 bytes.

This means the attacker can choose characters to control the relationship between code points and UTF-16 footprint.

3. Parcel / Binder estimation

The v0.3 tool estimates the actual size the string would occupy in a Binder transaction, including:

writeString() size (4-byte length + UTF-16 data + padding)
Bundle.putString() overhead (~44 additional bytes)

Binder risk is classified as:

SAFE (<100 KB)
WARNING (100-500 KB) — practical risk zone
DANGER (>500 KB) — very likely TransactionTooLargeException

The practical limit on many devices is around 500-520 KB, although the theoretical limit is 1 MB.

Implications for STA

This experiment demonstrates that an attacker can control the amplification by choosing specific characters. This affects:

Class A — Binder / SavedState / FragmentManager

STA-005 (WhatsApp): ASCII payload doubles in UTF-16, accelerating the Binder limit.
STA-012 (Threads): The attacker can choose ASCII to maximize Bundle size.
STA-015-DL (SystemUI): Corrupted state persists; UTF-16 size determines whether the limit is exceeded.
STA-022 (DuckDuckGo): 920 KB URL → 965 KB Parcel; with ASCII, the limit is reached faster.

Class B — libminikin / UI thread

STA-017 (Chrome/Firefox): More UTF-16 units → more O(n²) work for the line breaker.
STA-019 (Firefox address bar): The attacker controls the layout workload.

The ×20.6 factor in STA-005

The amplification factor observed in WhatsApp (×20.6) includes:

Encoding amplification: ASCII → UTF-16 (×2)
Structural amplification: FragmentManager adds metadata and overhead (×10+)

Key thresholds

Metric	Value	Notes
Theoretical Binder limit	1,048,576 bytes	Documented in AOSP
Practical limit on many devices	~500-520 KB	Before TransactionTooLargeException
ASCII characters to reach 1 MB	524,288	≈ half a million
Non-BMP characters to reach 1 MB	262,144	≈ a quarter million

Collaboration

The experiment includes an observation logger that allows you to save results with device, Android version, and observed STA behaviour. Observations can be exported as JSON for collaborative analysis.

If you have access to a device running a different Android version or OEM skin, run the experiment and share your results with the hashtag #STAresearch.

Methodological note

This experiment is a measurement tool, not a vulnerability in itself. It measures encoding properties that may correlate with STA behaviour observed in other vectors. The security impact is evaluated in the Class A and Class B vectors, not in the PoC itself.

Parcel/Binder estimates are approximate and may vary across devices, Android versions, and framework implementations. The PoC provides a quantitative basis for experimental exploration.

📌 Published:
✅ STA — UTF-16 Serialization Density Experiment

📌 Coming next:
⬜ STA — Finding the Binder threshold
⬜ STA-005 — WhatsApp
⬜ STA-015-DL — Google Drive → SystemUI
⬜ STA-017 — Cross-engine ANR

— Lostmon · lostmon.blogspot.com

STA-002- When an oversized link reaches Android's context menu

Thursday, August 13, 2026

Structured Text Amplification - Vector 002

This post is the first in a series documenting the 32 vectors of Structured Text Amplification (STA). The complete whitepaper, version v5, covers the research, methodology, evidence, and full vector catalog.

During the development of the Structured Text Amplification (STA) research, a pattern emerged that initially could have appeared to be an isolated application behaviour: an unusually large structured input can affect the processing that occurs when a user interacts with a link and its context menu is constructed.

This behaviour was documented as STA-002 within the research catalog.

The significance of STA-002 does not lie in presenting the greatest impact among all vectors. It lies in something more interesting from a research perspective:

The STA pattern can appear even in seemingly basic interaction surfaces.

This raises a question that will run through this entire series:

If a structured input can generate a disproportionate cost in a surface as simple as a context menu, what happens when that same input traverses deeper layers of the system?

Affected browsers and devices

STA-002 was observed in the following context:

Browsers: Google Chrome, Microsoft Edge, and other Chromium-based browsers on Android. The behaviour is not specific to a single browser engine; it appears in the interaction between the browser and the Android framework's context menu construction.

Devices tested: The behaviour was reproduced on multiple production devices across different OEMs, including:

Xiaomi Redmi Note 14 5G (HyperOS 3.0 / Android 16)
Google Pixel 7 (Android 13–15)
Samsung Galaxy series (One UI, Android 14–15)
OPPO A78 / A6 5G (ColorOS, Android 14–16)
OnePlus 11 (OxygenOS, Android 14)

This cross-OEM recurrence suggests the issue is not a manufacturer-specific customization, but rather a pattern present in the shared Android framework and browser interaction paths.

Timeline

The following timeline documents the discovery and reporting of STA-002:

Date	Event
28 Aug 2022	Original observation: TransactionTooLargeException / DeadSystemException in Firefox Focus & Nightly during clipboard, share, and open-in-app actions.
12 Oct 2022	First public advisory published: "Mozilla Firefox Focus and Nightly for Android Remote Crash DoS" (lostmon.blogspot.com).
Nov 2022	Chromium Issue 40879254 opened. Security labels removed; partial UX patch applied; issue remained open.
Nov 2022	Mozilla Bugzilla #1802594 (S3) opened — still NEW / unresolved as of 2026.
20 Jan 2026	Formal report to Google Android VRP (A-477279924) and Microsoft MSRC. Chrome VRP filing covering 27 vectors (Issue 477202817) closed same day as "Won't Fix (Intended Behavior)".
Feb 2026	Whitepaper v4 distributed (27 vectors).
24 May 2026	Chrome bugreport captures two full native ANRs, establishing STA-017 as Tier A.
30 Jul 2026	Public whitepaper disclosure — lostmon.blogspot.com.
Aug 2026	STA-001 published as part of the public blog series documenting all 32 STA vectors.

The scenario

The scenario is straightforward:

Web page
        │
        ▼
Link with an unusually large URL
        │
        ▼
User long-presses the link
        │
        ▼
Browser / Android builds the context menu
        │
        ▼
Processing of the URL content
        │
        ▼
Anomalous behaviour / degradation

The important characteristic is that the user does not need to perform a technically complex operation.

The interaction is apparently normal:

long-pressing a link.

However, that action causes the content associated with the link to traverse an additional processing chain.

Where does amplification appear?

The STA model studies precisely this type of path.

A structured input — in this case, a URL — enters an interaction surface and may end up being processed by different layers.

The important point is not solely the initial size of the input, but the cost it can acquire during its processing and propagation.

The conceptual path can be represented as follows:

INPUT
  │
  │ Structured URL
  ▼
Browser
  │
  │ selection / context
  ▼
Context-menu processing
  │
  │ transformation / analysis
  ▼
Text processing
  │
  ▼
Cost amplification

Therefore:

The size of the input data does not necessarily represent the final cost of processing it.

That is one of the principles that STA seeks to study.

Trigger

The documented trigger for STA-002 is:

Long-press on link → context menu

In the whitepaper's catalog, STA-002 appears with an estimated CVSS of 3.7.

(CVSS 3.1: AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L)

This rating corresponds to a scenario of limited impact, requiring user interaction and with no persistence.

This is important because STA-002 should not be confused with later vectors in the research that present persistence or systemic impacts.

Persistence

A relevant characteristic of STA-002 is precisely its lack of persistence.

The behaviour is associated with the processing that occurs during interaction with the context menu.

There is no documented evidence that the payload is permanently stored and continues to trigger the behaviour in subsequent sessions.

This differentiates it from other vectors in the catalog where the contaminated input ends up stored in history, activity state, or other persistent structures.

Why is it interesting within STA?

At first glance, a problem limited to the processing associated with a context menu might appear to be simply an application issue.

But from the STA perspective, it is interesting because it shows a recurring characteristic:

An apparently ordinary input can traverse a processing surface without there being a limitation proportional to the cost it can generate.

The goal of STA is not to claim that all documented behaviours have exactly the same technical cause.

The goal is to identify an architectural pattern that appears when structured data traverses different layers of Android and its applications.

Furthermore, the research distinguishes between problems that are specific to an application and those where a framework characteristic can amplify their consequences.

That distinction is fundamental: the fact that a behaviour can propagate through the framework does not automatically mean that the original defect belongs to the framework.

Evidence

STA-002 is classified in the whitepaper as:

Tier B — Behavioral

This means that there is evidence based on observed behaviour, but that for this specific vector there is insufficient low-level evidence to classify it as Tier A.

In particular, STA-002 should not be presented as if a complete native stack trace existed that, by itself, demonstrated the entire causal chain.

This distinction is part of the STA methodology and is important for maintaining a clear separation between:

observed behaviour;
inferred mechanism;
mechanism demonstrated through low-level evidence.

Conceptual mitigation

Mitigation should occur before the data can generate a disproportionate cost.

For this type of surface, the general approach would be:

URL received
    │
    ▼
Size validation
    │
    ├── within limit ──► processing
    │
    └── outside limit ──► truncate / reject

The idea is not simply to detect specific strings or characters.

Defence must establish reasonable limits on the amount and complexity of data that an operation can process, especially when that operation runs synchronously.

STA-002 within the research map

STA-002 is important not because it is the highest-impact vector, but because it is part of the early observations that helped build the STA model.

Subsequently, vectors with much more severe characteristics appeared:

persistence;
state contamination;
resource exhaustion;
inter-process interaction;
impacts on system components;
and other forms of amplification.

These cases allowed us to study whether the observed behaviours could be understood as completely independent incidents or whether a common pattern existed.

Version v5 of the whitepaper documents 32 vectors within the Structured Text Amplification framework.

Why publish a Tier B vector?

Because the value of research does not depend exclusively on every observation having the same depth of evidence.

STA-002 serves to show how the model began to be constructed.

The fact that the vector has a Tier B classification does not automatically make it irrelevant. It means that the level of certainty must be expressed correctly.

Methodology matters as much as the finding.

Methodological note

STA-002 should not be presented as "an exploit that breaks Android".

It is much more accurate to describe it as:

A case where a structured input can provoke a disproportionate cost during an apparently normal interaction with a link and its context menu.

That formulation reflects the level of available evidence and avoids overstating conclusions that Tier B material does not, by itself, allow us to demonstrate.

And precisely for that reason, STA-002 makes a good starting point for this series.

Not all vectors have the same impact.
Not all have the same mechanism.
Not all have the same level of evidence.

What we are investigating is whether, behind them, a common pattern exists.

Structured Text Amplification

STA-002 is just the second chapter.

As we move through the catalog, vectors with very different mechanisms, surfaces, and impacts will appear.

The question will always be the same:

What happens when an apparently innocuous data item acquires a very different cost as it traverses the layers that process it?

That is the problem that Structured Text Amplification seeks to study.

Whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout — v6 (August 2026)

📌 About this series
This post is part of a series documenting the 32 vectors of Structured Text Amplification (STA). The aim of the series is to present each vector independently, with its mechanism, impact, and evidence, while maintaining traceability with the complete whitepaper.

Published:
- STA-001 — Context menu (this post)

Next posts (upcoming):
- STA-005 — WhatsApp
- STA-015-DL — Google Drive → SystemUI
- STA-017 — Cross-engine ANR
- STA-027 — Copilot prompt injection
- And more...

Whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout — v5

Note: To maintain research traceability, each article in this series corresponds to a specific STA identifier and follows the same structure: mechanism, trigger, persistence, evidence, impact, mitigation, and confidence level. This way, the blog functions as a progressive public catalog of the STA research, while the whitepaper remains the consolidated technical reference.

Manuel García Peña (Lostmon)
Independent security researcher
lostmon.blogspot.com

Lostmon Blogger