News
Google Shows How Android Apps Split AI Between Cloud and Device
Google’s latest Android developer guidance uses the Jetpacker sample app to show how cloud, on-device and hybrid AI can work together.
Google has published a new technical update explaining how Android developers can divide artificial-intelligence workloads between the device, the cloud or both. The Android Developers Blog post, published on July 21, uses Jetpacker, an open-source travel application, to demonstrate the practical trade-offs behind modern AI features.
The guidance is aimed at developers building intelligent Android applications rather than consumers waiting for a new system update. Its central message is that there is no single best place to run every model. Cloud processing can provide broader knowledge and larger context windows, while on-device inference can reduce latency, limit data transfers and keep selected features working without an internet connection. Hybrid inference is presented as the way to combine those advantages when compatibility and operating costs also matter.
One sample app, three different AI strategies
Jetpacker is designed to help users plan and manage trips. Google uses the app to show how the same product can use different AI architectures depending on the job. Features that handle private information or relatively simple tasks can run locally, while requests needing current information or more complex reasoning can be sent to cloud models.
The first example is a museum assistant. A local model may not know the latest exhibition schedule, ticket rules or opening hours, so Jetpacker uses Firebase AI Logic with grounding tools. The sample can add information from a specific webpage, Google Search or Google Maps to the model’s context before generating an answer. That approach is intended to make responses more relevant to a particular place and more useful for questions whose answers can change over time.
Google’s example also illustrates an important limitation: grounding does not remove the need for developers to choose reliable sources and design suitable checks. A model can only work with the context it receives, so app teams still need to decide which websites, maps data or other services should be trusted before presenting an answer to users.
Hybrid inference keeps local processing in the loop
The second example is a restaurant-review feature. Jetpacker tries to generate a draft review on the device using Gemini Nano, then falls back to a cloud model on devices that do not support the required local capability. Google describes this as a way to make a feature available across a broader Android device base without giving up the potential privacy and cost advantages of local execution.
The Firebase Hybrid Inference API supports four routing choices: PREFER_ON_DEVICE, PREFER_IN_CLOUD, ONLY_ON_DEVICE and ONLY_IN_CLOUD. In the Jetpacker example, the application prefers local processing but can use the cloud as a fallback. Developers can choose a stricter mode when a feature must stay local, or prioritize the cloud when richer reasoning is more important than offline availability.
That decision has direct consequences for the user experience. Local inference can reduce network dependence, but it depends on compatible hardware, model availability and device resources. Cloud inference can support more capable models, but it introduces connectivity requirements and may increase latency or operating costs. A hybrid route gives developers another option, provided the app clearly handles changes in network status and model availability.
Translation shows why routing may need custom rules
Jetpacker’s hotel-support chat demonstrates a more complex arrangement. The app first identifies the language of an incoming message with ML Kit. It then routes selected language pairs to an on-device model and sends other cases to a cloud model. The sample uses custom logic rather than a single universal rule, allowing the app to consider language, device support and the needs of the conversation.
This is useful for international apps because translation quality, model support and privacy requirements can vary by language. A developer might keep common language pairs on the device while sending less-supported combinations to a cloud service. Google’s sample shows the mechanism, but it does not claim that every language or device will produce identical results. Teams still need to evaluate their own supported languages and define what happens when a model cannot respond confidently.
The post also highlights the security work required when an Android app sends AI requests to the cloud. Jetpacker integrates Firebase App Check with Play Integrity for production requests and uses a debug provider during local development. Google’s sample initializes anonymous authentication as part of the app’s pipeline. These controls are intended to help limit unauthorized API use and reduce the risk of unexpected billing or abuse.
What this means for Android developers
Google’s update is less about launching a single new feature than about giving developers a decision framework. Teams can begin with the user’s data and the task’s requirements: sensitive documents may favor on-device processing, current local information may require grounding, and broad device compatibility may benefit from a cloud fallback.
The approach also encourages developers to expose failure states honestly. If a device lacks Gemini Nano, the app should make its fallback behavior predictable. If a request needs cloud access, the interface should account for offline use, delays and consent. If a model drafts text or translates a message, users should be able to review the result before sharing it.
For Android users, the practical outcome may be less visible than a redesigned interface. The same app could respond faster in one situation, work offline in another and consult current web or map information when necessary. Those improvements depend on careful routing, source selection and security controls rather than on AI branding alone. Google’s Jetpacker sample offers a concrete reference for developers who want to build that balance into their own applications.