# stackzy decompiles an APK and names the libraries it contains

> stackzy is a Compose Desktop application in Kotlin that takes an Android package, decompiles it, and tells you which third party libraries are inside it, using a spreadsheet of known libraries as its database and a global cache to avoid decompiling the same app twice. Every published installer is still labelled experimental, and the macOS build is not notarised.

**theapache64/stackzy** — 💻 A cross-platform desktop application to identify libraries used inside an android application ⚡

- Repository: https://github.com/theapache64/stackzy
- Stars: 1,061 · Forks: 53
- Language: Kotlin
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/theapache64-stackzy

## Decompile, then match what you find

The description says it plainly: a cross platform desktop application to identify libraries used inside an Android application, and the README calls it a desktop app to analyse APK, built using Compose desktop.

The mechanism is two well known open source tools wrapped in a user interface. ApkTool does the APK decompiling, jadx turns the dex to Java, and the resulting classes and resources are then matched against a database of known libraries. That matching step is the actual product. Anyone who has decompiled an APK has seen a long list of packages and has to work out which of them are the application and which are third party code.

The stack table in the README makes the architecture explicit. The user interface is Compose Desktop, the architecture pattern is MVVM, the dependency injection is Dagger2, navigation is Decompose, the asynchronous work is Coroutines with Flow, the networking is Retrofit, the JSON is Moshi, the logging is Arbor, the ADB integration is Adam, and the testing uses DaggerMock with JUnit.

That is a modern Android shaped stack applied to a desktop tool, which is what Compose Desktop and Decompose make possible, and it explains the project topics, which include compose-desktop, coroutines-flow, dagger2 and mvvm. The project is MIT licensed, and there is a badge in the README that claims no AI was used.

## The library database is a Google Sheet

The Fun Facts section of the README contains the most important fact about how stackzy works, and it is this: stackzy uses a Google Sheet as the backend, thanks to Retrosheet.

Retrosheet is the author's own project, and it turns a spreadsheet into a small database that the app can query. The library data itself comes from the community. The credits section thanks mikepenz for contributing more than 200 libraries from his AboutLibraries project, which is a curated catalogue of open source Android libraries.

That design has a clear appeal. A spreadsheet is auditable, it is diffable, it can be edited through a browser, and a new library is a pull request rather than a database migration. It also has an obvious consequence for anyone depending on the result: the accuracy of the identification is bounded by the completeness of the sheet, and the sheet is maintained by volunteers.

The third fun fact explains the caching. Stackzy uses a global caching mechanism which works as a centralized caching system, which means that if someone has already decompiled WhatsApp, the next time you try to find the stack it will not be decompiled again and the result will be served from the cache.

So the decompilation, which is the slow part, happens once per application and everyone after that gets the answer immediately. The initial name of the project was Which Stack, which tells you what the tool was originally built to do.

## The cache is fast, and it is also a source of stale answers

The global cache deserves more attention than a fun fact, because it changes what the tool tells you.

A cache that avoids repeating a decompilation is a good design for a shared service, where the same popular applications get looked up over and over. In a single desktop install the effect is smaller, because each user is usually analysing a different application, and the benefit depends on how many users share a cache.

The failure mode is the same in both cases. A cached result reflects the application version that was decompiled at the time. If an application ships an update that changes its dependencies, and the cache is keyed on something coarser than the exact file, the tool will confidently report the previous library list. There is no mention in the README of cache invalidation, of a key that includes the version, or of a way to force a fresh decompilation, so a user who suspects a stale result has no documented way to check.

The identification step has the mirror image problem. A library is recognised by its package name or its class names, and the more obscure or obfuscated an application is, the less the matcher can say. ProGuard style shrinking and renaming will defeat any signature based matching, and the README does not describe what the tool does when it cannot identify a package, or how it reports a partially identified application.

Taken together, stackzy is a good tool for a triage question, and a poor tool for a due diligence question. If you need to know what is inside a specific build of an application, a decompiler and a dependency tree will tell you more, and you can read the result yourself.

## Three platforms, six downloads, all marked experimental

The install table is unusually honest about its own status. Every row carries the same status, Experimental, and there are six artefacts in total.

For Linux there is a DEB and a JAR. For Windows there is an MSI and a JAR. For macOS there is a DMG, a JAR for ARM64 and a JAR for x64.

