Offline AI Features and Device Compatibility

Android runs on thousands of device models. An AI feature has to answer three questions at runtime: can this device run the model, is the model present, and is the network available if we need the cloud? The answers decide which experience the user gets.

Tiered experiences

Detect capability

data class AiCapabilities(
    val onDevice: OnDeviceStatus,
    val online: Boolean,
    val lowRam: Boolean,
)

enum class OnDeviceStatus { AVAILABLE, DOWNLOADABLE, DOWNLOADING, UNAVAILABLE }

class CapabilityChecker(
    private val context: Context,
    private val summarizer: OnDeviceSummarizer,      // wraps ML Kit GenAI checkFeatureStatus()
) {
    suspend fun check(): AiCapabilities {
        val am = context.getSystemService(ActivityManager::class.java)
        val cm = context.getSystemService(ConnectivityManager::class.java)
        val caps = cm.getNetworkCapabilities(cm.activeNetwork)
        return AiCapabilities(
            onDevice = summarizer.status(),
            online = caps?.hasCapability(NetworkCapabilities.NET_CAPABILITY_VALIDATED) == true,
            lowRam = am.isLowRamDevice,
        )
    }
}

For Gemini Nano, always use the API's own status check (ML Kit GenAI's checkFeatureStatus()) instead of hard-coding device lists. Supported devices change over time.

Model downloads

• Download only when the user is likely to use the feature, preferably on unmetered networks.
• Show progress and size, and allow cancel.
• Handle storage-full and interrupted downloads, and verify checksums for your own model files.
• Use WorkManager for large downloads with constraints. See WorkManager.

Gating your own models

Designing for offline

• On-device first for features users need anywhere (dictation, translation, OCR).
• Queue cloud requests for non-urgent work (summarise later) and notify when done.
• Be explicit in UI: "Summaries need internet on this device" is better than a spinner that fails.

suspend fun summarize(text: String): SummaryResult {
    val caps = capabilityChecker.check()
    return when {
        caps.onDevice == OnDeviceStatus.AVAILABLE && text.length < ON_DEVICE_CHAR_LIMIT ->
            SummaryResult.Ok(onDevice.summarize(text), source = Source.ON_DEVICE)
        caps.online && settings.cloudAllowed ->
            SummaryResult.Ok(cloud.summarize(text), source = Source.CLOUD)
        else -> SummaryResult.Unavailable(reason = if (!caps.online) "offline" else "not supported")
    }
}

Testing across devices

• Test on at least one low-end and one mid-range device, not just flagships.
• Test airplane mode, flaky networks and low storage.
• Use Firebase Test Lab or device farms for broad coverage.
• Log tier selection (without content) to see real-world availability. See Monitoring AI.

Frequently asked questions

Conclusion

Design AI features in tiers: on-device when available, cloud when online and allowed, and a non-AI fallback otherwise. Detect capability with official status APIs, download models carefully, and test on real low-end devices and offline.

Next step: integrate other cloud providers safely with OpenAI API Integration Patterns for Android.