Offline PDF Search Architecture on Android

Direct answer

A useful offline PDF search workflow makes a narrow promise: search text the application actually extracted from a user-selected PDF, and return enough source location for the reader to verify each match. Older Android PdfRenderer APIs render pages; API 35 adds PdfRenderer.Page.getTextContents and searchText. Pin and test the actual text API or parser separately: rendering pixels alone is not evidence of extracted text. The Storage Access Framework offers a user-mediated document URI and access grant, but it does not promise that a provider is local, that the source stays available, or that the selected PDF contains selectable text. Test each assumption separately. RAG-01 and PRIVACY-01 support provenance and data-boundary checks; neither fact establishes any Cove PDF capability. This guide is a verification method, not a product statement. Keep the initial feature deterministic: index text returned by a named parser, retain document identity and page number, and search literal terms. Scanned-image OCR is a separate path with its own output and failure states. Do not silently render every page and send it to a vision model, then label that result ordinary PDF search. Do not mix embeddings or generated answers into these acceptance criteria. They change retrieval behavior and require separate evidence, citation rules, privacy analysis, and a not-found policy. Prepare a fixture corpus before changing code. Include a born-digital file with selectable text, an image-only page, a mixed document, rotated pages, repeated headers, a malformed or restricted file if in scope, and two files with the same display name from different providers. A reviewer should annotate expected terms, page locations, and terms that must not appear. Prefer synthetic documents; if using an authorized real file, keep its content out of logs and reports. Record a stable test identifier and, where appropriate, a digest of source bytes so a changed fixture cannot replace the reference unnoticed. Trace every layer. Record how the URI was obtained, whether permission was temporary or persisted, the parser name and revision, which pages produced text, and why other pages did not. An index record should carry source identity, page, parser revision, and enough offset or excerpt information for the user to reopen the original context. If the parser exposes only a flat string, do not invent page mapping. If normalization changes punctuation or case, preserve a path back to the original excerpt and document the rule. A result is useful only if it is auditable. Search a labeled query set whose expected pages were fixed before running. Check exact terms, punctuation, repeated headers, duplicate files, empty pages, and terms at page boundaries. Report misses and unexpected hits. A search result is not an answer to a broader question: show the source page so a person can read context. If ranking is introduced, define relevance judgments separately from parser correctness and literal matching. Access and retention need a second test pass. A provider may revoke access, return changed bytes under a document handle, or require network access. Do not infer local-only processing from an offline label. Observe the workflow under a controlled no-network condition and note which setup or provider paths are unavailable. Decide whether the app holds a private copy, extracted-text cache, index, or only a URI; these have different retention implications. On deletion or grant revocation, invalidate all derived text and search records associated with that source. Confirm a deleted term no longer appears in search, diagnostics, backup, or test exports. The final report should name the build, Android version, provider route, parser revision, fixture manifest, index schema, query set, and failures. It may say a controlled fixture produced a verified page hit; it cannot generalize to every PDF, provider, or language. Keep scanned pages visibly unindexed unless a tested OCR path exists. Keep answer generation outside scope. These boundaries make a small local search function testable without promising that Android rendering, Cove, or an unverified model already provides PDF understanding.

A traveler searches an itinerary PDF before boarding

A traveler opens a saved itinerary through the Android document picker before boarding. The PDF contains selectable hotel text, a scanned map page, and repeated headers. Later, without connectivity, the traveler searches for a station name and needs a page-level result that can be checked against the original source.

Decision

Test URI access, extraction, page mapping, literal search, and deletion separately; report image-only pages as unindexed unless a distinct OCR path has been tested.

Expected outcome

A verified hit identifies its source and page, while a scanned page produces a clear limitation rather than an invented result.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Document provenance
• Index revision
• Labeled retrieval queries

Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.

Implementation workflow

1. Define import and permission states. Use a user-selected fixture URI and record provider, grant type, process-restart behavior, and revocation result. A picker selection alone does not prove that a document is stored locally.
2. Classify page extraction before search. Run the selected parser and record per-page text, empty output, errors, and page mapping. Keep PDF rendering, text extraction, and optional OCR as separate stages.
3. Build a provenance-preserving index. Store source identity, page number, parser revision, normalized terms, and enough offset information to reopen and verify a result in the original context.
4. Evaluate with a labeled query set. Prepare expected terms and page locations before running searches. Check repeated headers, punctuation normalization, missing pages, duplicate names, and unexpected hits.
5. Exercise revocation and deletion. Remove or revoke the source, invalidate derived records, and search again. Confirm deleted content is absent from results, logs, backups, and test output.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• Every returned hit has a verified source identifier and page location, or the interface states that page mapping is unavailable.
• Image-only, malformed, restricted, and revoked inputs produce explicit outcomes and are never shown as successfully text-indexed.
• The report distinguishes parser, literal search, optional OCR, and generated answers without claiming an unverified Cove capability.

Decision table

Failure patterns to prevent

• Losing page locations
• Mixing embedding versions

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Android PdfRenderer API
• Android PdfRenderer.Page versioned text APIs
• Android Storage Access Framework documents and files
• Android document provider URI grants

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions