Comprehensive Practices for Ensuring Android App Stability Across Development, Gray Release, and Operations

Preface

Mobile app stability is crucial for user experience and commercial value. Crashes cause business interruption, user churn, brand damage, and reduced lifecycle value. Stability also includes jank, power consumption, and overall business availability.

Below we describe, in chronological order, what SoulAPP Android does to continuously control app stability.

Development Phase

Stability issues discovered only after launch cause loss; therefore prevention is more important than later optimization. Because pre‑release users are limited, exposing problems early is a key challenge.

During development we take the following actions to guarantee stability before the app reaches users.

R&D Measures

Technical design review: early review prevents CPU‑intensive or memory‑heavy designs.

SDK stability: third‑party SDKs are evaluated and providers must supply stability reports.

Disaster‑filtering: fallback strategies are filtered out of development and test builds to ensure issues surface.

Lint coding standards: automatic lint checks detect violations during coding and raise errors.

Architecture optimization: ability convergence and unified fault‑tolerance improve reliability; common libraries encapsulate base functions with unified error handling.

Method‑Not‑Found detection: a tool scans for removed public methods in shared libraries during regression and before release.

Testing Measures

UI automation: executed before each release to ensure basic business stability.

Monkey testing: daily automated stress tests expose performance problems.

Performance regression: generates CPU, memory, crash, ANR reports for each business scenario before release.

Offline crash statistics: special monitoring and alerts for upcoming releases to catch potential stability issues.

Gray Release Phase

After full regression in the development stage, the gray‑release stage usually guarantees no major issues. However, urgent fixes and code merges during gray can introduce unforeseen problems that are not covered by a full regression, so a strict process is required.

Gray release also provides a larger user base to expose issues missed in development, acting as a crucial stability safeguard.

Gray Release Process

New versions follow multiple gray‑release rounds before full rollout, minimizing impact by exposing problems early.

Strict Change Review

Because only targeted tests are run during gray, every code change undergoes functional testing, leader code review, and test review before merging into the production package.

Crash & ANR Monitoring & Fixes

Stability monitoring relies mainly on Bugly. While Bugly provides rich data, its alert dimensions are limited; we need finer‑grained alerts to identify which specific crash spikes.

We built a monitoring tool on top of Bugly that runs scripts after full rollout, instantly detecting and alerting on crash spikes.

Crash & ANR Spike Analysis

Bugly’s aggregation sometimes fails to group identical crashes, making it hard to pinpoint the cause of overall crash rate increases. To address this, we developed tools that:

Rank crashes by the increase in affected users, revealing which crashes drive the spike.

Aggregate crashes by stack‑trace keywords to prioritize high‑impact cases.

Data analysis workflow: fetch data from Bugly, then use SQL for deeper analysis.

Disaster Recovery

Feature Switch & AB Control

Configuration center controls feature switches. New features can be hidden behind a switch that can be turned off instantly if an emergency occurs, ensuring controlled rollout.

For code refactoring, the old implementation is retained and toggled via configuration, allowing quick rollback.

Crash Safety‑Net (Java Layer)

When an uncaught exception occurs on the main thread, the Looper stops, causing UI freeze. Our safety‑net captures such exceptions, restarts the Looper, and keeps the app responsive.

// Get the system default UncaughtException handler
mDefaultHandler = Thread.getDefaultUncaughtExceptionHandler();
// Register custom UncaughtExceptionHandler
Thread.setDefaultUncaughtExceptionHandler((Thread t, Throwable e) -> {
    handleUnCatchException(t, e);
});
// Match stack trace
if (isExceptionCrash(e)) {
    // If stack does not match, delegate to default handler (normal crash)
    mDefaultHandler.uncaughtException(t, e);
    return;
}
// If stack matches, intercept
// If on main thread, restart Looper
if (t == Looper.getMainLooper().getThread()) {
    while (true) {
        try {
            Looper.loop();
        } catch (Throwable e) {
            if (isExceptionCrash(e)) {
                mDefaultHandler.uncaughtException(Looper.getMainLooper().getThread(), e);
                return;
            }
        }
    }
}

Native Crash Safety‑Net

We also implement a safety‑net at the native layer to catch uncaught native crashes.

Router‑Based Client Disaster Recovery

After componentization, page navigation uses a router. If an exception occurs, the router can intercept the navigation, show a friendly message, or redirect to an error page, reducing user impact.

Single‑Point Investigation

For individual user‑reported issues, we rely on multi‑dimensional logs (behavioral events, system/business logs, device performance metrics). Optimized log upload policies keep logs on the device most of the time, reducing performance impact while ensuring logs are available when needed.

Issue Post‑mortem & Case Learning

We regularly document and review difficult cases, turning experience into knowledge to avoid repeat mistakes and continuously improve software stability and reliability.

Conclusion

Current gaps include insufficient control over third‑party SDKs, incomplete switch coverage, lost user logs, and limited disaster‑recovery scope. Maintaining high‑level stability is an ongoing effort that requires continuous investment, as code decay inevitably introduces new risks.