How to Automate Mobile Bug Reporting with an SDK: From Capture to Submission

1. Project Background

To ensure the quality of externally released apps, extensive regression and functional testing are performed before each release. During daily testing, communication gaps between developers and testers often lead to inefficient bug reporting. The existing reporting process suffers from low feedback efficiency, long feedback paths, inconvenient operations, and high communication costs due to mismatched descriptions and missing runtime data such as device model, version, crash files, and network logs.

2. Project Goals

Leverage technology to automate data filling and submission, aiming to simplify the reporting method so that anyone can report issues, shorten feedback paths, and automatically populate necessary information.

3. Project Plan

3.1 Bug Description Scheme

An effective bug report consists of four parts: system and app information, bug description, resource attachment information, and runtime context data. Except for the bug description, the other parts can be auto‑filled by the program, enabling a streamlined reporting workflow.

3.2 Path Optimization Scheme

Step 1: Testers trigger the reporting function; the SDK collects and edits resources (images, videos) and automatically associates runtime data (network, logs). Step 2: On the bug creation page, fill in the title and project, validate the content, and submit to the Max platform. Step 3: The bug is automatically assigned and a Lark notification is sent to the responsible developer.

3.3 SDK Architecture Scheme

The architecture involves three systems: Max backend, reporting SDK, and the business app.

Configuration module retrieves the project list from the Max backend.

Strategy module updates page and personnel mapping tables.

Collection module performs code injection and data monitoring.

When an app exception occurs, the dispatch module saves context data.

Dispatch module assembles final data (images, files, context).

Upload module creates the bug and uploads it.

3.4 UI Interaction Scheme

Illustrated UI flow for triggering bug reporting, editing captured assets, and submitting the bug.

4. Project Implementation

4.1 Image Capture

Active capture: Obtain a screenshot by accessing the Android DecorView, the top‑level view containing all UI controls.

Passive capture: Listen for media store changes. For Flutter pages, DecorView yields a black screen, so passive capture uses a ContentObserver to detect newly inserted images that meet time (within 10 s), size (not exceeding screen dimensions), and path (containing keywords like "screenshot") criteria.

Core implementation diagrams are shown below.

4.2 Network Capture

The SDK intercepts complete network request data, assembling the request (method, URL, cookies, etc.) and the server response. Since the app uses the open‑source OkHttp library, ASM and Gradle Transform techniques inject the reporting SDK’s network interceptor into OkHttp at compile time, enabling real‑time capture of runtime network data.

5. Automated Build

Option 1: Integrate the SDK into the business code and enable initialization only in non‑release builds.

Option 2: Use a dual‑branch strategy: the stable Dev branch contains normal code, while a Dev_BugReport branch adds the SDK for testing builds. Release APKs are built from Dev, ensuring the SDK is absent from production.

6. Result Showcase

Demonstrations include triggering the SDK, editing captured assets, auto‑filling bug title, module, and runtime data, creating the bug in the Max backend, copying the link to the clipboard, and sending the link via Lark to the QA team.

7. Future Planning

Planned enhancements include adding log collection, improving shake‑to‑report sensitivity, refining UI style, and further automating bug‑to‑developer association.

8. User Feedback

A table of requirements, priorities, and progress tracks the completion status of features such as image editing, automatic version filling, screen recording, log collection, and UI suggestions.