Device readiness guide
A model file size, chipset name, or Android version cannot answer that alone. Check the exact app build, model artifact, runtime, task, and recovery path on the device you plan to use.
The Android modules in this repository declare minSdk 31. This is a build configuration: it sets a minimum Android API level for installing the app build. It is not a measured list of supported phone models, a RAM requirement, or a performance promise. Android's own documentation describes minSdk as an app's minimum API level and separates that setting from hardware feature requirements and broader device compatibility.
Android 12 corresponds to API level 31. That mapping helps identify the operating-system boundary; it does not say that a device at API 31 can load a particular model or finish a task reliably.
A previous version of this page named eight phones, gave inference times, and labeled device classes incompatible. The underlying per-device run records are not available in the repository, so those claims are withdrawn. No public device support matrix, minimum RAM threshold, chip-family recommendation, or speed figure is asserted here. A build requirement is not the same as a tested compatibility verdict.
systemRequirements.sources.minSdk · systemRequirements.sources.api · systemRequirements.sources.compatibility
Device readiness is task-specific. A phone might install an app but fail while loading a model, opening the camera, processing a long prompt, or recovering after the app is interrupted. Instead of asking whether a phone is simply “compatible,” describe one job you need it to finish and test the full path on that exact phone.
Example: on a particular Android phone, open the exact app build, load the intended local model, analyze a synthetic receipt image while offline, show a readable result, then repeat after closing and reopening the app. This example defines a test; it does not claim that a Cove release or model has passed it on any named device.
Keep the test modest, privacy-safe, and repeatable. Change one variable at a time, record failures as well as successes, and do not turn one successful run into a promise about other phones.
Write down the phone manufacturer and exact model, Android version and build, free storage, app version, and date. Record whether the build came from a development install or the official distribution channel. The Android API level can establish whether the operating-system floor is met, but device model names alone do not establish hardware behavior. Keep this identity with every later result so that a firmware or app update does not silently change the test subject.
Install the exact build you intend to evaluate and note any store filtering, package error, permission prompt, or first-run setup. An app that installs has passed only the installation check. It has not yet demonstrated that its model downloads, that enough memory is available, or that camera, speech, or another task works. Do not bypass a failed install by changing device settings and then report the original setup as a pass.
Identify the model file and runtime version, complete any required download while connected, and record the file identity or checksum when the publisher provides one. Distinguish download size from installed storage and working memory: temporary files, updates, runtime buffers, and other apps can affect the device differently. Leave enough room for ordinary phone use, but do not invent a universal storage allowance. If the app cannot report setup completion, record that uncertainty.
Choose one harmless input with a known expected result, such as a synthetic note or sample image. Specify language, image dimensions or prompt length, expected output, and a clear pass condition before running. Close unrelated heavy apps only if that reflects how you will actually use the phone; record the choice. Capture free memory before and during the task with a repeatable system tool. Total installed RAM by itself does not tell you the memory available to this process.
Start from the screen a normal user would open, wait for model initialization, perform the task, inspect the output, and note the elapsed time and any visible errors. Separate cold start from a later warm run. If the task has stages—camera permission, image capture, recognition, inference, display—note where it stops. Do not compare speed unless the artifact, app build, runtime, input, output limit, device state, and timing method are held constant.
Close or background the app at a safe point, reopen it, and repeat the same task. If offline behavior matters, disconnect only after preparation and begin a fresh session; do not count a cached answer. Record whether the app resumes, requests a download, loses progress, or explains recovery. Run enough repetitions to expose inconsistent failures, but report the number and conditions rather than calling a small sample a universal benchmark.
These criteria turn “it seems fine” into an auditable decision. Set task-specific thresholds before the run. The page does not supply a universal pass threshold for response time, memory, heat, or battery.
A useful compatibility review connects each claim to the evidence that could support it. The same phone can pass installation and fail a memory-heavy task; results can also change with a different model file or app build.
| Dimension | What configuration can tell you | Evidence needed for a verdict | Your check |
|---|---|---|---|
| Android build floor | The project declares minSdk 31. | Install result for the exact package and OS build. | Record Android version and install outcome. |
| Model artifact | A model name or published file size identifies only part of the setup. | Exact artifact identity, runtime, load result, and memory observations. | Record file identity and whether initialization completed. |
| Phone resources | RAM, storage, and chipset labels are not task results. | Observed memory, storage, errors, and sustained behavior on the phone. | Measure the actual run and note background conditions. |
| User workflow | A supported API or component does not prove an end-to-end feature. | A fresh input completes every required stage and meets a task rubric. | Repeat the defined workflow, including recovery. |
Keep the evidence at the same level as the claim. One exact phone and one fixed scenario can support a statement about that run. A general compatibility list requires reproducible runs across named software and hardware configurations, with raw records and a stated pass rule.
No. It is the minimum Android API level declared by the app build. It does not certify every phone on that OS, a model's memory fit, a hardware accelerator, or successful completion of a task. Check the exact package and device, then run the workflow you care about.
This page does not publish a numeric minimum because there is no validated device-run dataset here to support one. Model weights are only one part of memory use; runtime buffers, input size, output length, other apps, and the operating system also matter. Measure peak use on the exact build and task.
No chip-family threshold is asserted here. A chipset or NPU label does not prove that the selected app runtime uses that accelerator or that the task meets quality and responsiveness needs. Test the exact artifact and runtime on your device, and record the execution path when it is observable.
There is no defensible universal time in this guide. Response time depends on the exact model artifact, app and runtime versions, accelerator path, input and output sizes, device state, and measurement method. If speed matters, define an acceptable limit before testing and report the raw repetitions with those conditions.
For each listed setup, retain the exact phone and OS build, app build, model artifact, runtime and backend, task fixture, measurement method, repetitions, errors, and pass rule. Publish the scope and date, preserve failed runs, and rerun after material changes. Until that evidence exists, treat compatibility as unknown rather than inferred from a chip name.
A successful test is narrow evidence: this build, artifact, phone, operating-system version, task, and date completed the recorded workflow. If any of those change, reassess. If the test fails, keep the failure stage and message; it is more useful than a broad unsupported verdict.
Learn how on-device AI works · See a camera task under difficult conditions
Factual review: Cove content team, 2026-09-27. Chinese owner review is pending; localized copy is not represented as owner-approved.