The installation notes cover the details that catch people out. The JAR files require Java 15 or above to run. The macOS DMG is not notarised and may trigger a security warning, and the note explains how to get past it: right click the app and select Open, and if a security warning appears go to System Preferences, then Security and Privacy, and click Open Anyway next to the blocked app message.

That last sequence is the ordinary macOS gatekeeper path for an unsigned application, and it means every Mac user has to perform it. For a tool that a team might want to roll out to a group of engineers, that is a distribution problem before it is a tooling problem.

There is also an alternative build, for people who would rather not take the release artefacts. You clone the repo and execute ./gradlew createDistributable.

```bash
./gradlew createDistributable
```

The README's dependency section says Java 8 or above, which does not match the Java 15 requirement stated for the JAR files. That inconsistency is small, but it is the kind of detail worth checking against your own environment, since one of the two numbers is wrong.

The release history shows the project moving quickly at the end of 2025 and then going quiet for a while: 1.2.13 and 1.2.12 were both published on 2026-01-14, and 1.2.11 came on 2025-08-04. The last push was on 2026-09-05.

## The alternative is jadx and a dependency tree

The realistic alternative to stackzy is not another identification tool, it is doing the decompilation yourself with the tools stackzy already wraps.

ApkTool and jadx are both open source and both usable on their own. Running jadx on an APK gives you the classes, and the class path list is where the libraries are visible, because a third party library has a recognisable package name while application code usually does not. The difference in approach is that stackzy adds the database and the presentation layer, and you lose the ability to read the decompiled source, which is often where the actual answer lives.

There is a second path, through the data rather than the tool. AboutLibraries is the catalogue the 200 or more contributed library entries come from, and it is maintained independently of stackzy by the person the credits thank. If you want the list of known libraries, that catalogue is the source of truth, and a tool that adds a spreadsheet backend and a cache on top of it adds convenience rather than new information.

The trade is worth naming precisely. stackzy saves you the manual work of reading a dependency list, and it does that well for popular applications where the cache is warm and the libraries are well known. It does not give you anything the decompiler and the catalogue would not, and it does not give you the decompiled source.

For an occasional question about one application, running the decompiler is the more reliable answer. For a workflow that repeatedly asks the same question, a tool with a cache and a known library database earns its place.

## Conclusion

stackzy fits a developer doing dependency triage on Android apps, who wants the library list in one click rather than reading a decompiled dependency tree, and who is comfortable with a tool whose database is a community maintained spreadsheet. It is the wrong choice if you need a signed, notarised installer for a managed fleet, because every platform build is marked experimental and the macOS disk image is not notarised. Verify first that the app you are analysing is in the Retrosheet data, and that a cache hit is not returning a stale library list for a version that has since changed its dependencies.

## FAQ

### What does stackzy do with an APK?

It decompiles the APK with ApkTool, converts the dex to Java with jadx, and matches what it finds against a database of known libraries to tell you which third party libraries the application contains.

### Where does stackzy get its library database?

It uses a Google Sheet as the backend through the author's Retrosheet project, and the library entries were contributed largely by mikepenz from the AboutLibraries project, to whom the README gives credit for more than 200 libraries.

### Which platforms can I install stackzy on?

Linux as a DEB or a JAR, Windows as an MSI or a JAR, and macOS as a DMG or as a JAR for ARM64 and for x64. The JAR files require Java 15 or above, and the README notes that the macOS DMG is not notarised and may trigger a security warning that you have to allow through System Preferences, Security and Privacy.

### What is stackzy built with?

Compose Desktop for the user interface, MVVM for the architecture, Dagger2 for dependency injection, Decompose for navigation, Coroutines and Flow for asynchronous work, Retrofit for networking, Moshi for JSON, Arbor for logging and Adam for ADB, with DaggerMock and JUnit for testing. It is Apache 2.0 licensed.

### How does the stackzy cache work?

It uses a global caching mechanism acting as a centralized caching system, so if an application has already been decompiled by someone, the next lookup is served from the cache instead of decompiling it again. The initial name of the project was Which Stack.

## Sources

- [Issues](https://github.com/theapache64/stackzy/issues)
- [License: Apache-2.0](https://github.com/theapache64/stackzy/blob/master/LICENSE)
- [README](https://github.com/theapache64/stackzy/blob/master/README.md)
- [Releases](https://github.com/theapache64/stackzy/releases)
- [theapache64/stackzy on GitHub](https://github.com/theapache64/stackzy)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/theapache64-stackzy