DEV Community: securepdfeditor

How We Built PDF OCR with Zero INTERNET Permission on Android

securepdfeditor — Wed, 21 Oct 2026 07:59:06 +0000

An Android app that declares no INTERNET permission cannot download models. That is the whole problem, and it shaped every other decision in this post.

This is VaultPDF, an offline PDF editor (com.securepdfeditor.pro, v2.0.1). Scanned PDFs become searchable, and can also be rebuilt into editable documents. Everything below runs on device.

1. "No INTERNET permission" is an artifact property, not a promise

Most "offline" claims are behavioral: the app says it does not upload. Ours is structural. The manifest strips the permission at merge time:

<uses-permission android:name="android.permission.INTERNET" tools:node="remove" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" tools:node="remove" />

Every release bundle is checked with aapt2 dump permissions, and the release is blocked if INTERNET reappears through a transitive dependency. Users can verify the same thing without trusting us: Settings → Apps → VaultPDF → Permissions has no network entry at all.

That constraint turns OCR into a delivery problem before it is a recognition problem.

2. Getting 254 MB of models onto a device that never downloads

Cloud APIs, runtime language packs, and "download the model on first launch" are all dead on arrival. What is left is Play Asset Delivery, where Google Play performs the transfer and the app still has no network capability.

We ship exactly one install-time pack, ocr_models, about 254 MB:

Asset	Size	Role
`layout.onnx`	214 MB	PP-DocLayoutV2 page layout analysis
`rec.onnx`	21.2 MB	PP-OCRv6 text recognition
`rec_korean.onnx`	13.5 MB	Korean recognition (see §8)
`det.onnx`	9.9 MB	text detection
`table.onnx`	7.8 MB	SLANet+ table structure

Install-time means it is present at first launch, so there is no "OCR is still downloading" state and no first-run network dependency.

0-INTERNET does not mean the device never touches the network. It means the app itself has no network capability, and distribution is delegated to Play. That distinction matters, and it is the honest version of the claim.

3. Why not ML Kit

ML Kit answers "what text is in this image?" A PDF editor needs more:

layout classes — body, title, table, figure, formula, header, footer;
table structure — rows, columns, cells;
reading order for multi-column pages;
PDF object reconstruction — invisible text layers, editable text objects, table grids;
CJK-safe search, copy, and editing.

ML Kit is not bad. It solves a smaller problem than the one a PDF editor has.

4. Searchable and editable are two different outputs

The recognition result is not the product. The product question is: how does the text get written back into the PDF?

Searchable mode (default). The original scan is untouched. Text objects are added with renderMode=3, so they are invisible but searchable and copyable. Same idea as Acrobat's "Searchable Image".

Editable mode. A new document is generated from visible text objects, table lines, and cell text. The original file is never mutated in place.

Our early failure was drawing visible OCR text on top of a page that still contained the scan, so both texts printed over each other. The fix was not coordinate tuning — it was semantic separation:

searchable = original image + invisible text;
editable = new document + visible reconstructed text;
the two live as separate documents, and the user switches between them.

That also removes the worst failure mode of editable OCR: a bad rebuild can never destroy the original scan.

5. OCR changes what redaction has to mean

Before OCR, a scanned page is pixels. After OCR, it may also contain a hidden text layer.

Draw a black rectangle over the pixels and the text underneath is still searchable and copyable. Real redaction has to remove both the visible content and the text layer.

This is a test, not a slogan — the suite includes searchablePdfWriter_ocrTextIsRemovedByErase.

6. The CJK bug that taught us the most: Kangxi radical substitution

One of the nastiest bugs came from our custom libpdfium.so ToUnicode CMap behavior: some ideographs that share shapes with Kangxi radicals were stored as radical codepoints.

高 (U+9AD8) came back as ⾼ (U+2FBC);
白 as ⽩;
力 as ⼒.

One root cause surfaced as three separate product bugs:

