# Tool-Tree repacks Android ROM partitions, and every link in its own page points at a different owner

> An Android ROM and APK toolkit that unpacks and repacks boot, dtbo, super, payload and the common filesystems, with a no-root path documented. The catch is on the page itself: the release, docs, issue and translation links all address Kakathic/Tool-Tree rather than the repository they sit in.

**Zenlua/Tool-Tree** — Unpack and repack ROMs and APKs for Android, Supports both root and non-root devices.

- Repository: https://github.com/Zenlua/Tool-Tree
- Website: https://zenlua.github.io/Tool-Tree
- Stars: 190 · Forks: 55
- Language: Kotlin
- License: Apache-2.0
- Published: 2026-08-22 · Updated: 2026-08-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/zenlua-tool-tree

## The download, docs, issue and translation links all address a different owner

The single most important thing to know before you click anything is that the repository and its links do not agree. The repository is Zenlua/Tool-Tree. Every download and documentation address printed in the project page belongs to a different owner: the stable release link and the beta tag link go to Kakathic/Tool-Tree, the website links go to Kakathic.github.io, the issue tracker link points at Kakathic/Tool-Tree, and the four translation directories are given as paths under Kakathic/Tool-Tree. The two accounts are not interchangeable in practice, since a release published under one owner is not reachable from the other. If you are following a link from a search result, a forum post or a translated tutorial, check which owner it names before you assume you have reached the same artefact. The same split is visible in the metadata: the project homepage is recorded as zenlua.github.io while the page names Kakathic.github.io as the official website. Both spellings of the project name appear side by side in one heading, one linking to the release feed and one to the repository.

## Release tags and release names do not use the same version string

The published releases show a small but real inconsistency. Tags are written with a leading capital V, as V1.6.0, V1.5.9 and V1.5.8, while the release names inside them are written out in full, as Tool-Tree 1.6.0. That is not cosmetic if you script a download: an automated fetch that assumes the tag matches the name will look for a string that does not exist. The dates are close together, with 1.5.8 on 2026-08-13, 1.5.9 on 2026-08-17 and 1.6.0 on 2026-09-05, so the project is moving in small increments rather than infrequent large jumps. The last push to the repository was 2026-09-22, and the repository is not archived. The change log is reachable two ways, from a Version.md file kept in the repository root and from a hosted page, which is a useful cross-check when the two disagree.

## Unpack covers zip and apks, and the pack list leaves both out

The two capability lists are worth reading side by side, because they are not the same list with the arrows reversed. The unpack side covers the partition and archive formats:

```
boot, dtbo, ext4, erofs, f2fs, payload, super
zip, apk, apks, apex, capex, squashfs, amlogic, ...
```

The pack side covers the same partition formats but a shorter archive list:

```
boot, dtbo, ext4, erofs, f2fs, payload, super
amlogic, apk, apex, capex, squashfs, ...
```

So `zip` and `apks` appear on the unpack side and not on the pack side, and the trailing ellipsis on both is the only signal that the list is not exhaustive. Note also that `zip` is a container rather than a partition, which tells you the tool treats archives as first-class input alongside disk images. Amlogic is listed on both sides, which is the one vendor-specific format named. If your workflow goes archive to image, the missing entry is exactly the one you will hit.

## Inputs sit on the sdcard while outputs land under /data/local

The directory layout is short enough to memorise, and it explains a lot about how the tool is meant to run. Input files are read from two folders on external storage: ROM images from `/sdcard/TREE/ROM` and APKs from `/sdcard/TREE/APK`. Output goes somewhere else entirely, and the two output paths are not parallel: repacked APKs are written to `/data/local/TOOL` while repacked ROM output goes to `/data/local/TREE`. Putting outputs under `/data/local` rather than back on the sdcard is a deliberate choice, since that is where a shell process on a non-rooted device can normally write. The two input folders being separate means a ROM job and an APK job never collide, and the trailing `TOOL` for APK output is a different word from the `TREE` used by both the ROM input and the ROM output, so do not assume the basename is reused. Copying a large payload image to the sdcard and back is the part of the round trip that costs you time.

## Aarch64 and Armv8l only, with root treated as a preference

The support table is short and the architecture row is the binding constraint: Aarch64 and Armv8l are the two listed architectures, and nothing else appears. That rules out 32-bit-only images and any device whose userspace is not one of those two, so a ROM built for a different ABI is out of scope before any other consideration. The two root rows are both positive, root is supported and no root is also supported, and the documentation points at a dedicated beginner guide for the no-root case rather than treating it as an afterthought. Given that the output directories sit under `/data/local`, the no-root path is a coherent design rather than a stripped-down mode: a shell-accessible path that does not need elevated privileges is enough for the documented workflow. What the project does not state on that page is which Android versions are covered, which is the gap to close before you start pulling images off a device.

