ApkAnalyzer

Detailed reports of the applications on your device — 📱

Apk Analyzer is the most downloaded APK analysis app on Google Play, with over 2 million downloads. It inspects installed apps and .apk files straight from device storage — no root required. It’s open source, ad-free, and does its analysis on your device.

Shipping since 2017, now rebuilt as a multi-module Jetpack Compose app.

Table of contents

• What it does
• Why it exists
• Privacy and permissions
• Tech stack
• Architecture
• Getting started
• Repository layout
• CI and releases
• Documentation
• Contributing
• Support
• License

What it does

Inspect one app — everything Android knows about it, in one report.

Browse by attribute. Turn the question around and start from the attribute instead of the app: which apps request a given permission, which are signed by a given certificate, what targets each Android version, where each app came from, which share a UID, how apps spread across categories.

Analyze .apk files. Open an .apk from another app or pick one from storage and get the same full report for something you haven’t installed.

On-device AI summary. A short, factual, plain-language read on what an app is and what its permissions and components imply — generated locally with ML Kit’s GenAI prompt API. The app data never leaves the device.

Export and share. Export or share the APK itself, save the app icon, copy or share a text summary, and launch an app’s components directly.

Requirements: Android 9 (API 28) or newer. The AI summary additionally needs a device that supports on-device generative AI; everything else works everywhere.

Why it exists

Android tells you very little about the software you already run. Apk Analyzer surfaces the whole manifest-level truth about every installed app in a form a human can read — no root, no ads, no paywall on the raw data. Raw facts stay free by design; see the roadmap for where interpretation features are heading.

Privacy and permissions

App analysis runs entirely on device. The app declares exactly two sensitive permissions, both needed for the core feature:

App-analysis data is processed on device. Network use is limited to Firebase telemetry (Analytics, Crashlytics, Performance) and ML Kit downloading the on-device AI model. See PRIVACY_POLICY.MD.

Tech stack

Exact versions live in gradle/libs.versions.toml — that file is the single source of truth; nothing pins a version elsewhere.

Architecture

A multi-module Gradle project with one strict dependency direction: app → feature/*/impl → feature/*/api + core/*, and core/* never looks back at a feature.

graph TD
    app[":appActivities, nav host, Hilt graph"]
    fimpl["feature/<name>/implscreens + ViewModels"]
    fapi["feature/<name>/apiNavKeys only"]
    core["core/*domain, data, design system"]

    app --> fimpl
    app --> core
    fimpl --> fapi
    fimpl --> core
    core --> core

Rules:

• feature/*/api depends on nothing — it holds only @Serializable NavKeys and a tab label, so any feature can navigate to another without touching its implementation.
• feature/*/impl depends on its own api plus whichever core modules it needs. Never on another feature’s impl.
• core/* may depend on other core modules, never on a feature.
• app is wiring only: Activities, nav host, and app-scoped Hilt bindings. No feature logic.

How the code reads

The same shapes repeat everywhere, so an unfamiliar file is rarely a surprise:

• One ViewModel shape. A single StateFlow and a single onAction(Action) with a when dispatch. No other public methods. One-shot signals (navigation, toasts, intents) go out as Events over a Channel, never as state.
• One data-layer shape. A public interface plus an internal Impl, bound with Hilt and scoped @Singleton. Interface methods never throw — they return Result, a nullable, or an empty collection. Dispatchers are injected, never hardcoded.
• A design system, not scattered Material. Feature modules don’t import androidx.compose.material3 at all; they use the wrappers, theme and icons in core:ui-library.
• No comments. Naming and structure carry the intent — deliberately, and enforced in review.
• One source of versions. gradle/libs.versions.toml for dependencies, build-logic for SDK levels and the JVM toolchain. Nothing is pinned in a module.
• Documented decisions. Every module carries an AGENTS.md explaining its boundary and package map, and product decisions — including the ones deliberately retired — live in docs/.

Modules

Every module — including app — has its own AGENTS.md documenting its purpose, package map, and key types. Start there when working inside a module instead of re-deriving it.

Getting started

Prerequisites: Android Studio (latest stable). That’s genuinely it — the Gradle setup auto-provisions a matching JDK on first build, and Android Studio’s SDK Manager covers the Android SDK. The setup-local-tools skill has the full breakdown, including headless/CLI-only setup and optional tools.

git clone https://github.com/MartinStyk/AndroidApkAnalyzer.git
cd AndroidApkAnalyzer
./gradlew assembleDebug   # first build downloads Gradle, the JDK, and all dependencies

app/google-services.json is committed, so the Firebase Gradle plugins compile out of the box with nothing to configure. CI replaces it with a freshly fetched config at build time.

Common tasks:

./gradlew installDebug          # build + install debug on a connected device/emulator
./gradlew spotlessApply         # auto-fix formatting — run before every commit
./gradlew :feature:apps:impl:compileDebugKotlin   # fast single-module check while iterating
./gradlew spotlessCheck detektDebug lintDebug :app:assembleDebug   # what CI gates on
./gradlew validateAgentContext  # verify the shared Claude/Copilot context files

Version name and code come from Gradle properties (-Pversion.name=, -Pversion.code=) and default to a local dev build.

Repository layout

app/           Activities, nav host, app-scoped Hilt bindings — wiring only
core/          Domain, data, and design-system modules
feature/       One api + impl pair per feature area
build-logic/   Convention plugins; SDK levels and the JVM toolchain live here
config/        Detekt and static-analysis configuration
docs/          Product roadmap, feature design docs, technical decision records
.claude/       Task skills shared by Claude and Copilot
gradle/        Version catalog and wrapper

CI and releases

Every push and PR to develop runs spotlessCheck, Detekt, Android Lint (results uploaded as SARIF), and builds a debug APK that is attached to the run as an artifact. Pushes to develop also go out to internal testers via Firebase App Distribution.

Tagging MAJOR.MINOR.PATCH runs the release workflow: it verifies against the release variant, builds and signs an AAB and APK, derives versionCode from the tag, publishes a GitHub release with the tag annotation as notes, uploads the AAB to the Play Store beta track with its mapping file, and distributes the APK to internal testers.

Documentation

Contributing

Contributions are welcome. Start with CONTRIBUTING.md for the workflow, then AGENTS.md for module boundaries and conventions. By participating you agree to the Code of Conduct.

Good first contributions: a translation (the app currently ships English and Japanese, and a PR touching only strings.xml files needs no prior discussion), or anything marked open in the roadmap.

Support

• Bugs and feature requests — open an issue
• Security vulnerabilities — see SECURITY.md; please don’t file a public issue
• Using the app — the Play Store listing is the place for reviews and general feedback

License

Licensed under the GNU General Public License v3.0.