What this prompt does
This prompt integrates Gemini Nano for on-device AI in an Android app, where privacy and offline support rule out sending user data to the cloud. It runs through six steps: setting up the environment and capability checks, implementing on-device features, designing an offline-first architecture, handling data privacy, building adaptive model loading, and monitoring performance. Because Gemini Nano's memory, latency, and availability constraints are real, a graceful fallback is non-negotiable rather than an afterthought.
The variables shape the integration. [min_api_level] and [ai_core_dependency] set up the environment, [fallback_strategy] covers unsupported devices, and [feature_count] plus [feature_list] define what runs on-device. [temperature] and [top_k] tune output, [benchmark_device] and [max_latency] set performance targets, [local_storage] and [min_ram] plus [idle_timeout] manage resources, and [compliance_framework] and [analytics_platform] govern privacy and monitoring. The fallback strategy is the value that decides what happens on the many devices where Nano simply isn't available, so it shapes the whole architecture rather than sitting at the edge. The privacy guarantees follow from the same constraint: keeping inference on-device is what lets you promise that user data never reaches a server.
When to use it
- You want AI features that work offline and never send user data to the cloud.
- You are building on Android with Gemini Nano and need device-capability checks.
- You need a graceful fallback when Gemini Nano is unavailable on a device.
- You want on-device features like summarization or smart replies with bounded latency.
- You need a privacy-by-design data flow for
[compliance_framework]compliance. - You want adaptive model loading that respects memory and battery constraints.
Example output
Expect environment setup with [ai_core_dependency] and isAvailable() capability checks, plus a degradation strategy to [fallback_strategy] and a list of supported device tiers. The feature step produces [feature_count] on-device features from [feature_list] configured with [temperature] and [top_k]. From there you get an offline-first architecture with a request queue and [min_ram] monitoring, a privacy-by-design data-flow document for [compliance_framework], lazy model loading with an [idle_timeout] unload, and a privacy-respecting performance dashboard reported via [analytics_platform]. It blends setup, architecture, and code, with the offline-first and fallback paths designed so the features keep working regardless of connectivity or device capability.
Pro tips
- Always check
isAvailable()and design the[fallback_strategy]first; Gemini Nano isn't on every device meeting[min_api_level]. - Keep
[temperature]and[top_k]low for consistent on-device results, since user-facing features benefit from predictability. - Benchmark each feature on
[benchmark_device]against[max_latency]; on-device inference latency varies widely by hardware. - Load the model lazily and unload after
[idle_timeout]to respect[min_ram]; keeping it resident drains memory and battery. - Keep all data on-device and exclude prompt and response content from
[analytics_platform]telemetry to honor the privacy-first design. - Pre-load the model only when charging and on Wi-Fi so warm-up never hurts the user's battery during normal use.