## Two download channels, and the configuration is TOML you can generate

There are two release channels rather than one. The stable channel is the latest release, and the beta channel is a separate moving tag, so a stable link and a beta link can hand you different builds of the same project with no version arithmetic to do. Configuration is handled as TOML, and the project publishes the same material three times over: a Markdown guide, an HTML rendering of it, and a generator page that writes the configuration for you. Having the generator alongside the prose matters more than it sounds, because a TOML file with a wrong key name fails at load time with a message that will not tell you which key was wrong. The language utilities follow the same pattern of being generated and checked in: they are usually a file called `language.bash` inside the relevant directory. Add-ons are supported too, with a guide for creating them and a separate list directory for the ones that exist, so the tool is extensible rather than a fixed feature list.

## Translations are spread across four directories in the Android project

Localisation is not a single resource folder here, and that is unusual enough to be worth knowing before you file a translation patch. Four separate locations are offered. Interface resources live in the standard Android path under the app module. Shell language files live under the assets directory, in a nested `etc/lang` path. Add-on language lives in a list directory under the repository's `.github` folder, and everything else in another `.github` folder beside it. Two of the four are therefore not part of the shipped application at all, which means a translator working in the Android resources folder will silently miss the shell strings, the add-on strings and the loose ones. The project asks for help with translations and says contributions are welcome, and the practical advice is to open all four before starting, using `language.bash` as the anchor for the shell side. The same directory layout means the app is a normal Gradle module, with `app/`, `build.gradle`, `settings.gradle` and `gradle.properties` at the root.

## The toolkit is a Kotlin app that builds on Termux and borrows from Kr-Script

Two upstream projects are credited, and both explain parts of the design. Termux is credited, which is the natural companion for a shell-driven tool on Android where the output directories live under `/data/local`. Kr-Script, a collection of shell scripts for Android device work, is credited as the other source, which fits a tool whose operations are file transformations rather than API calls. A further references page exists for everything not named on the credits list. The issue tracker is on GitHub, with a Telegram channel alongside it, so a report can go either way depending on how urgent it is. The project is written in Kotlin and packaged as an Android application, with a Gradle wrapper checked in, so building from source means an Android toolchain rather than a standalone compiler. It is also a closed binary in practice: the release page offers a prebuilt APK and a beta tag, and nothing in the published material describes a command line that runs the same operations outside the phone.

## Conclusion

Use Tool-Tree if you need to get at the contents of a boot, super or payload image on an Aarch64 phone and put something back, especially when rooting is not an option, and you are comfortable with a sideloaded APK and a TOML config. Do not expect a polished or fully self-describing project: the packaging, the docs site and the release history are split across two GitHub owners, and the format lists disagree with each other. Before you rely on it, confirm which of the two accounts actually serves the release you downloaded, read the TOML guide rather than guessing at configuration, and check the stable and beta channels separately since the page offers both.

## FAQ

### Can Tool-Tree repack a ROM on a phone without root?

Yes. The support table marks both root and no root as supported, and there is a separate beginner guide for the no-root case. Output is written under /data/local, which a shell process can reach without elevated privileges.

### Which image formats does Tool-Tree unpack and repack?

The unpack list covers boot, dtbo, ext4, erofs, f2fs, payload and super, plus zip, apk, apks, apex, capex, squashfs and amlogic. The pack list covers the same partition formats but leaves zip and apks off its archive list.

### Which GitHub account do I download Tool-Tree from?

The repository is Zenlua/Tool-Tree, but the stable, beta, documentation, issue and translation links on the project page all point at Kakathic/Tool-Tree and Kakathic.github.io. Confirm which owner serves the release before you fetch it.

### How is Tool-Tree configured and where are its translations?

Configuration is TOML, published as a Markdown guide, an HTML version and a generator page. Translations sit in four places: Android resources, shell files under the assets etc/lang path, and two .github folders for add-on and other strings, with utilities usually in a language.bash file.

## Sources

- [Official documentation](https://zenlua.github.io/Tool-Tree)
- [Official README](https://github.com/Zenlua/Tool-Tree#readme)
- [Project repository](https://github.com/Zenlua/Tool-Tree)
- [Release notes](https://github.com/Zenlua/Tool-Tree/releases)

---

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