# Android: Gemini Nano, Firebase Hybrid and a Backend Proxy

Part 40 of the series "On-Device AI in Your App, Compared With External Models". Previous: [Part 39: Plug an External Model Into Apple's Foundation Models](https://sairamkotha.hashnode.dev/plug-external-model-into-apple-foundation-models).

On Android you have three paths to a model, and each one answers a different question. Gemini Nano through the ML Kit GenAI Prompt API keeps the request on the phone. Firebase AI Logic's hybrid API decides, per request, between the phone and a cloud Gemini model. A backend proxy lets you reach any other external model, including Claude, without putting its key in the app. This article shows how the three fit together, what each one costs the user and you, and what the privacy disclosure has to say. The disclosure part is where we found the least official guidance, and we say so below.

## Path 1: Gemini Nano through ML Kit

The ML Kit GenAI Prompt API is Google's route to Gemini Nano on Android. The model runs inside AICore, a system service that also downloads and updates it. Your app does not ship the weights.

Article 23 covered the limits. The part that matters for architecture is the model state. The Prompt API reports four states: AVAILABLE, DOWNLOADABLE, DOWNLOADING and UNAVAILABLE. A model that is not ready yet is normal, not an error. The first run on a new phone may begin with a download, so the feature needs a state for "not ready yet" as much as it needs a state for the reply.

The quota is the second thing to design for. AICore enforces a per-app inference quota. Too many requests in a short window return `BUSY`. Google suggests exponential backoff. A longer quota can refuse with a battery-use error. Your app should treat `BUSY` as a retry-later result, and show the user something other than a spinner that never ends.

Use this path when the data must stay on the phone and the device list covers your users. The device list is the catch. Direct model access is limited to listed devices, and the list changes by model family. Check it against your own user base, not against the phone on your desk.

## Path 2: Firebase AI Logic hybrid inference

Firebase's hybrid API is a routing layer. You create one model, you choose a mode, and the SDK decides, per request, where the work runs. The on-device side uses the ML Kit Prompt API. The cloud side uses the Gemini models that Firebase AI Logic serves.

The Firebase configuration page lists four modes. The table is the main thing to get right before you ship.

| Mode | Where it runs | If the preferred path fails |
| --- | --- | --- |
| `PREFER_ON_DEVICE` | Phone if the model is available and supports the request | Logs an on-device error, then falls back to the cloud model |
| `ONLY_ON_DEVICE` | Phone only | Throws an exception |
| `PREFER_IN_CLOUD` | Cloud when online and the model is available | Falls back to the phone when offline; throws for other failures |
| `ONLY_IN_CLOUD` | Cloud only | Throws an exception |

Two things in the table change how you build. First, `PREFER_ON_DEVICE` does not fail silently: the SDK logs the on-device error before it falls back. Your logs will show the fallback, so set up your alerting to read it. Second, `PREFER_IN_CLOUD` is the reverse of the mode most teams expect, and it does not mean "keep it private". Use it when cloud quality matters more than the phone path.

Each mode also needs a named cloud model. The SDK has no default for the three modes that can reach the cloud, so you must set one explicitly. Some modes accept an optional on-device model category. The Firebase page gives Gemini Nano 4 Fast (Preview) as one example, based on Gemma 4 E2B. Treat it as a preview name that can change.

To learn which path served a request, read the response's `inferenceSource` attribute. It returns `ON_DEVICE` or `IN_CLOUD`. Log that value, and never log the prompt. Article 41 uses it to answer "which model answered this request?" without storing user text.

The hybrid API is marked experimental. A search summary attributed that status to the Android Developers Blog post from April 2026; we did not open the post. Check the current status and the exact mode names on the Firebase configuration page before you build.

### Choosing the mode

Pick the mode from the feature's data policy, not from the quality you hope for:

- **Private text, phone only:** `ONLY_ON_DEVICE`. Your code must catch the exception on every call. A missing model is then a UI state, not a crash.
- **Private text, fallback allowed when the phone cannot serve it:** `PREFER_ON_DEVICE`. Only use this if the feature's consent covers the cloud path for that input. The fallback sends the input to the cloud.
- **Quality first, phone as the offline backup:** `PREFER_IN_CLOUD`.
- **Cloud only:** `ONLY_IN_CLOUD`. Use it when the phone path is not allowed or not useful.

The rule from article 37 holds here. Decide the fallback before you ship. A mode that silently moves private text to the cloud is a policy decision, not a tuning knob.

## Path 3: A backend proxy for any other model

For any model that is not Gemini Nano or Gemini in Firebase, the call goes through a server you control. The app authenticates the user to your backend. Your backend holds the provider key, calls the model, applies the rate limits and cost caps, and logs usage without logging the prompt.

This is the safe pattern for a key you pay for. A key compiled into the APK can be pulled out with ordinary tools. The proxy is also where you put the consent check. If the user has not agreed to send a feature's data to a provider, the request never leaves your server.

The proxy adds a network hop. Measure the added latency before you promise a time to first token. Article 38 shows how to put that number next to the on-device number.

## Disclosures: what the Play Console asks

The privacy disclosure is where we found the least official guidance, so this section stays short and says what we could not confirm.

What we could confirm is the principle. On-device inference does not remove the obligation to declare what data the app handles. A cloud fallback is a separate path, and the user should know which provider receives their data. Some developer guidance also warns against calling an integration private before you have checked whether it sends telemetry.

What we could not confirm is the current wording of Play's Data safety form for on-device AI with cloud fallback. We did not find a Play policy page that addresses this case directly. Before you submit, read the Data safety help page in the Play Console and the policy pages it links to. Then check each data type your fallback path sends against the form.

Practical steps that do not depend on that wording:

- List each path the feature can take: phone only, cloud fallback, or cloud only.
- For each path, list the data that leaves the phone. Include instructions, conversation history and any tool output.
- Write the consent screen for the cloud path in the same words as the policy.
- Keep a record of the mode each user's feature was set to, so you can answer a support request later.

## What to test

- **Model states.** Force each of the four states on a test device and check that the UI does something sensible for each.
- **Quota.** Send a burst of requests and confirm the app backs off on `BUSY` and recovers.
- **Fallback.** On `PREFER_ON_DEVICE`, use a device without the model and confirm the request succeeds in the cloud and the log shows it.
- **Exception paths.** On `ONLY_ON_DEVICE`, use the same device and confirm the exception is handled and shown as a state.
- **Proxy.** Confirm the provider key does not appear in the APK or in logs. Decompile a release build and search for the key format.

## What I could not verify

- **Current Firebase mode names and status** at the time you ship. We saw the Firebase configuration page only through search summaries of its localized versions. Check the English page first.
- **Gemini Nano 4 Fast** as a category name. It is labelled Preview on the Firebase page, and the name may change.
- **Play Data safety wording** for cloud fallback. Not found in official text.
- **Device list coverage** for your users. It depends on your own device mix.

#AndroidDev #OnDeviceAI #FirebaseAI #GeminiNano #MobileAI

---

**Work with me:** I take 1:1 calls on mobile architecture, on-device vs cloud AI decisions and startup tech consults. Start with a [free 10-minute intro call](https://topmate.io/sairamkotha/2339352), or book a [Mobile Architecture Review](https://topmate.io/sairamkotha/66762). All options: [topmate.io/sairamkotha](https://topmate.io/sairamkotha)