AICore Developer Preview Practical Guide: Why Android Teams Should Validate Gemma 4 On-Device AI Now

The first problem mobile app teams face when applying generative AI is not model quality, but operational reality. This is because cloud call costs, network delays, personal information processing, offline response, and device performance deviations are all intertwined. AICore Developer Preview is close to the first public testing ground for solving this problem in the direction of “verify it first on an Android device.” However, not all apps need to be installed right away. AICore-enabled devices, initial model maturity, and preview limits must also be considered.

1. One-line problem definition

Key takeaways: Android teams looking at on-device AI must now ask “which features should be moved to the device,” rather than “should we call the cloud?”

AICore Developer Preview allows you to download Gemma 4-based preview models to AICore-supported devices and test them directly. The scope of application is the initial verification stage of prompt accuracy, delay time, battery impact, and differences between devices. Conversely, large-scale commercial deployment, full Android device coverage, and firm performance guarantees are still beyond the scope of this preview.

2. First, conclusion

Key takeaways: If your app team values ​​privacy-sensitive features, offline UX, and low latency, it's worth starting verification now. Conversely, teams that prioritize broad terminal support are safer to enter after observation.

• Teams you need to join right now:Teams where offline or immediate response is important, such as keyboard assistance, summarization, post-processing after image OCR, field work apps, and local form filling assistance
• Teams that should only be piloted with caution:Teams where explainability and quality assurance are important, such as finance, healthcare, high-precision calculations, and legal documents
• Teams that are still better off waiting: Popular service apps where the range of supported devices is the most important, and judgment may be distorted by CPU execution experience without GPU/NPU optimization

3. Decomposition of core structure

Key takeaway: This preview should be understood as a combination of “AICore app + Prompt API + supporting hardware” rather than “the model itself”.

The structure has four major layers.

1. App Layer: Android app sends creation request to ML Kit Prompt API:
2. Runtime layer: AICore app provides preview model download, model selection, quota bypass option, and testing UI.
3. Model layer:Gemma 4 Use edge optimization models such as E2B and E4B. E2B is speed-oriented, E4B is inference quality-oriented.
4. Hardware layer: In devices that support AICore, you can expect optimization of Google, MediaTek, and Qualcomm AI accelerators, but in non-supported devices, it is risky to use it as a standard for final performance judgment because it is an early CPU implementation.

In other words, it is correct to view this preview not simply as “LLM running on Android”, but as a compatibility rail that prepares future Gemini Nano 4 compatible code in advance.

4. Description of design intent

Key takeaway: Instead of trying to get all teams to commercialize right away, Google chose to have them lock in prompts and UX first.

In the official announcement, Google explained that the code written for Gemma 4 was designed to work on Gemini Nano 4 devices in the future. The advantages of this approach are twofold. First, it allows Android teams to quickly experiment with local AI UX without cloud model contracts or server infrastructure. Second, it locks down the ecosystem in advance by maintaining the Prompt API-centric code structure even when the model changes.

Instead, it is clear that he gave up. We have given up on ensuring uniform performance across all devices, and during the preview period, features such as tool calling, structured output, system prompts, and thinking mode will be added in stages. That is, currentlyfinished productseeTesting center that adjusts the operation direction in advanceClose to .

5. Evidence and Comparison

Key summary: The current options are largely three: AICore preview, server call type LLM, and direct mounting of local open model.

Option	When is it advantageous	Advantages	Cost/Limitations
AICore Developer Preview + Gemma 4	When Android native teams quickly verify on-device UX	Offline capable, low latency, future Gemini Nano 4 compatibility, prompt verification speed	Supported devices limited, preview performance changes, some features incomplete
Cloud LLM API	When accuracy, versatility, and access to the latest model are more important	Less device restrictions, fast model update, stable quality	Call cost, network delay, personal information regulation burden, offline not possible
Direct bundling of local open models within the app	When special hardware or custom pipeline control is important	High runtime control, platform independence	Increased app size, deployment complexity, optimization cost, high maintenance difficulty

The judgment criteria can be summarized in one line as follows. If product experimentation speed and Android ecosystem compatibility are priorities, it is AICore, if highest accuracy and versatility are priorities, it is cloud, and if runtime control is priority, it is direct mounting.

Based on official data, Gemma 4 E2B is designed to be 3 times faster than E4B, and the new model aims to improve speed by up to 4 times and save battery by up to 60% compared to the previous version. However, since this is a description based on supported hardware, the CPU test results of non-supported devices should not be generalized as is.

6. Actual operation flow / step-by-step execution method

Key takeaways: The purpose of this preview is not deployment, but short cycle verification of “whether our features are suitable for on-device”

1. Check for supported devices
   First check whether your device is supported by AICore Developer Preview. If not supported, only the CPU path will be tested, which will distort the judgment.
