Tencent's XLog Remains the Only Self-Contained Android Logging Library That Doesn't Lock You Out of Your Own Data
A logging library that encrypts your own data and refuses to give you a key is a liability, not a feature. XLog's standalone decoder means incident response stays under your control — no dependency on a vendor's server, no forced workflow, no lock-in.
Business-heavy Android apps break in ways that never produce a crash report. A wrong price, a missing discount, a skipped step in a checkout flow — none of these trigger a stack trace, but they all destroy trust. Online logging frameworks exist to capture those silent failures, and the field on Android has narrowed to two real contenders: Tencent's XLog and Meituan's Logan. Both use mmap-backed storage with AES encryption to avoid the I/O bottlenecks that make file-based logging dangerous in production.
Logan is better maintained and ships with a full log-retrieval pipeline, but it encrypts everything by force and provides no standalone decoder. You decrypt logs only through Logan Server, which means adopting Meituan's entire backend workflow just to read a file. XLog, abandoned publicly since 2018, still works. Its AAR compiles, its .so files cover the two ARM ABIs that matter, and a single Python script turns any .xlog binary back into readable text.
Integration requires pulling the AAR from a third-party mirror or storing it locally, adding ProGuard rules the official docs omit, and limiting ndk abiFilters to armeabi-v7a and arm64-v8a. Once initialized with separate cache and log directories, the API mirrors android.util.Log levels and supports async or sync flushing. The trade-off is clear: a stale but self-contained library beats an actively maintained one that holds your data hostage.
Log encryption without a standalone decoder is a form of vendor lock-in dressed as security — it forces adoption of an entire backend stack just to read a file.
XLog's abandonment is a feature, not a bug: a library frozen in time avoids the churn that breaks integrations, as long as the core mechanism (mmap + zlib) remains stable.
The real cost of Logan isn't technical complexity but organizational dependency — incident response now requires a server to be up, authenticated, and reachable.
Most Android logging libraries are just logcat wrappers; the jump to mmap-based persistence is what separates toy logging from production forensics.
Tencent's pattern of publishing then abandoning open-source projects creates a scavenger economy where developers extract value from orphaned code long after the corporate sponsor has moved on.
ProGuard rules being absent from official docs but required for release builds is a signal that the library was tested internally in a debug-only workflow and never hardened for external distribution.
The discussion pivots on a claimed practical obstacle with XLog: its lack of 16KB page alignment, which one commenter calls more troublesome than Logan's server-side decryption dependency. Counterpoints argue the alignment problem is trivial — solvable through a CMake flag, zipalign, recompilation, or a quick AI-assisted fork.
Logan's decryption logic can just be copied out from the server side. On the contrary, the real headache with XLog is that it doesn't maintain 16KB alignment and other such issues [sweat]
16KB compilation — just add an option in CMake.
This can be solved with zipalign or by recompiling.