copy and extraction returned radical codepoints;
search failed, because the user typed the real ideograph while the PDF stored the radical form;
editing failed, because char → charcode mapping could not resolve.

The fix was a CjkNormalize layer: display/copy/extraction map radicals back to canonical ideographs, search checks both forms, and editing registers canonical aliases in the charcode map.

The lesson generalizes: the model can recognize text perfectly and PDF write-back can still corrupt its semantics.

7. The real-device OOM: 214 MB is not something you casually `readBytes()`

layout.onnx is 214 MB. Opening it from a normal file path worked in development. Through the real install-time PAD path it did not, because the early code did this:

assets.open("ocr-models/layout.onnx").readBytes()

That allocates ~214 MB in the JVM heap. On device:

Throwing OutOfMemoryError "Failed to allocate a 213964005 byte allocation"
model missing: layout.onnx

The UI symptom was misleading: OCR simply "found no text."

The fix: stream-extract to a cache file, then let ONNX Runtime mmap it by path. Copy with a 1 MB buffer, never materialize the model in the heap, extract once and reuse.

This only reproduced through the release path — AAB + bundletool --local-testing + real device + logcat. A debug build hid it completely.

8. Japanese and Korean

Japanese works through the default PP-OCRv6 dictionary; kana and shared Han characters are covered, and on-device tests recognize mixed-script lines correctly.

Korean needed its own path. The default dictionary has no Hangul, so we added a dedicated PP-OCRv5 Korean recognizer (13.5 MB) and route low-confidence suspected-Korean regions to it.

The general lesson: multilingual OCR is not "the model supports 100+ languages." Dictionaries, fallback routing, and confidence strategy all have to ship as well.

9. The tier we measured and then did not ship

We also built a much stronger high-accuracy tier: PaddleOCR-VL 1.6 Q4 running through llama.cpp/mtmd with Vulkan offload, via JNI. On a natural 150-page sample it scored 0.0499 mean text-edit, with English at 0.0368 and English/Chinese mixed at 0.0322 — at or near the public PaddleOCR-VL reference line. On a Xiaomi XRing O1 device, Vulkan offload cut one crop from ~34 s to ~20 s with byte-identical output.

It is not in the current release.

PaddleOCR-VL is about 1.1 GB, which cannot be an install-time pack. It has to be a fast-follow pack — and fast-follow extraction requires a foreground service. The asset-delivery library then declares FOREGROUND_SERVICE and FOREGROUND_SERVICE_DATA_SYNC, which means a Play foreground-service declaration and a justification video for an app whose entire pitch is an empty permission list.

We chose the empty permission list. The manifest now strips those permissions too, and ships only the install-time pack.

That is the real trade-off behind "zero permissions": it is not free, and this is what it cost us. The VLM path stays in the codebase and is measurable, but the current build does not carry it.

10. Results, stated plainly

Fast tier (the shipped one), official OmniDocBench text_block edit distance, full 1651-page set, lower is better:

text_edit: 0.263
latency:   1.3–1.9 s/page

That is not leaderboard SOTA, and we are not going to pretend otherwise. It is a fast, stable, fully offline default that handles everyday scanned documents.

The numbers people usually quote for this model family come from the large VLM tier — the one described in §9 that we did not ship.

11. Testing: 338 instrumentation tests

Validation was not "click a few pages." The Android test suite currently has 338 @Test cases, with OCR-relevant coverage including:

searchable PDF writer with invisible text layer;
replacement of a previous invisible OCR layer;
reconstructed PDF writer with visible editable text;
rotated pages;
OCR text removed by erase/redaction;
CJK font, editing, search, and page-geometry regressions.

We also used bundletool --local-testing to reproduce Play's delivery behavior locally — that is how the 214 MB OOM was caught.

Generating code is cheap now. These checks are what make it engineering.

12. What this cost, and what it bought

The hard part was never one model. It was the chain:

delivering models without giving the app network capability;
loading large models without OOM;
writing results back without destroying the original;
keeping search, copy, edit, and redaction on one semantic layer;
surviving PDF font and ToUnicode traps;
and deciding what to leave out when a feature and a principle collided.

