APK Info Viewer

Local Static Analysis of Android Packages

The APK Info Viewer is a static analysis utility designed to inspect the contents and metadata of an Android application package (APK) file before installation. Operating entirely within the user's web browser, the tool extracts and displays key technical details of the package without executing or installing the application. This allows security-conscious users, Android developers, and IT auditors to verify the facts of an APK file and compare them against official developer releases.

By performing static analysis, the tool reads the structural declarations of the file. This method exposes the application's package name, version, required Android versions, requested permissions, background and screen components, supported processor types, signing certificates, and file hashes.

Browser-Based Local Processing and Privacy

The tool processes files locally using the resources of the host device. All file reading, hashing, and parsing occur entirely within a local Worker in the user's web browser. No files or data are uploaded to an external server, and the APK is never installed or executed on the user's device.

This local processing model imposes specific input limits and rules to ensure browser stability:

• Single APK file: The tool accepts only one file at a time. If a user attempts to upload multiple files at once, the tool processes only the first file and displays the note: "One file at a time — inspecting the first one.".
• Accepted format: The file must be a standard .apk file.
• Size limit: The tool supports files up to 500 MB. Files exceeding 500 MB are rejected with the error message: "This file is over 500 MB — larger than a browser tab can safely inspect.".

During operation, the interface displays real-time status and progress indicators to reflect the state of the local worker:

• Ready. Drop an APK to inspect it.
• Reading ‹name›…
• Computing file hashes — ‹percent›%
• Parsing the package…
• Report ready.
• Cleared.
• Report downloaded.

If a file cannot be processed, specific error messages are triggered based on the failure state:

• Unsupported Formats: Split packages (XAPK, APKM) are rejected with: "This is an XAPK split package — a container of several APKs. Extract the base APK and inspect that file instead.". Android App Bundles are rejected with: "This is an Android App Bundle (.aab) — a publishing format, not an installable APK. Inspect the built APK instead.". Non-APK files trigger: "This doesn’t look like an APK: no readable AndroidManifest.xml found inside.".
• Damaged Files: Damaged or truncated packages trigger: "The package looks damaged or truncated, so its contents couldn’t be read.".
• Read Failures: General file reading issues trigger: "The file couldn’t be read. Pick it again.".
• General Failures: Any other inspection failure triggers: "Inspection failed. Try another file.".

Android SDK Versioning and Requirements

The Requirements section of the report displays the SDK versioning constraints declared in the APK's manifest. These values dictate application compatibility and security behaviors across different Android OS versions.

Understanding Android Permissions

The Permissions section lists every permission requested by the application package. Android categorizes permissions based on the level of risk they pose to user privacy and system integrity.

Permissions classified by the Android operating system as having access to private data (such as location, contacts, camera, microphone, or storage) are marked with a Dangerous badge. To help users evaluate these requests, the tool automatically sorts the permission list, prioritizing those carrying the Dangerous badge at the top of the interface. This allows users to quickly determine if the requested access aligns with the stated utility of the application.

Anatomy of an APK: Components and Resources

An APK is an archive containing the compiled code, resources, assets, and manifest of an Android application. The tool parses these internal structures and organizes them into dedicated sections:

Components (Components)

The tool extracts declared application components from the AndroidManifest.xml. These are grouped into four categories, with a limit of 100 displayed entries per category. If the count exceeds 100, the tool appends a +‹count› more label.

• Activities: The entry points for user interaction. Components accessible to other applications display an exported label.
• Services: Background processing components. These display an exported label where applicable.
• Receivers: Broadcast receivers that listen for system-wide or application-specific events. These display an exported label where applicable.
• Providers: Content providers that manage access to structured data. These display an exported label, the provider authority, or None where applicable.

Native Code (Native Code)

This section displays the supported processor types (Application Binary Interfaces, or ABIs) and the count of native libraries included in the package.

Resources (Resources)

This section quantifies the structural files packaged within the archive:

• Screen densities
• Resource files
• Asset files
• Code files (.dex)
• Files in package

Android Code Signing and File Hashes

Every Android application must be signed with a certificate before it can be installed on a device. The operating system uses this signature to establish publisher identity and ensure the application has not been modified.

Signatures Section (Signatures)

The tool extracts X.509 certificates from v1 PKCS#7 blocks and APK Signing Blocks (v2, v3, and v3.1) to display their metadata. For each signer found, the tool displays:

• Signer ‹n›
• Subject
• Issued by
• Serial number
• Valid from
• Valid until
• Signature algorithm
• Key algorithm
• MD5, SHA-1, and SHA-256 fingerprints.

If no signature block is found, the tool displays: "No recognized signature block found — the package may be unsigned or repacked.".

Note: The tool extracts this metadata for inspection; it does not cryptographically verify the integrity of the signatures, validate the certificate trust chain, or verify the real-world identity of the publisher.

File Hashes Section (File hashes)

To assist with verification and auditing, the tool computes cryptographic hashes of the entire APK file. It displays the MD5, SHA-1, and SHA-256 hashes of the package. These hashes can be compared against official developer releases or security databases to verify file integrity.

Users can save these details by clicking the Download report button, or clear the interface using the Clear button.

Frequently Asked Questions

What can I learn from an APK without installing it?

Quite a lot: the app’s package name and version, the Android versions it needs, every permission it requests, the screens and background components it declares, the processor types it ships native code for, and the certificates it was signed with.

Can this tool tell me whether an APK is malware?

No — and be skeptical of any tool that promises a verdict from a quick scan. What you get here are the facts: permissions, components, signers, and hashes. Compare them against what the developer publishes, and treat unexpected permissions or a different signer than the official release as reasons to walk away.

Which files are supported?

Single APK files up to 500 MB. Split packages (XAPK, APKM) and Android App Bundles (.aab) are containers or publishing formats rather than one installable package, so they’re declined with a clear message instead of a confusing report.

What do the signing details tell me?

Every Android app is signed, and the certificate identifies who published it. You see which signature schemes the package carries (v1, v2, v3) and each signer’s subject, validity window, and MD5, SHA-1, and SHA-256 fingerprints. Two APKs with matching fingerprints came from the same publisher — whether you trust that publisher is still yours to judge.

What does the “Dangerous” badge on a permission mean?

It’s Android’s own classification: dangerous permissions can reach private data — location, contacts, camera, microphone, storage — so the system asks the user before granting them. The badge isn’t an accusation; a maps app asking for location is normal. It just marks the permissions worth reading twice.