A New Approach to Mobile App Online Issue Localization Using Cloud Plugins

Background

Mobile app pluginization is a platform‑level solution that overcomes system limits (65535), decouples modules, and supports multi‑team collaboration. Its key feature is dynamic module delivery, which brings obvious product benefits. At Baidu, this system has inspired new ideas for mobile testing.

Typical Online Issue Localization Scenarios on Mobile

Scenario 1: Cloud users report a feature is unavailable; developers cannot reproduce the issue because client logs are incomplete, leading to a dead‑end.

Scenario 2: Pre‑embedded client telemetry often misses events, yet full interaction logs are needed for reproducible debugging without code changes.

Scenario 3: Many useful offline SDK tools cannot be integrated due to performance impact or scheduling constraints, leaving many online issues undiscovered.

Scenario 4: Small‑scale online experiments show that top issues follow a normal distribution and can be captured from a tiny user sample.

Typical Offline Testing Scenarios on Mobile

Scenario 1: A QA engineer needs a full stack of analysis abilities (ANR, crash, jank, memory leak, CPU, battery, startup time, etc.) without deep expertise; the goal is a one‑click solution for comprehensive client‑side diagnostics.

Scenario 2: Offline testing capabilities must be applied to a minimal user base to recover as many issues as possible while keeping user impact low.

A New Idea for Online Issue Localization on Mobile

By building a testing plugin that packages valuable offline testing capabilities (e.g., Dexposed, LeakCanary, TraceViewer, Choreographer, ActivityLifecycleCallback) and delivering it through an existing cloud‑based dynamic module system, issues can be continuously exposed on targeted devices.

How Cloud Plugins Work

The cloud plugin is itself just another host plugin. Its testing power comes from the large number of offline test scenarios packaged inside and the dynamic loading mechanism that enables those scenarios to run online.

Parent‑delegation mechanism: In Java’s class‑loader hierarchy, a child classloader can delegate to its parent, allowing the cloud plugin to discover host classes.

DexClassLoader: Loads arbitrary JAR/Dex/ZIP/APK files from the file system.

PatchClassLoader: Loads only APKs located in data/app/ , commonly used for multi‑dex projects.

DexFile: Loads dynamic files and extracts internal class information, a capability not provided by DexClassLoader.

“Hatching”: The plugin integrates a log‑upload class at compile time without embedding it directly, enabling callbacks to the host’s logging system after the plugin is loaded.

With the above mechanisms, JAR or APK packages containing test scenarios can be dynamically loaded by the cloud plugin, allowing it to read, collect, and inject information from the host, its local storage, and related system components. Hooking, reflection, code injection, exception capture, and instrumentation become merely implementation techniques.

Example

Note: Although the following case focuses on cloud‑plugin issue localization, the same SDK can be integrated into any app. Developers must consider security implications, especially on rooted devices where the app may be fully exposed.

Case study: measuring UI smoothness. Smoothness is perceived when the eye receives 60 frames per second within one second. Android 4.1 introduced Project Buffer, VSYNC, Triple Buffer, and the Choreographer, which coordinates all Loopers via a shared Choreographer object.

Choreographer exposes a FrameCallback; each frame triggers doFrame, allowing calculation of the number of frames rendered per second. However, using this directly in production is discouraged.

Instead, we embed the logic into a cloud debugging plugin. The implementation is straightforward: copy the code snippet into any Android project, add NutXError as a compile‑time dependency, and the plugin can be loaded and executed if a plugin system already exists.

Result

The screenshot below shows a smoothness issue detected while the client was running; the monitoring case was loaded dynamically via the cloud plugin. The UI flow where the issue occurred is also visualized, enabling offline teams to reproduce the problem using the captured trace.

Postscript

The discussion concludes Baidu’s mobile testing technique, but many aspects remain unaddressed, such as the existing automated cases, compatibility of the mechanism, and how to control versioning and safety of the cloud debugging plugin (named “JianGuo Cloud”). In practice, Baidu’s online environment already runs a full dynamic‑module, small‑traffic system where the cloud plugin acts as a dynamic module that activates when issues arise.