Analysis and Solution of Inline Crash in Android TV Plugin Architecture

Updating Android TV applications is challenging due to device‑vendor restrictions and low user willingness to manually update. Plugin‑based hot‑update becomes a necessary technique to automatically refresh business capabilities without installing a new APK.

The plugin technology deeply leverages Android's private capabilities and must adapt to various Android versions. Supporting low‑performance devices requires loading plugins and TV logic in the same dex, while high‑version systems suffer from inline crashes when the same architecture is used.

Background

Inline (method inlining) is a compiler optimization that replaces a method call with the method body, reducing call overhead but increasing instruction count.

In Kotlin, the inline keyword forces inlining at compile time. However, the inline crashes discussed here are performed by the ART runtime during JIT/AOT compilation, not by the language.

Inline Crash Scenario

Characteristics:

The crash occurs only when the EPG plugin (host plugin) is running; it never happens in the one‑version baseline.

Only the EPG plugin exhibits the issue; other plugins (screen casting, settings, sports) do not.

The crash is observed on Android 9.0 (Pie) devices.

The abort message typically looks like:

entrypoint_utils-inl.h:94] Inlined method resolution crossed dex file boundary: from void com.gala.video.plugincenter.download.downloader.DownloadManager$TaskHolder.progress(...)

The corresponding stack trace is shown in the original article (image).

Cause Analysis

When a method is inlined across dex files, the generated machine code may reference outdated DexCache offsets, leading to mismatched class resolution and unpredictable native crashes.

In the one‑version baseline, host and EPG code reside in the same dex, allowing inlining. After a plugin upgrade, the EPG code moves to a new dex while the host remains unchanged, creating a cross‑dex inlining situation that triggers the crash.

Industry Solution – Tinker

Tinker avoids the problem by discarding incremental dex synthesis under ART and generating a full new dex, ensuring all methods come from the same dex and preventing cross‑dex inlining.

Our Solution

Since we cannot restructure the plugin architecture like Tinker, we focus on preventing inlining in the one‑version APK. The strategy includes:

Precisely locating potential inline call sites by scanning bytecode during the Gradle transform phase.

Inserting a try‑catch block (or other non‑trivial code) into those methods to break the inlining conditions.

We evaluated two approaches:

ClassLoader Splitting : Loading classes from the same dex with different ClassLoaders to treat them as separate dex files. This was abandoned due to complexity and risk.

Insert Try‑Catch : Adding a try block with side‑effect code to the target methods, which prevents the ART optimizer from inlining them.

The bytecode insertion is illustrated in the article (image). Empty try blocks are optimized away, so a minimal side‑effect statement is required.

Conclusion

The article presents a TV‑specific solution to inline crashes: automatically detect possible inline call points during compilation and inject bytecode to block inlining. This method has been validated across several versions and effectively resolves the inline crash issue on Android TV.