AppErrorsTracking: an Xposed module that puts the Android crash dialog back

The crash dialog that Chinese ROMs removed

The starting point is an observation the author makes in the README. On ROMs common in mainland China, with the exception of MIUI in its non stable versions, the system dialog that appears when an app crashes has been deleted, so the app simply exits and the user sees nothing. The author describes decompiling the system framework to confirm the dialog was genuinely removed rather than merely hidden, and asks whether hiding the error from the user is really the intended product decision.

That is the whole problem this module addresses. A developer who cannot connect a computer and cannot run ADB has no way to retrieve the crash log, and a user without developer access has no way to report it. The module is designed for that situation: it replaces the system's app error dialog entirely, so the information appears on the device itself.

The audience is stated plainly in the README, which says the project is specially designed for Android developers, while adding that a non developer can still install it to hand exception information to a developer. Minimum support is Android 7.0, and the module works on any Android system but has so far only been tested in LSPosed.

Hooking the framework instead of registering an exception handler

The mechanism is the interesting part, and it is different from the usual approach. The README contrasts the module with Thread.UncaughtExceptionHandler, which is the standard way an app registers a callback for uncaught exceptions on its own threads. Instead of that, this module captures app errors in all directions by injecting into the system framework, and the README states that this avoids generating additional registration monitoring and is better for performance than the original exception monitoring approach.

The second benefit follows from where the hook sits. Because the capture happens at the system level, the module can also capture the stack trace of the native platform, which an in-process handler inside a single application cannot reach. Native crashes, which in Java and Kotlin apps usually surface as an abort rather than a Java exception, are exactly the ones that tend to go missing when a developer reads only the app side log.

The tradeoff is scope. A system level hook sees the whole device rather than one application, which is what makes the module able to report on any installed app, but it also means the module needs privileges that an ordinary application cannot obtain.

The blind spot: apps that handle their own crashes

The README has a precautions section, and it is short enough to be worth reading twice. Errors captured at the system level can only be errors that the app itself did not handle. If an app installs a custom Thread.UncaughtExceptionHandler, of the kind used by products such as Bugly to collect errors automatically, the system cannot tell whether the app actually crashed.

In practice that means a missing log is not proof of an absence of a crash. An app with its own reporting SDK may swallow the exception, show its own dialog, or restart itself, and this module has nothing to record in that case. For a developer whose app already has a crash reporting library, this module tells you nothing new about that app and only covers the third party apps installed alongside it.

That limitation also sets the boundary of the tool. It is a diagnostic aid for the crashes your own test device throws at you during development, not a telemetry pipeline, and it has no facility for uploading anything. The README does not describe any export destination beyond copying, sharing and exporting a stack trace.

What the module interface actually gives you

The features list is short and mostly about what happens to a captured error once it exists. The module completely replaces the system app error dialog, so the crash appears in the module's own interface rather than in the stock one. Exceptions are logged per app and the log persists until restart, which matters because a crash that kills the process would otherwise take its log with it.

From there the module adds the handling you would otherwise do by hand. There are copy, share and export functions for the stack trace, so the error can be moved off the device into a chat message or a bug report. There is an error history record function, reachable from a notification bar tile named errors history record as well as from the main interface of the module, which is how you recover a crash that scrolled past while you were busy. Error statistics per app are included, and there is a display function for multi-process apps, where the crash happens in a process other than the main one.

Taken together this is closer to a small crash log browser than a dialog replacement. The notification tile is the detail that most improves the workflow, since it removes the need to open the module right after every crash.

Where the builds are published, and why the channel matters

The README is unusually firm about distribution. A release channel table lists four routes: GitHub CI, described as an automatic build producing a test version; a Telegram CI channel, also an automatic build producing a test version; GitHub Releases, described as the formal stable edition; and the Xposed-Modules-Repo, likewise the formal stable edition. The README states that releases of this module are limited to the urls listed there, and that the project has nothing to do with versions downloaded from other informal channels.

For an Xposed module that is the correct position to take, since repackaged zips circulate easily and a module is code that runs with elevated privileges inside other applications. If you are evaluating this project, get the artifact from the Xposed-Modules-Repo release page or the GitHub releases page rather than from a mirror, and note that the CI channels are explicitly labelled test builds.

The repository also ships translated readmes in Simplified Chinese and Japanese alongside the English one, and the project invites translation contributions. That tells you the maintainer expects the module to be used by developers across regions, which matches the problem it was written to solve.

Building from source, where a Gradle project and a secret directory sit

There is no installation guide in the README, which is expected for an Xposed module: the install step is not a command but a state of the device, namely a rooted environment with a working LSPosed installation, after which the module is enabled from the LSPosed manager. The README states that the module can be used in any Android system and is currently only tested in LSPosed, so that qualification should be taken at face value.

For anyone who wants to build rather than install, the repository is a Gradle project in Kotlin. The root holds build.gradle.kts and settings.gradle.kts, the Gradle wrapper with gradlew and gradlew.bat, a gradle.properties file and a .editorconfig, plus two application modules, module-app and demo-app. The demo-app module is there so you can trigger a crash deliberately while testing the module, which is the sensible way to confirm that capture works on your own ROM before you rely on it.

Two entries in the tree are worth noting. A .secret directory sits at the root, which in a project of this kind usually holds signing or release configuration, and an .idea directory is committed rather than ignored. Neither has a documented purpose in the README, but their presence tells you the release process is set up for signed artifacts.

Commits continue while the release tags stopped in 2023

The maintenance picture needs reading carefully. The repository is not archived and the last push was on 2026-10-20, which is recent. The release history, however, tells a different story: the newest tagged version is 1.3 from 2023-11-03, preceded by 1.25 from 2023-04-16 and 1.2 from 2023-01-23.

The numbering itself is irregular, since 1.25 was published before 1.2, so version numbers are not a reliable ordering here. And a nearly three year gap between the last release and the last commit means that whatever is on the default branch may differ from what the stable channels are serving.

Two things follow for an adopter. First, the README does not document a rollback path, so if a CI test build breaks your module setup, there is no stated way to return to a known good artifact other than reinstalling an older release from the release page. Second, the licence is AGPL-3.0, which is the strongest copyleft of the common open source licences and carries obligations that matter if you ever want to read, modify or redistribute the code inside a product you ship. Developers using it only as a debugging tool on their own device are unaffected, but anyone considering folding the code into their own tooling should look at the licence text in the repository before going further.

Editorial conclusion

Adopt AppErrorsTracking when you are an Android developer debugging a crash on a device you cannot reach with ADB, especially on a Chinese ROM that has removed the system crash dialog, and you have a rooted environment with LSPosed available. Do not adopt it as a production crash reporter, since an app that installs its own Thread.UncaughtExceptionHandler hides the very crashes you want to see, and it is not usable at all on a stock unrooted device. Verify first that your LSPosed version and your Android version are supported, because the README states the module has only been tested in LSPosed with Android 7.0 as the minimum, and check the Xposed-Modules-Repo release page for the current build since the newest tagged release in the repository history dates from 2023-11-03.

Frequently asked questions

Official sources

1. Issues
2. KitsunePie/AppErrorsTracking on GitHub
3. License: AGPL-3.0
4. README
5. Releases