GO — Healthy across the board

• Last commit 3d ago
• 10 active contributors
• Distributed ownership (top contributor 33% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Scorecard: default branch unprotected (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

Apktool is a reverse-engineering tool that decodes binary Android APK files into near-original source form (XML resources, Smali bytecode, assets) and rebuilds them after modifications. It extracts and decompiles DEX bytecode to Smali intermediate language, parses binary XML resources, and repackages everything into a valid APK. Core capability: edit Android apps at the resource and bytecode level without needing original source code. Two-module Gradle monorepo: brut.apktool/apktool-lib/ contains core logic (ApkDecoder, ApkBuilder, resource parsing) as a reusable library; brut.apktool/apktool-cli/ wraps it into a CLI entry point (Main.java). Metadata lives in brut.apktool/apktool-lib/src/main/java/brut/androlib/meta/ (ApkInfo, SdkInfo, ResourcesInfo). Exception hierarchy under brut.apktool/apktool-lib/src/main/java/brut/androlib/exceptions/ handles domain-specific errors.

Android security researchers, app modders, localization engineers, and platform developers who need to analyze, debug, or modify third-party closed-source APKs. Also used by developers adding custom platform support or testing app behavior across Android versions.

Production-ready and actively maintained. Main branch (3.x) is the current development line with Gradle-based build system, while 2.x branch receives maintenance fixes. Project has CI/CD (GitHub Actions workflows in .github/workflows/), Apache 2.0 licensing, and an established community (IRC on libera.chat). Last activity is recent; project shows consistent updates and issue management.

Low risk overall, but single-maintainer dependent (Connor Tumbleson is primary contact per SECURITY.md). Java dependencies are managed via Gradle but not explicitly listed in provided data—verify upstream framework versions for security patches. APK format changes across Android versions can require frequent updates; binary format compatibility is a moving target. No major breaking changes visible, but API surface is broad (APK building, decoding, resource parsing).

Currently on v3.x branch (see .github/workflows/build.yml and .github/workflows/gradle.yml for active CI). The ROADMAP.md and INTERNAL.md docs hint at ongoing feature work. No specific PR/issue details in provided data, but build and analyze workflows suggest active development with GitHub Actions integration. Repository has dependabot configuration (.github/dependabot.yml) indicating proactive dependency management.

git clone https://github.com/iBotPeaches/Apktool.git
cd Apktool
./gradlew build

For CLI usage post-build, see CONTRIBUTING.md and the official docs. Gradle Wrapper handles setup; no Maven or npm required.

Daily commands:

./gradlew build
./gradlew installDist  # Installs CLI to brut.apktool/apktool-cli/build/install/
# Then use CLI: apktool d app.apk  (decode) or apktool b app/ (rebuild)

See .github/workflows/gradle.yml for official test/build command structure.

• brut.apktool/apktool-cli/src/main/java/brut/apktool/Main.java — CLI entry point—defines command parsing and orchestrates decode/build workflows that every contributor must understand.
• brut.apktool/apktool-lib/src/main/java/brut/androlib/ApkDecoder.java — Core APK decoding orchestrator—handles resource extraction, manifest parsing, and smali decompilation; central to reverse engineering.
• brut.apktool/apktool-lib/src/main/java/brut/androlib/ApkBuilder.java — Core APK rebuilding logic—recompiles resources, smali, and packages them back; mirror of ApkDecoder for the build phase.
• brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/BinaryResourceParser.java — Parses binary resource tables from APK—decodes compiled resource formats; critical for resource extraction fidelity.
• brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/BinaryXmlResourceParser.java — Converts binary XML (manifest, layouts) to plain text—handles Android's compressed XML format at the byte level.
• brut.apktool/apktool-lib/src/main/java/brut/androlib/Config.java — Configuration singleton managing frameworks, output dirs, and decoding options—every tool operation reads from here.
• brut.apktool/apktool-lib/src/main/java/brut/androlib/smali/SmaliDecoder.java — DEX to Smali disassembly—converts compiled bytecode to human-readable assembly; foundation for code inspection.

Add support for a new resource type

1. Define a new ResValue subclass (e.g., ResCustom.java) in brut.apktool/apktool-lib/src/main/java/brut/androlib/res/table/value/ (brut.apktool/apktool-lib/src/main/java/brut/androlib/res/table/value/ResCustom.java)
2. Register the type ID in BinaryResourceParser.java when reading resource values from the binary table (brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/BinaryResourceParser.java)
3. Implement XML serialization by overriding toResources() in your ResValue subclass or adding a case in ResXmlSerializer.java (brut.apktool/apktool-lib/src/main/java/brut/androlib/res/xml/ResXmlSerializer.java)
4. Test by decoding an APK containing the resource and verifying XML output in the values/ directory

Add a new CLI command

1. Create a new command class extending a base CLI handler in brut.apktool/apktool-cli/src/main/java/brut/apktool/ (brut.apktool/apktool-cli/src/main/java/brut/apktool/Main.java)
2. Register the command in Main.java by adding a case in the argument parser (brut.apktool/apktool-cli/src/main/java/brut/apktool/Main.java)
3. Implement the command logic by calling ApkDecoder, ApkBuilder, or other library classes from brut.apktool/apktool-lib/ (brut.apktool/apktool-lib/src/main/java/brut/androlib/ApkDecoder.java)

Improve binary resource parsing for a new Android API level

1. Identify new resource flags or configuration qualifiers in BinaryResourceParser.java (brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/BinaryResourceParser.java)
2. Update ResConfig.java to handle new configuration bits (e.g., new density buckets or locale variants) (brut.apktool/apktool-lib/src/main/java/brut/androlib/res/table/ResConfig.java)
3. Test with APKs targeting the new API level; verify resource extraction produces correct directory structure (e.g., values-xxxhdpi)

Extend APK rebuilding with custom processing

1. Create a new processing class in brut.apktool/apktool-lib/src/main/java/brut/androlib/ that hooks into the build phase (brut.apktool/apktool-lib/src/main/java/brut/androlib/ApkBuilder.java)
2. Call your processor from ApkBuilder.java before or after resource compilation and DEX assembly (brut.apktool/apktool-lib/src/main/java/brut/androlib/ApkBuilder.java)
3. Test by building a modified APK and verifying the output respects your custom processing (e.g., additional signing, obfuscation)

Framework dependencies: Apktool requires Android framework files (android.jar, aapt) to be present; missing framework throws FrameworkNotFoundException. See CONTRIBUTING.md for setup. Binary format brittleness: APK/DEX/AXML formats change per Android release; decoding against unknown format versions can silently corrupt resources. Classpath issues: Smali bytecode assumes specific Android class hierarchy; modifying core classes can break rebuild. ProGuard obfuscation: apktool-cli uses ProGuard (see proguard-rules.pro); rebuilds may differ from source. Shell script dependencies: BATCHFILE and Shell files in repo suggest Windows/Unix compatibility quirks—test on both.

• DEX (Dalvik Executable) Format — Apktool's core function is converting DEX bytecode to Smali and back; understanding DEX structure (method indices, encoded arrays, type IDs) is critical for modifying app logic
• Android Binary XML (AXML) Format — APK resources are stored as compiled binary XML, not text; Apktool must parse/regenerate this format to let users edit AndroidManifest.xml and layout files as text
• Smali Intermediate Language — Apktool decodes DEX to Smali syntax (human-readable bytecode assembly); contributors must understand Smali mnemonics and instruction encoding to debug or extend bytecode manipulation
• Resource ID Remapping — When rebuilding APKs, resource IDs may shift due to new strings/drawables; Apktool must maintain stable ID references across decode/modify/rebuild cycles to avoid crashes
• APK Signing and Certificate Handling — Rebuilt APKs must be signed with a valid certificate to install; Apktool wraps signing logic but developers must understand certificate pinning and signing-related rebuild failures
• Android Framework Resources — Apktool decodes resource IDs by referencing Android framework files (android.jar); missing or mismatched framework versions cause resource decompilation failures; understanding framework installation is essential for troubleshooting
• ProGuard Obfuscation — Apktool CLI is obfuscated with ProGuard to reduce binary size; maintainers must manage ProGuard rules carefully to preserve public APIs while optimizing; broken rules break the CLI

• JesusFreke/smali — Standalone Smali assembler/disassembler library that Apktool depends on for DEX bytecode round-tripping; understanding Smali format is essential for bytecode-level modifications
• google/android-go — Go implementation of Android binary parsing (AXML, resources); useful for understanding resource decompilation techniques or building cross-platform tooling
• iBotPeaches/apktool.org — Official documentation and blog for Apktool; companion repo for users learning how to use and contribute to Apktool
• skylot/jadx — Alternative DEX decompiler targeting Java source output; useful for comparing decompilation strategies or hybrid reverse-engineering workflows with Apktool
• java-decompiler/jd-gui — GUI bytecode decompiler; often used alongside Apktool for visual class inspection after APK decoding

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for ResDecoder and BinaryResourceParser

The resource decoding pipeline (brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/) is critical to Apktool's core functionality but likely lacks dedicated unit tests. BinaryResourceParser.java and ResDecoder.java handle binary XML and resource parsing—fundamental operations that would benefit from regression tests for edge cases (malformed chunks, unusual encoding, Android version compatibility). This prevents silent breaking changes.

• [ ] Create brut.apktool/apktool-lib/src/test/java/brut/androlib/res/decoder/ directory
• [ ] Add BinaryResourceParserTest.java with tests for various ResChunkHeader types and malformed binary data
• [ ] Add ResDecoderTest.java with tests for resource file parsing across Android API levels
• [ ] Create test fixtures in brut.apktool/apktool-lib/src/test/resources/ with sample binary resource files
• [ ] Integrate tests into build.gradle.kts test suite

Add integration tests for APK decode/build round-trip with assertions

The ApkDecoder.java and ApkBuilder.java classes represent the public API surface, but there's no clear evidence of integration tests verifying that decode → modify → build → decode produces consistent results. This is critical for catching regressions in manifest handling, resource encoding, and dex preservation. Add tests that decode sample APKs, validate output structure, rebuild, and compare checksums.

• [ ] Create brut.apktool/apktool-lib/src/test/java/brut/androlib/ directory for integration tests
• [ ] Add ApkRoundTripTest.java that decodes a sample APK and validates AndroidManifest.xml, resources.arsc structure
• [ ] Add test APK fixtures in brut.apktool/apktool-lib/src/test/resources/apks/ for multiple Android versions (API 21, 28, 31+)
• [ ] Implement assertions for: manifest XML structure, resource ID consistency, DEX file integrity
• [ ] Document expected vs actual behavior in INTERNAL.md for future contributors

Add GitHub Actions workflow for testing across multiple Java versions and Android API targets

The .github/workflows/build.yml and gradle.yml exist, but there's no visible matrix testing across Java 11, 17, 21 or targeting different Android API levels. Apktool must work across Android versions, so a dedicated workflow that tests APK samples from API 16–34 would catch version-specific regressions early. This is especially valuable given the complexity of resource parsing changes across Android releases.

• [ ] Create .github/workflows/compatibility-matrix.yml workflow file
• [ ] Configure job matrix for Java versions: 11, 17, 21
• [ ] Add test matrix for Android API levels: 21, 26, 28, 31, 33, 34
• [ ] Use brut.apktool/apktool-lib/build.gradle.kts to parameterize AAPT/framework dependencies per API level
• [ ] Ensure test APK fixtures in src/test/resources/ are tested against each configuration
• [ ] Document expected behavior in CONTRIBUTING.md for running compatibility checks locally

• Add unit test coverage for brut.apktool/apktool-lib/src/main/java/brut/androlib/exceptions/ package (NinePatchNotFoundException, RawXmlEncounteredException, etc. lack test assertions); mock failing APK scenarios and verify exception messages.
• Expand ApkInfo.java serialization: add automated tests for round-trip (decode APK → write apktool.yml → read back) to catch YAML schema drift; currently no visible test in the file structure.
• Document Config.java defaults in CONTRIBUTING.md with concrete examples (framework path resolution, resource ID range limits); junior developers struggle to understand when Config properties are required vs. optional.

Apktool's security posture is generally reasonable for a reverse engineering tool, with proper licensing and vulnerability disclosure policies in place. However, several medium-severity concerns exist around XML processing safety, binary deserialization robustness, and path traversal prevention when handling untrusted APK files. The tool processes arbitrary binary formats from potentially malicious sources, requiring strong input validation throughout. No hardcoded credentials or obvious injection vulnerabilities were detected in the visible file structure. Recommendations focus on strengthening input

• Medium · Potential Unsafe XML Processing — brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/. The codebase contains multiple XML processing components (BinaryXmlResourceParser, ResXmlPullStreamDecoder, ManifestPullEventHandler) that parse untrusted APK content. XML External Entity (XXE) injection vulnerabilities could occur if XML parsers are not properly configured to disable external entity resolution. Fix: Ensure all XML parsers disable XXE processing by setting appropriate features: XMLConstants.ACCESS_EXTERNAL_DTD and XMLConstants.ACCESS_EXTERNAL_SCHEMA to empty strings. Use SAXParserFactory.setFeature() to disable DOCTYPE declarations.
• Medium · Deserialization of Untrusted Data — brut.apktool/apktool-lib/src/main/java/brut/androlib/res/data/. APK files are deserialized and parsed extensively (ResStringPool, ResChunkHeader, various resource table parsing). Malformed or malicious APK files could potentially trigger unsafe deserialization or cause denial-of-service attacks through resource exhaustion. Fix: Implement strict validation of binary formats, add size limits for parsed resources, validate chunk headers before processing, and implement timeout mechanisms for parsing operations. Consider using fuzzing tests.
• Medium · Potential Path Traversal in File Operations — brut.apktool/apktool-lib/src/main/java/brut/androlib/ApkDecoder.java, brut.apktool/apktool-lib/src/main/java/brut/androlib/ApkBuilder.java. The ApkDecoder and ApkBuilder classes perform file system operations on APK contents. If resource paths or file names from the APK are not properly sanitized, attackers could use path traversal sequences (../) to write files outside the intended directory. Fix: Implement strict path validation using canonical path resolution. Verify all extracted paths are within the target output directory. Use Files.createDirectories() with proper security checks and reject any paths containing '..', absolute paths, or symlinks.
• Low · Missing Dependency Version Pinning — brut.apktool/apktool-cli/build.gradle.kts, brut.apktool/apktool-lib/build.gradle.kts. The build.gradle.kts files are not provided in the analysis, but typical APK analysis tools depend on external libraries like AAPT. Without explicit version pinning and vulnerability scanning, transitive dependencies could introduce security issues. Fix: Implement dependency version pinning, use Gradle's dependency locking feature, and integrate OWASP Dependency-Check or similar tools into the CI/CD pipeline. Regularly update dependencies and monitor for CVEs.
• Low · ProGuard Configuration Exposure — brut.apktool/apktool-cli/proguard-rules.pro. The proguard-rules.pro file is present and could be analyzed by attackers to understand code obfuscation patterns and identify sensitive code paths or class names that should have been obfuscated. Fix: Ensure ProGuard rules do not reveal sensitive package structures. Avoid keeping package names that indicate security-critical components. Review and minimize the -keep directives to only what is necessary for functionality.
• Low · Lack of Input Validation Documentation — brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/. The codebase handles untrusted binary formats (APK files) extensively, but there is no evident comprehensive input validation framework across the resource parsing modules. Fix: Implement a centralized input validation layer for all binary parsing. Document accepted formats, sizes, and constraints. Add detailed error handling and logging for malformed inputs. Create integration tests with malicious/malformed APK files.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/iBotPeaches/Apktool shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live iBotPeaches/Apktool repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/iBotPeaches/Apktool.

What it runs against: a local clone of iBotPeaches/Apktool — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in iBotPeaches/Apktool | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 33 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of iBotPeaches/Apktool. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/iBotPeaches/Apktool.git
#   cd Apktool
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of iBotPeaches/Apktool and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "iBotPeaches/Apktool(\\.git)?\\b" \\
  && ok "origin remote is iBotPeaches/Apktool" \\
  || miss "origin remote is not iBotPeaches/Apktool (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "brut.apktool/apktool-cli/src/main/java/brut/apktool/Main.java" \\
  && ok "brut.apktool/apktool-cli/src/main/java/brut/apktool/Main.java" \\
  || miss "missing critical file: brut.apktool/apktool-cli/src/main/java/brut/apktool/Main.java"
test -f "brut.apktool/apktool-lib/src/main/java/brut/androlib/ApkDecoder.java" \\
  && ok "brut.apktool/apktool-lib/src/main/java/brut/androlib/ApkDecoder.java" \\
  || miss "missing critical file: brut.apktool/apktool-lib/src/main/java/brut/androlib/ApkDecoder.java"
test -f "brut.apktool/apktool-lib/src/main/java/brut/androlib/ApkBuilder.java" \\
  && ok "brut.apktool/apktool-lib/src/main/java/brut/androlib/ApkBuilder.java" \\
  || miss "missing critical file: brut.apktool/apktool-lib/src/main/java/brut/androlib/ApkBuilder.java"
test -f "brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/BinaryResourceParser.java" \\
  && ok "brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/BinaryResourceParser.java" \\
  || miss "missing critical file: brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/BinaryResourceParser.java"
test -f "brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/BinaryXmlResourceParser.java" \\
  && ok "brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/BinaryXmlResourceParser.java" \\
  || miss "missing critical file: brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/BinaryXmlResourceParser.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 33 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~3d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/iBotPeaches/Apktool"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.