# PDF Toolkit: an offline Android PDF editor split into three build flavors

> PDF Toolkit is a Kotlin and Jetpack Compose Android application that merges, splits, compresses, converts and annotates PDFs entirely on the device. The interesting choice is its build flavor matrix, where the OCR engine changes depending on where the APK is distributed.

**Karna14314/Pdf_Tools** — Privacy-first, offline PDF editor for Android. Merge, split, compress, convert and annotate PDFs — 100% on-device, no internet required.

- Repository: https://github.com/Karna14314/Pdf_Tools
- Website: https://play.google.com/store/apps/details?id=com.yourname.pdftoolkit
- Stars: 655 · Forks: 43
- Language: Kotlin
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/karna14314-pdf-tools

## PDF Toolkit does the whole job without sending a file anywhere

PDF Toolkit is an Android application for working with PDF files, and the single organising idea behind it is that nothing leaves the phone. The feature list covers the familiar ground of a PDF utility: merge, split, compress, reorder, rotate, extract and delete pages, convert images to PDF and PDF pages back to images, turn a webpage into a PDF, scan a physical document with the camera, annotate with highlights and freehand drawing, sign a document, fill in forms, flatten those forms, lock a file with a password, remove a password you know, and apply a watermark. Alongside that sit an image toolkit for compression, resizing, format conversion and stripping EXIF data, and text extraction through OCR. Two claims in that list are worth separating from the feature names. The app declares no internet permission, and the project states that all processing happens on device with no cloud and no servers, with no data collection or tracking. That is the reason to choose this over a web-based converter when the document is a contract, a medical record or anything covered by a non-disclosure agreement. The trade-off is that you have no browser tab to share the tool through and no cross-platform consistency, since it exists only as an Android app under the package name com.yourname.pdftoolkit.

## Three flavors, two OCR engines, and no ads in any of them

The build flavor matrix is the most interesting engineering decision in the project, and it comes down to one dependency that Google owns. Three flavors are defined, and the OCR engine changes with the distribution channel. The playstore flavor uses ML Kit and ships to Google Play. The fdroid flavor uses Tesseract and ships to F-Droid. The opensource flavor also uses Tesseract and ships through GitHub Releases. Ads and Firebase are marked as absent in all three, and the project states that every flavor is privacy-first with no ads and no analytics, with no proprietary dependencies except ML Kit in the Play Store flavor. The reason for the split is stated plainly in the feature list. ML Kit OCR is described as the on-device, smaller APK option and is available in the Play Store flavor, while Tesseract OCR is described as the 100% open source option used by the F-Droid and opensource flavors, running as an offline Tesseract engine without Google Play Services or a network connection. For an F-Droid user the constraint is not a preference but a platform rule, since a build distributed there cannot carry Google proprietary components. That single dependency shapes the OCR choice across three separate distributions of the same application.

## The stack is Compose with PdfBox-Android and CameraX doing the heavy lifting

The technology choices describe a fairly conventional modern Android application. The language is Kotlin throughout, and the UI framework is Jetpack Compose with the third generation of Google's design system. The architecture is described as MVVM plus Clean Architecture, which is a layered structure where UI, domain and data responsibilities are separated, and the project backs that up with Coroutines and Flow for asynchronous work and Room for the database alongside DataStore for preferences. PDF processing is handled by PdfBox-Android and the platform's own Android PdfRenderer, so document manipulation does not depend on a third party rendering engine. Annotation is described as a custom Canvas with BlendMode layering rather than a library, which is why highlights and freehand drawing can sit over a page without being baked into it. Camera work uses CameraX, and image loading and processing goes through Coil, Glide and uCrop. The build itself is Gradle with KSP, and the repository root carries build.gradle.kts, settings.gradle.kts, gradle.properties, gradlew and gradlew.bat. The interesting entry for a developer is that the PDF layer is not one library but a pair, a cross platform PdfBox-Android and the Android PdfRenderer, which suggests rendering and manipulation have different requirements.

## Building it locally means choosing one of three Gradle assemble tasks

The prerequisites are stated before the build commands: Android Studio Hedgehog or newer, JDK 17 or newer, and Android SDK 26 or newer. With those in place, the repository is cloned and one of three variants is assembled. The commands are on the Gradle wrapper, so no local Gradle install is needed:

```bash
# Clone the repository
git clone https://github.com/Karna14314/Pdf_Tools.git
cd Pdf_Tools

# Play Store flavor (ML Kit OCR)
./gradlew assemblePlaystoreRelease

# F-Droid flavor (Tesseract OCR, no proprietary deps)
./gradlew assembleFdroidRelease

# Opensource flavor (fully FOSS)
./gradlew assembleOpensourceRelease
```

The three assemble tasks map one to one onto the flavor table, so the choice of task decides both the OCR engine and the distribution target of the resulting APK. Someone who wants to reproduce what F-Droid serves builds assembleFdroidRelease, and the result carries Tesseract rather than ML Kit. Someone who wants the smaller APK with ML Kit builds assemblePlaystoreRelease. The opensource flavor produces the variant offered as a manual APK download through GitHub Releases. The repository also contains a fastlane/ directory, a distribution/ directory, store_assets/ with the app icon and Play Store artwork, metadata/, a release/ directory and scripts/, which together indicate that producing a store-ready artifact is part of the repository rather than something done by hand.

## Three ways to install, and the package name still reads like a placeholder

Installation is offered through three channels and each has a practical difference. F-Droid gives automatic updates and is described as 100% FOSS. Google Play gives automatic updates for the Play Store variant. GitHub Releases offers a direct APK download for the opensource flavor with manual installation. The F-Droid path is spelled out in detail, and the interesting part is what it promises about the build itself rather than the install. The project states that the fdroid build flavor has zero proprietary dependencies or trackers, that the F-Droid builds are standard automated builds compiled from source and described as reproducible and verified, and that updates arrive automatically with verified security. The caveat sits in the URLs themselves. Every distribution link points at com.yourname.pdftoolkit, both on F-Droid and on the Play Store, and the repository name is Pdf_Tools while the application is called PDF Toolkit. A package identifier containing yourname is a placeholder that was never replaced, and that is the kind of detail worth confirming before you install from a store listing, since it makes the listing harder to be sure about at a glance. The F-Droid route, where the build is compiled from source on F-Droid's own infrastructure, is the one where that verification claim is most meaningful.

## The README ends at contributing, so the details live elsewhere

The documentation in the repository is uneven, and knowing where to look saves time. The README itself is the most complete part, covering the feature list, the flavor table, the technology stack, the build commands and the download links. After the contributing section it simply stops mid-sentence, so the contribution rules, the code of conduct and the branch policy are not spelled out there. Some of that detail lives in the root of the repository instead. There is an AGENTS.md file, a CHANGELOG.md, a CODE_OF_CONDUCT reference in the file list, and a docs/ directory, which usually holds the longer form documentation. There is also a privacy-policy.html, a licenses.html and an index.html at the top level, which for an app distributed on both Google Play and F-Droid is a sensible way to keep those pages under version control rather than in a separate site repository. A metadata/ directory and a scripts/ directory sit alongside them. Two limitations of the current documentation are worth naming. The README does not describe any configuration, build-time flags or manifest permissions beyond the statement about internet access, and it does not document how the OCR language data is packaged for the Tesseract flavors, which is the detail that would most affect the size of a self-built APK. There is also no mention of a rollback procedure for a failed upgrade from a Google Play install to an F-Droid install, which matters because the package identifier is shared across channels.

## Where this falls short of a desktop or browser PDF workflow

The boundaries are obvious but worth stating plainly. This is an Android application, so it cannot be used on a desktop, in a browser, or in a server pipeline. If your PDF work happens on a laptop, a phone-only tool adds a transfer step and, for anything long, an awkward one. The second limit is OCR capability. The Tesseract path is the one used by the F-Droid and opensource flavors, and Tesseract is a different engine with different language support, different accuracy characteristics and a different output from ML Kit. Choosing the 100% open source build means choosing Tesseract for that reason, and the README gives no comparison of results between the two engines. If a workflow depends on OCR accuracy for a specific script, you will want to try the flavor you will actually ship with rather than assume the engines behave alike. A third limit is the license boundary. The project is under the Apache 2.0 licence, which permits modification and redistribution with the usual obligations to retain the licence and notices, and the repository ships a licenses.html alongside the LICENSE file. That matters more than usual here because the Play Store flavor depends on Google ML Kit, whose own terms apply to that build, so a clean open source redistribution of the application is the opensource or fdroid flavor rather than the Play Store one.

## Conclusion

PDF Toolkit suits Android users who need to handle confidential documents without uploading them anywhere, and it suits developers who want a readable Jetpack Compose and MVVM project with clean flavor separation. It is the wrong choice if you need a desktop or browser tool, or if you need a specific OCR capability that only the ML Kit path provides and are unwilling to install the Play Store flavor. Verify first which flavor you install and therefore which OCR engine you get, that your device meets the Android SDK 26 requirement, and that a build from source works on your machine with JDK 17 or newer before you rely on it for anything.

## FAQ

### Does PDF Toolkit upload my PDF files to a server?

The project states that all processing happens on-device with no cloud and no servers, no data collection or tracking, and no internet permission. OCR runs locally through ML Kit in the Play Store flavor and Tesseract in the F-Droid and opensource flavors.

### What is the difference between the PDF Toolkit build flavors?

The three flavors differ in OCR engine and distribution channel: playstore uses ML Kit and ships to Google Play, fdroid uses Tesseract and ships to F-Droid, and opensource uses Tesseract and ships through GitHub Releases. Ads and Firebase are absent in all three.

### How do I build PDF Toolkit from source?

You need Android Studio Hedgehog or newer, JDK 17 or newer, and Android SDK 26 or newer. After cloning, you run ./gradlew assemblePlaystoreRelease, ./gradlew assembleFdroidRelease or ./gradlew assembleOpensourceRelease depending on the flavor you want.

### Is PDF Toolkit available on F-Droid?

Yes. The project publishes on F-Droid under com.yourname.pdftoolkit, and states that the fdroid flavor has zero proprietary dependencies or trackers and is built from source by F-Droid's automated builds.

## Sources

- [Karna14314/Pdf_Tools on GitHub](https://github.com/Karna14314/Pdf_Tools)
- [License: Apache-2.0](https://github.com/Karna14314/Pdf_Tools/blob/master/LICENSE)
- [Project website](https://play.google.com/store/apps/details?id=com.yourname.pdftoolkit)
- [README](https://github.com/Karna14314/Pdf_Tools/blob/master/README.md)
- [Releases](https://github.com/Karna14314/Pdf_Tools/releases)

---

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