The shipped shape is: fast on-device OCR by default, searchable and editable outputs, true redaction that also removes the OCR layer, and no INTERNET permission in the app.

You can verify the last one yourself in Settings.

VaultPDF is on Google Play: https://play.google.com/store/apps/details?id=com.securepdfeditor.pro

Zero Permissions: how an Android PDF editor ships with no INTERNET permission

securepdfeditor — Wed, 23 Sep 2026 06:21:28 +0000

How an Android PDF editor ships with no INTERNET permission — and why that is a different kind of privacy claim

Most privacy claims in app stores are unfalsifiable. "We don't sell your data." "Your files are never shared." "Privacy first." You cannot check any of these. You are asked to trust a policy document written by the party you are trying to evaluate.

There is a second kind of privacy claim: one the operating system enforces on your behalf. On Android, android.permission.INTERNET is a hard gate. An app that does not declare it cannot open a network socket. Not "promises not to" — cannot. socket() fails, URL.openConnection() throws, and the failure is at the OS level, not in the app's own code.

This article is about how VaultPDF — a cross-platform PDF editor with real content-stream text editing, redaction, and offline OCR — ships with that permission removed. It is a writeup of specific engineering problems, including the parts that are unglamorous and the places where the guarantee is weaker than the marketing would suggest.

If you want to check the claim before reading further, it takes about fifteen seconds: install the app, then Settings → Apps → VaultPDF → Permissions. You will find no permissions listed. Not camera, not storage, not network.

1. What the shipped manifest actually contains

Here is the relevant part of the source manifest:

<uses-permission android:name="android.permission.INTERNET" tools:node="remove" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" tools:node="remove" />

Those two lines are the whole trick, and they are also not the whole story. The tools:node="remove" attribute is a manifest-merger instruction. It does not declare a permission — it deletes one that would otherwise be merged in from a library.

That distinction matters, because the interesting question is not "how do I not write <uses-permission INTERNET>". It is: why would it have been there in the first place?

Because your dependencies put it there.

2. Your dependencies are declaring permissions for you

Gradle's manifest merger combines your manifest with the manifests of every library in your dependency graph. Libraries routinely declare permissions they believe they need. In this project the offenders were:

com.google.mlkit:text-recognition-chinese — on-device OCR
com.google.android.gms:play-services-mlkit-document-scanner — camera scanning
com.android.billingclient:billing-ktx — in-app purchases

Pulling in ML Kit and Play Billing is how a project ends up with INTERNET, ACCESS_NETWORK_STATE, and sometimes more, without a single line in your own manifest asking for them. You inherit capability you never requested and may not want.

tools:node="remove" is the supported way to reject the inheritance. The merged output for the release build confirms it worked — the final AndroidManifest.xml in build/intermediates/ contains exactly two <uses-permission> entries, and neither is network-related:

<uses-permission android:name="com.android.vending.BILLING" />
<uses-permission android:name="com.securepdfeditor.pro.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION" />

com.android.vending.BILLING is required for in-app purchases. The second is an app-local, signature-level permission that AndroidX generates automatically. That is the complete list.

There is a tradeoff worth stating plainly: removing a permission does not remove the code that wanted it. More on that in the next section, because it is the most interesting part of this whole exercise.

3. The telemetry pipeline that is still in the APK

After stripping INTERNET, the merged manifest still contains this:

<service
    android:name="com.google.android.datatransport.runtime.backends.TransportBackendDiscovery"
    android:exported="false" >
    <meta-data
        android:name="backend:com.google.android.datatransport.cct.CctBackendFactory"
        android:value="cct" />
</service>
<service
    android:name="com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService"
    android:exported="false"
    android:permission="android.permission.BIND_JOB_SERVICE" />
<receiver
    android:name="com.google.android.datatransport.runtime.scheduling.jobscheduling.AlarmManagerSchedulerBroadcastReceiver"
    android:exported="false" />

