Offline Image Batch Processing on Android

Direct answer

An image batch is a workflow of individually identifiable tasks. A good test does not reduce the whole set to one spinner and one final success message. Each input should retain an identity and a visible state such as queued, active, completed, skipped, rejected, cancelled, or failed. If one file is malformed, the app should not silently erase earlier results or mark every item successful. MEMORY-01 and COVE-OCR-01 support treating task resources and image-text work as measurable stages, but they do not claim Cove supports batch processing or any fixed number of images. Scope the test around a route the user actually chose: photo picker, document URI, in-app camera, or a deliberate imported copy. These routes differ in grants and lifetime. Treat import, header inspection, decode, transformation, inference, result review, persistence, and export as separate events. A batch may combine OCR and image understanding, but the task label and evaluation must identify which pipeline ran for each item. This prevents a readable caption or parsed text from being substituted for another task's acceptance result. The main risk in a batch is often state and resource multiplication. Android bitmap guidance explains that decoded pixels may occupy far more memory than compressed files and that multiple retained or concurrently decoded bitmaps can create pressure. That is a reason to instrument a target implementation, not to invent a safe batch-size threshold. Record how many items are in flight, when source streams close, how transformed images are released, and which runtime session owns active work. Measurements must name the exact build and device; do not turn an example calculation from platform documentation into Cove's capacity claim. Prepare a manifest before the run. Give every image a stable ID and expected class. Include ordinary, rotated, oversized, corrupt, duplicate, unsupported, and empty inputs, and include cancellation points between and during items. Synthetic or explicitly authorized images make diagnostics safer. Fix the expected classifications and any source-derived required fields before observing model output. Store the fixture revision and transformations so that a later run is comparable. If the user can reorder selections, verify the app maps results by identity rather than by the current list index. Define whether progress is ephemeral or durable. A foreground flow that loses work when the app closes should say so and should offer a safe restart path; it must not claim resumability. A durable worker requires its own process-recreation and cancellation tests, including URI permission lifetime for every selected item. The test should differentiate batch cancellation from item failure and user removal. Cancellation is best effort in some Android work APIs, so inspect the actual worker, decoder, and inference lifecycle rather than assuming the button stopped native work. Record a per-item audit trail with stage start and finish, failure category, output availability, review state, and whether the source remains accessible. Keep raw photo bytes and recognized text out of ordinary analytics and crash logs. Preview thumbnails, intermediate crops, OCR strings, and generated outputs are derived user data too; check where they live and what delete means. A user may ask to remove one image but keep other completed items, so deletion tests should be item-scoped. Evaluate correctness as well as lifecycle. For each fixture, compare output with a prewritten expected class or field set. Do not grade a batch only by the last visible result, and do not average away failed images. Separate recognition correctness from successful queue completion, and separate both from any latency or memory measurement. If a retry produces a new result, preserve its relationship to the earlier attempt so a reviewed output is not overwritten without disclosure. The report should explain the queue policy, item-state model, tested interruption points, resource observations, output review, and known exclusions. It may describe this fixture batch and build. It cannot assert universal compatibility, offline readiness, performance, privacy, or maximum capacity from a small run. A careful batch test is useful precisely because it reports partial outcomes and uncertainty instead of presenting a multi-image feature as more reliable than the evidence supports.

A field worker reviews several inspection images

A field worker selects a fixed set of authorized inspection images before entering a location with no expected network access. One input is corrupt and another may be removed after review. The worker needs item-level results, a visible batch state, and a safe way to resume or restart if the app process stops.

Decision

Use a stable manifest and separate item outcomes from batch state; test the selected URI grants and process interruption instead of assuming every image stays available.

Expected outcome

The test shows which items completed, failed, were removed, or need retry without losing prior reviewed results.

Evidence to collect

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

• Batch-size policy
• Per-item result record
• Sustained memory timeline

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

Implementation workflow

1. Freeze the item manifest. Assign stable IDs and expected classes to valid, rotated, large, corrupt, duplicate, and empty inputs. Record the source route and any authorized transformations.
2. Observe stages and ownership. Record import, decode, preprocessing, inference, persistence, and review separately, including active item count and release of streams, bitmaps, and runtime work.
3. Inject item failures and user removal. Fail one decode, reject one unsupported item, and remove another after selection. Confirm each transition remains attached to the correct source identity.
4. Interrupt and cancel the batch. Cancel before and during work, recreate the process, and test any claimed durable worker. Verify actual decoder or inference termination and selected-URI access.
5. Review retention and retry behavior. Retry one failed item, compare attempts without overwriting a reviewed result, and delete one source. Check previews and derived text follow the stated policy.

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

Acceptance criteria

• Every input has a stable identity and explicit terminal or in-progress state; batch success cannot hide failed, cancelled, removed, or skipped items.
• Interruption and cancellation outcomes are reproduced and the report does not claim resumability unless process-death tests pass.
• The report separates task correctness, queue completion, and measured resource behavior and makes no universal capacity or performance claim.

Decision table

Failure patterns to prevent

• Decoding the whole batch at once
• Losing all progress after one failure

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 bitmap handling guidance
• Android memory and bitmap guidance
• Android WorkManager cancellation reference

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

Frequently asked questions