SageSearch

Inspiration

Phone users often remember what a document said, when it was created, or what it was for—but not the generated filename or folder where Android stored it. A receipt may be named IMG_20260312_184522.png while the user remembers only “gym membership around March.” Ordinary filename search cannot connect those clues, and cloud AI search would expose sensitive document context.

What it does

SageSearch is an offline Android file-search launcher for user-approved files. It builds a private local metadata and OCR index, returns immediate preliminary matches, and uses Gemma 4 E2B through LiteRT-LM as a constrained query planner. Gemma converts remembered details into a small versioned search plan; trusted Kotlin code sanitizes and validates that plan before Room and SQLite FTS execute it.

The model never receives filenames, OCR text, database rows, content URIs, candidate documents, or results. It cannot write SQL or invent a file result. Every result card is backed by facts stored in the local index, and the user can open the original with Android’s normal viewer.

How we built it

• Kotlin and Jetpack Compose for a simple black-and-white Android interface
• Android Storage Access Framework for persistent user-approved folders and files
• WorkManager for resumable, source-scoped background indexing
• Bounded on-device ML Kit OCR for images and the first five PDF pages
• Room and SQLite FTS4 for private candidate retrieval and exact-first ranking
• LiteRT-LM 0.16.0 with Gemma 4 E2B on an Arm64 Android phone
• Native constrained decoding, strict validation, deterministic reconciliation, and safe repository APIs
• Cumulative query refinement without maintaining a persistent model conversation

How AI is used

Gemma is deliberately limited to natural-language query planning. The app supplies only the current remembered-detail turns and an optional previously validated plan. The model produces an allowlisted structure containing document kind, remembered text, merchant or category, date, amount, and currency clues.

Application code bounds and sanitizes generated text; rejects prose, unknown fields, paths, URIs, SQL-like terms, wildcards, invalid ranges, and unsupported schema versions; reconciles only facts explicitly present in the user request; revalidates the final plan; and executes accepted plans through a safe repository API. If model setup or generation fails, deterministic local search remains available.

Arm optimization and measured output

The fixed planner matrix used 20 public synthetic cases on a Samsung Galaxy A57 / SM-A576B running Android 16 on Arm64, with LiteRT-LM 0.16.0 and a 2,588,147,712-byte Gemma 4 E2B container.

The GPU engine initialized, but all generation calls failed with LiteRtLmJniException, so no GPU speedup is claimed. The quality-passing CPU constrained-hybrid configuration became the production default.

A separate on-device Room/FTS benchmark seeded 10,000 synthetic documents. After three warmups and 25 recorded runs, retrieval measured 8.971 ms p50 and 12.069 ms p95, with the intended result ranked first for all three fixed queries.

The demo difference

On the same A57 in airplane mode, Samsung My Files returned no result for “gym membership around March.” SageSearch matched the camera-named synthetic receipt IMG_20260312_184522.png, showed stored match evidence, and opened the original. This is a controlled comparison using one device and one synthetic fixture, not a universal claim about every Android file manager.

Significant challenge-period update

Before the challenge, SageSearch was a Windows/LM Studio proof of concept plus a single-image Android OCR prototype. During the challenge it became a complete offline Android search system with persistent storage grants, resumable indexing, image/PDF OCR, Room/FTS retrieval, private model import, constrained on-device Gemma planning, cumulative refinement, factual evidence cards, device benchmarks, and an airplane-mode A/B demonstration.

How Codex helped

Codex helped turn the product interviews into a scope, PRD, technical specification, and verified build checklist; implemented and tested the Android architecture; challenged unnecessary RAG, embedding, fine-tuning, and deep-search scope; diagnosed an A57 bitmap-related force-close; iterated system-bar spacing and tap affordances from device feedback; and produced privacy-safe benchmark and submission evidence. Final product decisions and device approvals remained human-directed.

Build and test

Requirements: JDK 17, Android SDK 36, Python 3, and an Android 7.0/API 24 or newer Arm64 device.

1. Clone https://github.com/gitnyaDanil/SageSearch-Arm
2. Open the android directory or run: gradlew.bat testDebugUnitTest lintDebug assembleDebug assembleDebugAndroidTest
3. Install android/app/build/outputs/apk/debug/app-debug.apk
4. Approve the public sample receipt in artifacts/demo through Android’s picker
5. Obtain the documented compatible Gemma 4 E2B LiteRT-LM container separately and import it through Prepare AI model
6. Enable airplane mode and search: gym membership around March

Final verification includes 74 Android JVM tests, 9 Python evaluator/report tests, Android lint, debug assembly, APK installation, and the A57 10,000-document instrumented benchmark.

Privacy and limitations

The APK declares no Internet, broad-storage, or legacy external-storage read permission. Model, cache, database, and preferences are backup-excluded private app data. The approximately 2.6 GB model is not bundled. Planner evaluation uses a 20-case synthetic smoke set. End-to-end planning takes several seconds on the tested A57, while millisecond preliminary search preserves responsiveness. Android Storage Access Framework restrictions require explicit folder or file approval. No GPU speedup, NPU, battery-life, broad production accuracy, RAG, fine-tuning, post-training, or cloud-runtime claim is made.

Built With

• android
• gemma-4
• jetpack-compose
• kotlin
• litert-lm
• ml-kit
• room
• sqlite-fts4
• workmanager