LibChecker: inspecting the libraries inside Android apps

What LibChecker answers that a file manager cannot

An installed Android app is a bundle of code you did not write. The README describes LibChecker as a tool that helps you inspect libraries and package details used by Android apps. That is a narrower job than decompiling. LibChecker takes an installed app, an APK file, a split package (the APKS-style bundles), or a previously captured snapshot, and turns it into a readable list: which known SDKs and libraries are present, what native libraries ship with it, which permissions and components the manifest declares, and how the signature is set up.

The audience is fairly specific. Someone auditing what an app pulls in, a developer checking whether a dependency crept into a release build, or a user who wants to know why a simple utility requests a long list of permissions. All of those people want the answer on the phone, not in a desktop decompiler session. LibChecker is built for that: point it at a package, read the result.

How rule matching and native library analysis work

The detection layer is not inside the app alone. LibChecker matches against LibChecker-Rules, a separate repository, and the README lists what those rules can key on: native libraries, components, permissions, metadata, package names, shared UIDs, signatures, and intent actions. That is the core mechanism. A rule says, in effect, that this package name prefix, this permission, this signature or this .so file indicates a particular library, and the app reports a match. The rules are data, so coverage grows without shipping a new APK, and the README points to a mirror of the rules on GitLab alongside the GitHub copy.

Native library handling goes deeper than a filename list. The README says LibChecker reports ABI and native library details including 32-bit and 64-bit architecture, multi-architecture packages, 16 KB page-size readiness, ZIP alignment, stripped symbol tables, and native library extraction. Those checks matter for packaging work: a library that is not 16 KB aligned or that ships only one ABI is a real distribution problem, and the app surfaces it as a property of the file rather than a guess.

The rest of the surface is package metadata. Manifest entries, permissions, signing schemes, installation source, DEX optimization status, alternative launch icons, themed icons, Overlay apps, and Modern Xposed API module information are all listed as covered. Snapshots are the other half: you capture the state of installed apps, compare changes over time, back up or restore the snapshot set, and compare a saved package against what is currently installed. That comparison is the feature that turns a one-off inspection into something you can run periodically.

Installing LibChecker and reading your first app

There is no build-from-source instruction in the README, and no package manager command. The project distributes through app stores: the README shows Google Play, F-Droid, and the IzzyOnDroid repository, with the package name com.absinthe.libchecker. The F-Droid listing is the one to use if you want the store to track updates for you.

If you do build it, the repository is a Gradle project with a gradlew wrapper at the top level and an app module, so the standard wrapper invocation is the entry point. The README does not document the required JDK or Android SDK versions, so treat the wrapper and the build-logic directory as the source of truth rather than a version you assume.

git clone https://github.com/LibChecker/LibChecker.git
cd LibChecker
./gradlew assembleDebug

Once installed, the first useful run is on an app you already trust, so you have a baseline. Open LibChecker, pick an installed app from the list, and read the library section. Matches come from LibChecker-Rules, so a library that is present but not covered by a rule will not appear under a friendly name. The README also notes that large APK download links can be shared to LibChecker, and that APK and APKS-style files can be analyzed directly, which is how you inspect something you have not installed.

The second step is a snapshot. Capture the installed app set, then compare after an update to see which libraries or permissions changed. The README describes backup and restore for snapshots, and comparison of a saved package against the current installation, so this is the intended workflow rather than an afterthought.

For sharing results, Settings can export app information, and the README says the exported file opens in the WebUI at lc.absinthe.life. That WebUI lives in the LibChecker/tgbot project together with a Telegram bot and a shared JavaScript analyzer, and the README states it processes packages locally in the browser.

Where LibChecker stops being the right tool

LibChecker identifies and reports. It does not decompile, and the README makes no claim that it does. If you need to read the actual code inside a DEX file, rename symbols, or rebuild an APK, you need a different class of tool, and LibChecker will only tell you which libraries you are about to look at.

Rule coverage is the second boundary, and it is the one that bites quietly. Detection depends on LibChecker-Rules matching something in the package. A library with no rule can still be visible through its native file or package name, but you will not get the labelled verdict that makes the output readable. The README does not describe what the app shows for an unmatched library, so the honest position is that the labelled result depends on the rules repository being current for whatever you are inspecting.

Platform support is explicit and narrow: Android 7.0 to 17, with a marshmallow branch for Android 6. There is no iOS build, despite what search traffic around the name suggests, and no desktop application. The WebUI is browser-based and handles exported files and package analysis, but it is a companion to the Android app, not a replacement for a desktop reverse-engineering suite. Finally, a snapshot comparison tells you that something changed. It does not tell you whether the change is harmful, and the README does not claim otherwise.

LibChecker compared with Apktool and generic APK analyzers

Apktool is the comparison people reach for, and the difference is in what each one produces. Apktool decodes an APK into resources and smali, giving you files you can read and, in many cases, rebuild. LibChecker does not decode anything into an editable project. It reads the package and reports structured facts about it: matched libraries, ABI coverage, page-size readiness, ZIP alignment, signing schemes, permissions, and the diff between two points in time.

That makes the two complementary rather than competing. If your question is "what is inside this app and did it change", LibChecker answers on the phone in a form you can compare across versions. If your question is "how does this code work", you are going to need the decoded output, and LibChecker's library list is a reasonable map of where to start looking.

The same distinction applies to generic APK info viewers. Many of them show the manifest and the file listing. LibChecker's value is the rule set behind the names, plus the packaging checks on native libraries and the snapshot diff. If you only need the manifest, a simpler viewer is enough.

Maintenance, releases and what the licence allows

The repository is not archived, and the last push was on 2026-09-21, one day before this writing, so the project is under current development. Releases are less frequent than commits: 2.5.4 on 2026-06-17, 2.5.3 on 2025-11-23, and 2.5.2 on 2025-09-09. The gap between 2.5.3 and 2.5.4 is roughly seven months, which is worth knowing if you depend on a fix landing in a tagged build rather than on master.

Upgrade cost is low by design. The detection logic lives in LibChecker-Rules, a separate repository, so library coverage can move without an app update. What you install from F-Droid or Play is the client; the rules are the part that ages fastest, and the README points to both a GitHub and a GitLab mirror of them. If you build from source, you inherit the Gradle toolchain and the build-logic directory, and the README does not pin the required JDK or SDK versions.

The licence is Apache-2.0, which the README links to the standard choosealicense page for. That is a permissive licence, but this is not legal advice: if you plan to redistribute a modified build or bundle LibChecker into a product, read the LICENSE file in the repository and the attribution requirements it carries.

Editorial conclusion

LibChecker is worth installing if you need to see which SDKs, native ABIs or permissions an Android package carries, and you want that answer on the device without uploading the APK anywhere. Skip it if you need a general reverse-engineering workbench, a desktop tool, or anything for iOS: the README lists Android 7.0 to 17 only, and the marshmallow branch is the fallback for Android 6. Before you rely on a verdict, check that LibChecker-Rules covers the library you are looking for, since an unmatched library shows up only through its package name or native file, and confirm the current release on the F-Droid or Play listing rather than a mirror.

Frequently asked questions

Official sources

1. Issues
2. LibChecker/LibChecker on GitHub
3. License: Apache-2.0
4. README
5. Releases