2. Register for preview
   Follow the official instructions to participate in Google Group, register as an AICore beta tester, and complete the Android AICore (Beta) update on the Play Store.
3. Model download and code-free test
   AICore Download the preview model from the app and first enter the prompts to be used in the actual service. The first inference may take up to a minute due to model loading.
4. Prompt API code connection
   Only the preview track and model preference are attached separately in the app.

val previewFullConfig = generationConfig {
    modelConfig = ModelConfig {
        releaseTrack = ModelReleaseTrack.PREVIEW
        preference = ModelPreference.FULL
    }
}

val previewModel = GenerativeModel.getClient(previewFullConfig)
val previewModelStatus = previewModel.checkStatus()
if (previewModelStatus == FeatureStatus.AVAILABLE) {
val response = previewModel.generateContent("Summary the meeting minutes in 3 lines and return only the action items as a JSON array")
}

5. Compare both E2B and E4B
   Speed-oriented functions are measured separately by E2B and accuracy-oriented functions by E4B. You should not look at just one model to determine your overall strategy.
6. Leaves a failure log
   BUSY Error, first inference delay, model initialization time, battery consumption, terminal heat, and output fluctuation are recorded in a separate sheet.
7. Determine distribution standards in advance
   For example, criteria such as "Response within 3 seconds, JSON parsing success rate of 95% or more, 0 fatal errors during 10 repeated tests" must be present to distinguish the demo from the product. There is

7. Pitfalls

Key takeaway: On-device AI pilots often fail due to poor measurement methods rather than model quality.

• Pitfall 1. Misunderstanding CPU test results as end-user experience
  Prevention: Record AICore supported devices and non-supported devices separately. Recovery: Show “Accelerator Path/CPU Path” separately in performance report.
• Plot 2. Mixing the first inference delay with the average response time
  Prevention: Measure cold start and warm start separately. Recovery: After model loading is complete, measure again with repeated tests.
• Plot 3. Mistaking a BUSY error for a model quality problem
  Prevention: Check the quota bypass option and concurrent execution status in the preview document. Recovery: Clean up the test environment and measure repeated loads.
• Pit ​​4. Structuring prompts too late
  Prevention: From now on, also fix JSON return format, fallback statement on failure, and safety statement. Recovery: Create separate prompt contracts for each function.

8. Strengths and Limitations

Key takeaways: The real strength of this preview is less the low-latency AI itself, but the ability for the Android team to quickly explore product hypotheses without relying on the cloud.

• Strengths: Offline possibility, ease of personal information processing burden, future Gemini Nano 4 compatibility, Prompt API-centered development flow, expansion of multilingual and multimodal
• Limitations: Limited supported devices, possible feature changes during preview, skewed CPU path tests, lack of commercial SLA, quality deviation of high-level inference

My judgment is clear. This is not a signal to “all Android apps go to on-device AI right now,” but a signal to choose and experiment with only the right features first . In particular, text summarization, classification, structuring after OCR, and short on-site question and answering are candidates, but cloud assistance is still safer for long text generation and high-precision judgment.

9. Points to study more deeply

Key summary: This topic requires studying interfaces and operating conditions together rather than models.

• ML Kit Prompt API model selection method and future structured output support flow
• AICore Developer Preview support terminal conditions and quota bypass operation precautions
• Separation of roles from Gemma 4 E2B/E4B and upper 26B, 31B series
• How to treat cold start, memory footprint, and battery budget as performance KPIs in on-device AI
• Hybrid architecture that mixes local processing of sensitive data and server post-processing

10. Action Checklist + Author's Perspective

Key takeaways: If you don't nail the pilot success criteria first, even if the demo is awesome, the product won't stick.

• Have you created a test matrix that separates AICore supported and non-supported devices?
• Have you defined target functions and success criteria for each of E2B and E4B?
• Are cold start, warm start, and BUSY error rates recorded as separate indicators?
• Have you created a prompt contract with JSON output, failure response, and safety phrases?
• Is it clear why you choose “on-device instead of cloud” for privacy-sensitive features
• Have you prepared a fallback path for when there is a shortage of supported terminals?

Definition of Done: The three core scenarios must be measured repeatedly on at least two supported devices, passing the response time, error rate, and battery impact standards, and even the fallback must be verified.

Author's point of view: I think this is a preview that the Android native team must attach at least once in the first half of 2026. However, it should not be used as a standard for full distribution, but as a classifier that selects functions that can be released on-device. On the other hand, if it is a service where the range of terminal supply is the deciding factor, it is better to calculate the support range and operational complexity first rather than a flashy demo.

Reference material

• Announcing Gemma 4 in the AICore Developer Preview (Android Developers Blog, 2026-04-02)
• AICore Developer Preview program (Google Developers, confirmation date 2026-04-18)
• Gemma 4: Byte for byte, the most capable open models (Google Blog, 2026-04-02)