ALEAPP: A plugin-driven parser for Android extractions that leans on community artifacts

What ALEAPP actually parses and who needs it

ALEAPP targets Android forensic extractions. The README names four input types: zip, tar, fs, and gz. That covers a typical range of extraction formats, from full filesystem images to compressed archives. The tool is aimed at forensic examiners who need to pull structured data out of an Android device image quickly. It is not a general log parser. It is also not a mobile device management tool. It sits in a specific niche: turning raw Android files into reports that an examiner can read and search. The project name spells out the scope: Android Logs Events And Protobuf Parser. That means it handles log files, event logs, and protobuf-based data, but the actual artifact coverage comes from plugins, not from a hardcoded list. The README does not enumerate which artifacts are supported out of the box. That is a gap. You cannot tell from the repository description whether your target app or system component is covered until you run it or inspect the scripts/artifacts folder.

The plugin architecture is the core mechanism

The heart of ALEAPP is its plugin system. Each artifact is processed by a Python source file placed in scripts/artifacts. The README states that these plugins are loaded dynamically each time ALEAPP runs. That means adding a new artifact does not require recompiling the tool or editing core code. Each plugin must define a dictionary named __artifacts_v2__ at the very top of the module. The dictionary maps artifact IDs to metadata: name, description, author, version, date, requirements, category, notes, paths, and function. The paths key holds glob patterns that match files in the extraction. For example, a plugin for a database would use a pattern like '*/com.android.cooldata/databases/database*.db'. The function key names the entry point that processes the matched files. That function receives four arguments: an iterable of file paths, the output folder path, a seeker object of type FileSeekerBase, and a Boolean for text wrapping. This design is clean and testable. The dynamic loading means you can drop a new plugin in and run ALEAPP immediately. But it also means the quality of the output depends entirely on the plugin author. A poorly written plugin can crash the whole run or produce empty reports.

Getting it running: commands and dependencies

To run ALEAPP from source, you need Python 3.10 or above. The README lists dependencies in requirements.txt and gives two install commands: py -m pip install -r requirements.txt or pip3 install -r requirements.txt. On Linux, you must also install tkinter separately with sudo apt-get install python3-tk. That is a concrete requirement that many Python tools skip. The CLI usage is straightforward: python aleapp.py -t <zip | tar | fs | gz> -i <path_to_extraction> -o <path_for_report_output>. There is also a GUI launcher, python aleappGUI.py, and a help flag, --help. If you want a standalone executable, the README provides PyInstaller spec files for Windows, macOS, and Linux. For Windows, you run pyinstaller scripts\pyinstaller\aleapp.spec to get aleapp.exe, and a separate spec for the GUI. For macOS and Linux, the spec files are named aleapp_macOS.spec and aleapp_Linux.spec. The project does not publish prebuilt binaries in the README, so you must build them yourself if you need them. That is a barrier for non-developer examiners, but it is manageable for a Python-savvy user.

The testing workflow is unusually rigorous for a forensic tool

The README devotes a long section to how contributors should create test data and sample_data for pull requests. This is not typical for a small open-source project. The workflow uses several scripts under admin/test. First, python admin/test/scripts/make_test_data.py <module> --case 1 --input <extraction.zip> cuts a fixture from a real extraction. The fixture is a small zip under admin/test/cases/data/<module>/ plus a case file. Size rules are explicit: under 10 MB per zip, commit it; between 10 and 25 MB, commit the case file and attach the zip to a PR comment; larger than that, coordinate with a maintainer. Second, TZ=UTC python admin/test/scripts/test_module.py <module> -a all -c all runs the module against the fixture and writes a snapshot under admin/test/results/<module>/. That snapshot becomes the baseline for CI. Third, python admin/test/scripts/run_test_cases.py --module <module> runs the same comparison CI will run. Fourth, python admin/scripts/validate_sample_data.py --emit <extraction.zip> --key <image_name> generates sample_data blocks that you paste into the plugin. The README stresses that the TZ=UTC prefix is required because committed snapshots are UTC and CI runs UTC. This is a strong point. It means that if you contribute a plugin, you can verify it will not break future runs. The downside is that this workflow is heavy for a casual contributor. You need a real extraction, which itself raises privacy and legal concerns. The README warns: whatever you commit becomes public, so only use data you are allowed to share.

