Actualité
Google’s Jetpacker shows how Android apps can split AI between phone and cloud
Google’s open-source Jetpacker sample demonstrates how Android developers can combine on-device AI, cloud models and system integrations in one mobile app.
Google’s Android Developers team is using Jetpacker to show how the next generation of Android applications can divide artificial-intelligence work between the phone, the cloud and the operating system. The travel-planning sample is not a consumer product launch or a benchmark: it is an open-source technical showcase designed to help developers understand the architectural choices behind intelligent mobile apps.
Jetpacker brings together trip planning, itineraries, flight and hotel details, expense tracking, voice notes and travel assistance. Google says the project was built from the ground up for Google I/O and is now available in the Android AI Samples repository. Its value is less about the travel theme than the way each feature is routed to the most suitable type of model.
Local processing for private, lightweight tasks
Three Jetpacker features are designed to run on the device. A trip overview turns a multi-day itinerary into a shorter, actionable summary using Gemini Nano through the ML Kit GenAI APIs. An expense tracker extracts structured information from receipt images, while an audio diary records, transcribes and categorises voice notes using ML Kit Speech Recognition and GenAI Prompt APIs.
This approach is useful when an app needs to work with sensitive or personal information. Google’s description says local inference avoids additional cloud inference costs and allows information such as receipt images to be processed without leaving the device. It can also reduce dependence on a live connection, although the actual availability of Gemini Nano depends on the device and its configuration.
That last point matters for developers. Google’s Prompt API documentation requires apps to check whether Gemini Nano is available, downloadable, still downloading or unavailable. The documentation also labels the API as beta, so developers must build a fallback path and avoid treating local generative AI as a universal capability.
Cloud and hybrid models fill the gaps
Not every mobile feature can be handled locally. Jetpacker’s place question-and-answer feature needs broader knowledge about real-world locations, so it uses Firebase AI Logic with Google Maps and web context. That design lets the app ground answers in current location information instead of relying only on a compact model stored on a handset.
The sample also demonstrates hybrid inference for drafting reviews. A local model can handle the task when the required capability is available, while a cloud model acts as a fallback for other users. The project applies a similar principle to live hotel-chat translation, using custom routing between on-device and online processing.
This split gives developers a practical decision framework. A short summary, a receipt extraction task or a voice note can be handled locally when privacy, offline operation and predictable costs are important. A location assistant or a more demanding language task may justify cloud processing when it needs larger context or wider world knowledge. The architecture does not assume that one model should handle every request.
Connecting an app to Android intelligence
Jetpacker goes beyond in-app features through Android’s AppFunctions API. The sample exposes structured travel actions and data queries so the Android intelligence system can work with trips, itineraries, expenses and voice notes. In practical terms, the app can describe capabilities that the system may discover and invoke, rather than keeping every action locked inside its own interface.
The project also previews an agentic booking assistant. Google describes a workflow that can coordinate flight reservations while asking the user for input before a final booking. The assistant runs in the cloud and uses A2UI and ADK, so it should be read as a demonstration of an emerging architecture rather than a promise that every Android app will automatically gain autonomous booking.
Why the sample matters for mobile developers
Jetpacker’s most important message is about boundaries. Mobile AI is becoming a routing problem: developers must decide what belongs on the device, what needs a cloud model and what should be exposed to the operating system. Those decisions affect privacy, responsiveness, connectivity, cost and the range of devices an app can support.
The open-source project gives teams a concrete starting point for examining those trade-offs. Its codebase combines modern Android architecture with ML Kit GenAI, Firebase AI Logic and AppFunctions, while the accompanying Google series explains the individual pieces in more detail. Developers can study the implementation, compare local and remote paths, and adapt the pattern to their own use cases without presenting a technical demo as a finished consumer service.
For users, the broader consequence is that future Android apps may feel more helpful without sending every piece of personal data to a server. For developers, the requirement is more demanding: each intelligent feature needs an explicit data path, a capability check and a fallback when the preferred model is unavailable. Jetpacker makes that design discipline visible in one mobile application.