This is Google's datatransport stack — the telemetry transport layer that ML Kit and other Google libraries use to ship events back to Google. cct is the CCT backend factory, i.e. the path used for Google's own telemetry ingestion.

It is still there. It was merged in from a dependency, and no tools:node="remove" was applied to it. There is a service registered, a job scheduler, an alarm receiver — the entire apparatus for scheduling and transmitting usage events.

And it cannot transmit anything, because the process it runs in has no INTERNET permission. Any socket it opens will throw SecurityException. The pipeline is present and permanently inert.

This is the most useful thing to understand about permission-based privacy: the permission is the switch, not the code. Auditing for trackers by reading library names or scanning for SDK classes will not tell you whether an app can exfiltrate data. The permission model will. An app can bundle every analytics SDK in existence and still be structurally incapable of phoning home, and conversely an app with a tiny dependency list can phone home freely if it holds INTERNET.

For anyone building a privacy-positioned app, this suggests a genuinely stronger design: do not audit your way to a clean dependency graph — which is a moving target as libraries change. Remove the capability. Then the dependency graph stops mattering.

4. Billing without `INTERNET`

This is the part people assume is impossible. An app that takes payments must talk to Google's servers. So how does it do that with no network permission?

It doesn't. The Play Store app does it.

Play Billing works over IPC. Your app binds to the billing service exposed by the Play Store, sends a purchase request, and receives the result. The Play Store — which does hold INTERNET — performs the actual network communication. Your app never touches the network, and never needs to.

The merged manifest shows both halves of that arrangement:

<uses-permission android:name="com.android.vending.BILLING" />

<queries>
    <intent>
        <action android:name="com.android.vending.billing.InAppBillingService.BIND" />
    </intent>
</queries>

The <queries> element declares the intent your app wants to resolve — this is how you find the billing service under Android 11+ package visibility rules. The BILLING permission is what lets you bind to it.

So the permission profile is coherent rather than suspicious: an app that holds BILLING and binds to a billing service, and holds no network permission, is describing a client that delegates network I/O to a separate process. That is exactly what is happening.

The billing products in this app are securepdf_monthly_sub and securepdf_lifetime. Both exist purely as a donation mechanism — the app has no feature gates, so there is nothing for a purchase to unlock. That is a product decision, but it is also why the permission profile stays small: there is no entitlement server, no license check, no account system to justify a network stack.

5. OCR without `INTERNET`

Optical character recognition is the other feature that conventionally implies a server. Most "scan to searchable PDF" pipelines upload the page, run recognition in the cloud, and return text.

The alternative is a bundled model. The dependency here is:

implementation("com.google.mlkit:text-recognition-chinese:16.0.0")

The important detail is which artifact this is. ML Kit ships in two flavours: a bundled variant, where the model and native pipeline are inside the AAR and get packaged into your APK, and a Play Services variant, where the model is downloaded on demand at runtime. Only the bundled variant can work with no network, and only the bundled variant avoids adding INTERNET to your merged manifest.

The tradeoff is size. The bundled models and libmlkit_google_ocr_pipeline.so are in the APK. That is a real cost, paid in download size, in exchange for the recognition working in airplane mode.

The output is written as an invisible text layer — PDF text render mode 3:

OCR-created text uses PDF text render mode 3 (invisible).

The scanned image is preserved underneath, so the page looks identical, but the text is now selectable and searchable. Coordinates come from bitmap space and have to be mapped into PDF user space, which means handling CropBox offsets and page rotation — a step that is easy to get subtly wrong and produces text that is invisible but offset from the image it is supposed to sit on.

The invisible text layer is a redaction trap

Here is a consequence that is easy to miss, and that matters more than the OCR feature itself.

If a tool rasterizes a page and re-OCRs it, and then a user draws a black box over a name and saves — the visible image may be covered, and the invisible OCR text layer may still contain the name in machine-readable form, extractable with any text tool. The redaction looks complete and is not.

Any honest redaction implementation has to treat the invisible OCR layer as content to be removed, not as metadata to be left alone. In this codebase that is an explicit, tested behaviour:

TRUE REDACT removes overlapping OCR invisible text along with visible page objects.

The general lesson: once you introduce a feature that writes hidden machine-readable text into a document, every downstream deletion feature inherits a new obligation. Test for it explicitly.

6. The camera permission you don't need

Document scanning normally means CAMERA. This project requests no camera permission, and the reason is again architectural:

// On-device document scanner (camera + edge detection + PDF output run in
// Google Play Services; the app itself needs no CAMERA/INTERNET permission).
implementation("com.google.android.gms:play-services-mlkit-document-scanner:16.0.0-beta1")

The scanner UI, camera capture, edge detection, and PDF assembly all run inside Play Services, which holds its own permissions. The app hands off to a Play Services activity and receives the result. The camera is used, but not by this process — so this process does not need to be trusted with it.

This is a pattern worth internalising: delegating work to a platform component moves the permission to the platform component. If you are fighting to justify a permission in your listing, first ask whether the work can be delegated instead of performed.

7. Backup is a data-exit channel

Removing network permission does not automatically keep documents on the device. Android has two separate mechanisms that copy app data off a phone, and disabling one does not disable the other.

allowBackup="false" covers Google cloud backup and adb backup. But on Android 12+, device-to-device transfer is governed separately, by data_extraction_rules. An app that only sets allowBackup="false" and assumes it is covered is wrong — during a phone-to-phone migration, its private data can still be copied.

This project excludes everything from both paths:

<data-extraction-rules>
    <cloud-backup>
        <exclude domain="root" />
        <exclude domain="file" />
        <exclude domain="database" />
        <exclude domain="sharedpref" />
        <exclude domain="external" />
    </cloud-backup>
    <device-transfer>
        <exclude domain="root" />
        <exclude domain="file" />
        <exclude domain="database" />
        <exclude domain="sharedpref" />
        <exclude domain="external" />
    </device-transfer>
</data-extraction-rules>

The reason this matters more than it looks is the font cache. To render edit overlays that match the original document, the app extracts embedded fonts from the PDF and caches them (pdf_fonts). A font cache sounds like an implementation detail. It is not: embedded font subsets are derived from the document, and a subset can carry identifying information about the document it came from. A cached font from a client's contract is a fragment of that contract, sitting in app-private storage.

Treating document-derived caches as user data — not as scratch space — is the right default. It is also the kind of thing that is easy to get wrong precisely because the file extension looks innocuous.

8. Redaction that deletes rather than covers

The distinction this whole product is built on:

Covering draws something on top of the text. The text is still in the file. Selecting the area and copying it returns the original characters. This is the single most common failure in "redaction" features, and it has caused real document-disclosure incidents — including government ones.

Deleting removes the text from the file's content stream, so there is nothing left to extract.

PDF stores text as graphics operators. A BT/ET block brackets a text object, and inside it Tj and TJ operators draw strings. Removing text properly means operating at that level.

Two things make this harder than it sounds:

Text objects are not paragraphs. A single visual line can be split across several text objects, and one BT block can contain several lines. Deleting a whole BT block to remove one line takes out its neighbours. The implementation here does sub-block surgery — blanking individual Tj/TJ operators while leaving the rest of the block intact:

Sub-BT-block stream surgery: blank individual Tj/TJ operators (replace operand+operator with spaces). This preserves all other text in the same BT block.

Text is often not at page level. Content frequently lives inside Form XObjects. There is no single operation that removes it, because the right strategy depends on what else the form contains. Text-only forms can be flattened safely. Forms that also contain paths or images cannot, because flattening loses graphics state — those require editing the form's own content stream and then regenerating it, while leaving the paths and images untouched.

The implementation carries both paths, plus a protectedPointers set so objects that must survive a region deletion are explicitly excluded, and it works in reverse index order to avoid index shifting as objects are removed.