A real limitation: output format and plugin fragility

The README says plugins are expected to provide output in ALEAPP's HTML output format, TSV, and optionally submit records to the timeline. That means the primary output is a web page and tab-separated files. If you need JSON or a database directly, you will have to write your own plugin or post-process. There is no mention of a built-in export to CSV or SQLite. Another limitation is that plugin functions must follow a strict signature. If a plugin does not match, ALEAPP will not load it. The README gives an example signature: def get_cool_data1(files_found, report_folder, seeker, wrap_text). That is a fixed contract. A plugin that returns nothing or crashes will produce an empty report for that artifact. The project has no plugin sandboxing. A malicious or buggy plugin can read any file in the extraction, because the seeker matches glob patterns and passes paths to the function. For a forensic tool, that is acceptable because the examiner controls the input, but it means you should only run plugins from trusted sources. The README does not mention any isolation or permission model.

The wrong tool for some cases

ALEAPP is the wrong tool if you need to parse a single log file without a full extraction. The CLI requires an input path that is a zip, tar, fs, or gz. There is no mode to point it at one file and get a report. You would have to wrap that file in a zip or tar first. It is also not the right tool if you need a polished commercial forensic suite with a point-and-click interface and vendor support. ALEAPP is a developer-oriented tool. The GUI exists, but it is not described in detail, and the README focuses on CLI and plugin development. If you are a forensic examiner who cannot write Python, you will depend on the community to maintain plugins. That is a real risk. The project is MIT licensed, which is permissive, but the artifact plugins themselves are also MIT unless a contributor states otherwise. The README does not specify a code of conduct or contribution guidelines beyond the test workflow. That is a gap for a project that relies on external contributions.

Alternatives and how they differ

The most direct alternative is iLEAPP, the iOS counterpart to ALEAPP. The same author, abrignoni, maintains it, and the README references ilapfuncs as a module used by ALEAPP plugins. iLEAPP follows the same plugin architecture but targets iOS extractions. The difference in approach is the input format: iLEAPP handles iOS backups and filesystem images, while ALEAPP handles Android. If you work on both platforms, you would use both tools, but they are separate codebases. Another alternative is the open-source tool APOLLO, which also parses Android artifacts, but APOLLO uses a different plugin framework and focuses on a pre-built set of artifacts. The README does not mention APOLLO, so I cannot compare specifics beyond what is publicly known. The key difference is that ALEAPP's plugin system is explicit and documented, while APOLLO's is more monolithic. If you want to add a custom artifact, ALEAPP gives you a clear path: write a plugin, test it with the provided scripts, and submit a PR. That is a concrete advantage for teams that need custom coverage.

Maintenance and upgrade cost

The project is actively maintained. The last push was 2026-08-27, and there are recent releases: v2026.3.2, v2026.3.1, and v2026.3.0. The version scheme suggests a yearly release cycle with patch updates. That means you can expect bug fixes and new plugins regularly, but you also need to track changes. The README does not describe a migration path for plugins between versions. If the __artifacts_v2__ schema changes, existing plugins may break. The test workflow with snapshots is designed to catch regressions, but only if contributors run it. The cost of upgrading is low if you run from source: you pull the latest code and reinstall dependencies. But if you build executables with PyInstaller, you must rebuild them for each release. The README does not provide a one-command updater. You also need to maintain your own plugins if you rely on custom artifacts. For a forensic lab, that means version-controlling your scripts/artifacts folder and testing against new releases. The MIT license allows you to fork and modify, but you are responsible for maintaining your fork.

Editorial conclusion

ALEAPP is for digital forensics examiners and incident responders who work with Android extractions and want a parser that is easy to extend with Python plugins. It is not for analysts who need a one-shot commercial tool with guaranteed artifact coverage or who cannot write Python. Before adopting it, verify that your Python environment is 3.10 or above, that you can run the CLI with your extraction type, and that the plugin you need exists or that you are willing to write it. The project is MIT licensed, so you can modify it freely, but you must check the license implications of the artifact data you commit to a PR, as the README warns that anything you commit becomes public.

Official sources

1. Official README
2. Project repository
3. Release notes