There is also a watermark problem. Many PDFs carry low-opacity watermark text. If it enters the editable text layer, users see phantom editable text that belongs to the watermark rather than the document. The filter here uses fill-colour alpha (below 40/255), not perceived brightness — so light-but-opaque body text is never mistaken for a watermark. Using brightness would silently drop legitimate content in documents with pale text.

9. Where this guarantee is weaker

A writeup that only lists strengths is an advertisement. So:

The guarantee is strongest on Android, because the OS enforces it. No INTERNET permission means no sockets, enforced below the app. That is a hard, checkable property.

On macOS it is an implementation choice, not an enforced one. The macOS build is not sandboxed, and there is no com.apple.security.network.client entitlement — but an unsandboxed binary is not restricted by entitlement declarations, so the absence is a statement of intent rather than a technical barrier. A user on macOS is trusting that no network code was written, not relying on the OS to make network code fail. That is a meaningfully weaker position than the Android side, and it should be described as such.

Removing a permission does not remove capability that travels by other means. The app process cannot open a socket. It can still hand data to another process through an intent or a content provider — and a different app, one that does hold INTERNET, could transmit it. That requires a user-visible action in this design, and no storage permission is held, but "cannot open a socket" is a narrower claim than "data can never leave the device by any route," and it is the accurate one.

The telemetry stack described in section 3 is still in the binary. It is inert, and that inertness is enforced by the permission model rather than by code removal. Anyone auditing the APK will find it. It is better to say so up front than to be caught by it.

These limits do not weaken the core claim. They define it. The core claim — this process cannot open a network socket, and you can verify that in two taps — is true, and it is a stronger claim than most apps in this category are able to make.

10. Verify it yourself

The point of this class of guarantee is that it is checkable by someone who does not trust the developer.

Check permissions at runtime. Settings → Apps → VaultPDF → Permissions. Nothing should be listed.
Check the manifest without running anything. aapt dump permissions <apk>, or open the APK and read AndroidManifest.xml. Look for uses-permission entries.
Test the features offline. Enable airplane mode, then use OCR, editing, redaction, and signing. All of it should work. Recognition and editing have no server path to fail back to.
Test the failure mode. With the app in airplane mode, attempt a purchase. Billing requires the Play Store's network path, so it will not complete — which is itself confirmation that the app is not the one doing the network work.

11. What this cost

Real numbers, from the repository, not rounded up:


Commits	148
First commit	2026-03-14
Last commit	2026-09-21
Android (Kotlin)	15,658 lines, 32 files
macOS (Swift + Objective-C)	7,836 lines
PDFium JNI bridge (C)	1,953 lines
JNI functions exposed	122
Test files	31 Android instrumented + 31 XCTest
`minSdk` / `targetSdk`	24 / 36
PDFium	built from source for Android, 423 exported `FPDF` APIs

The editing engine — text extraction, paragraph merging, font resolution, content-stream editing, redaction — exists twice, in Swift and Kotlin, with matching behaviour. That duplication is not an accident of the project; there is no shared runtime between the platforms, so the second implementation is the price of the second platform.

The point

Privacy claims are usually a promise. This one is a constraint.

A promise can be broken by a policy change, an acquisition, a bad quarter, or a well-meaning engineer adding an analytics SDK to debug a crash. A constraint enforced by the operating system can only be broken by requesting a permission — which is visible in the app store listing, and visible again on the device.

That is the whole argument for building this way. It is not that this code is more trustworthy than someone else's. It is that you do not have to decide whether to trust it.

VaultPDF is on Google Play: https://play.google.com/store/apps/details?id=com.securepdfeditor.pro

Free, no ads, no feature gates, no network permission. Every feature works on first launch. There is an optional purchase that unlocks nothing — it exists so that people who find it useful can pay for it if they want to.

Technical details in this article are drawn from the actual source repository. Numbers in section 11 are counted from the commit history and source tree rather than estimated.