Gemini Android: A Compose Chat Reference That Needs Two API Keys Before It Compiles
✨ Gemini Android demonstrates Google's Generative AI on Android with Stream Chat SDK for Compose.
At a glance
- What is it?
- GetStream's gemini-android is a Kotlin sample that wires Google's Generative AI into a Jetpack Compose chat UI backed by the Stream Chat SDK. It is a teaching repository, not a library, and its setup path runs through two third-party dashboards before the first build succeeds.
- Who is it for?
- Adopt gemini-android if you are building a Compose chat surface and want a working reference for how Stream's message layer sits next to Gemini calls, and you accept that the sample depends on a Stream account and a Google AI Studio key before it runs.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 69 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Gap This Sample Fills: Chat UI Plus a Model Call
Google's own Gemini quickstart for Android shows you how to send a prompt and read a response. It does not show you a message list, a composer, pagination, or anything that survives a process death. That is the gap gemini-android targets. The README frames the repository's purpose as demonstrating the Gemini API for Android, building the entire UI in Jetpack Compose, applying Jetpack architecture components such as Hilt and AppStartup, running background work with Kotlin Coroutines, and integrating chat through the Stream Chat Compose SDK for real-time event handling. Five bullets, one app. The intended reader is an Android developer who already knows Compose and wants to see how a generative model call fits inside an existing messaging stack rather than beside it. The secondary reader is anyone evaluating Stream's Compose SDK and wanting a non-trivial integration to read through. If you only need to call Gemini from a button press, this repository carries a lot of chat infrastructure you will never exercise.
Layered Kotlin: Compose Views Over Hilt-Injected Chat and AI Layers
The architecture is the standard modern Android arrangement, stated in the README as Jetpack libraries with Hilt for injection and AppStartup for initialisation, Kotlin Coroutines for background tasks, and the Stream Chat Compose SDK handling real-time events. In practice that means the UI layer is Compose functions, the chat state arrives from Stream's SDK rather than from a hand-rolled WebSocket client, and the Gemini call is another dependency the Hilt graph can hand to a view model. The data flow implied by the layout is: a user types into a Stream-backed composer, the message is persisted through Stream's channel, and the model interaction is a separate path that produces content the UI renders. What the repository does not claim to do is route every message through the model automatically, and the README gives no message-handling policy. Treat the Gemini integration as a feature inside a chat app, not as the chat app's brain. The README points to a companion blog post, Build an AI Chat Android App With Google's Generative AI, for the layer-by-layer explanation, which tells you the repository is meant to be read alongside prose rather than self-documenting.
Getting It to Build: secrets.properties, Two Keys, and a Disabled Auth Check
The build instructions are the most concrete part of the README and also the most demanding. You create a Stream account, open the dashboard, and click Create App. You copy the app Key, create a file named secrets.properties at the root of the Android project, and add STREAM_API_KEY=.. to it. Then, back in the dashboard's Overview menu, you find the Authentication category and switch on the Disable Auth Checks option, and in the Explorer tab you create a user with the name gemini and the ID gemini. Separately, you go to Google AI Studio, generate an API key, and add GEMINI_API_KEY=.. to the same secrets.properties file. Only then does the project build as intended. Two things stand out. First, the sample depends on two external services, so a contributor without a Stream trial and a Google account cannot run it at all. Second, Disable Auth Checks is a deliberate convenience for a demo and the README presents it as a step, not a warning. Anyone lifting this configuration into a real app is copying a shortcut, not a pattern. The README also gives no Gradle command, no wrapper invocation, and no note on what happens if either key is missing; the setup list simply ends.
Where the Sample Stops Being Useful
The repository is a demonstration, and the README says so directly in its stated purpose. That framing sets the ceiling. There is no published Maven artifact named in the material, so you cannot add gemini-android as a dependency; you clone it and read it or fork it. The release history is thin: 1.0.0 in January 2024 and 1.0.1 in August 2024, with the last push to the default branch much later, which means the tags do not describe the current code. The setup flow assumes a single hardcoded user identity, gemini, created by hand in the Stream dashboard, so there is no account system to study. And the auth configuration the README walks you through is the one you would have to replace first in any real deployment. The failure mode is quiet rather than loud: a developer follows the steps, gets a running demo, and then discovers that the parts they most need (token issuance, per-user identity, error handling when the model call fails) were never in scope. None of that is a defect in a sample. It is a mismatch if you arrived expecting a starting point for production chat.
The Alternative: Call the Gemini SDK Directly and Skip the Chat Stack
The honest comparison is not another sample repository; it is the Android quickstart on ai.google.dev that the README itself links to. That path gives you the Gemini client and nothing else: you construct the model, send a prompt, and render the result wherever you like. The difference in approach is ownership. With the quickstart you write your own state holder, your own list, your own persistence, and you decide whether messages are stored locally, in your backend, or not at all. With gemini-android you inherit Stream's channel model, its Compose UI components, its event handling, and its dashboard-based configuration, in exchange for a Stream account and a dependency on their SDK version cadence. If your app already uses Stream Chat, the sample shows you the seam between the two systems and that is worth reading. If it does not, adding a full chat SDK to get a prompt-and-response screen is a large amount of surface area for a small feature, and the quickstart will get you to a working call with one API key instead of two.
Licence, Upgrades, and What the Repository Does Not Tell You
The project is Apache-2.0, which permits commercial use, modification, and redistribution provided you keep the licence and notice files, and it includes a patent grant. That covers the code in this repository. It does not cover the services the code talks to. Your use of the Stream Chat SDK is governed by Stream's own terms and your app's plan, and your use of the Gemini API is governed by Google's terms and quota rules, neither of which the Apache-2.0 licence touches. On maintenance cost, the material supports only a limited reading: two releases, both in 2024, and a default branch that has moved since. A sample that tracks two fast-moving SDKs ages in two places at once, and there is no changelog in the supplied material describing how the maintainers handle a breaking change in either. There is also no stated minimum Android version beyond the API 21 badge in the README header, and no dependency version table. If you fork it, budget for the work of re-pinning both SDKs yourself. This is a description of the licence and the release record, not legal advice; read the Apache-2.0 text and the two vendors' terms before shipping anything derived from it.
Who Should Clone This, and What to Check First
Clone it if you are an Android developer comfortable with Compose and Hilt who wants to see a generative model call sitting inside a real chat surface, or if you are already on Stream Chat and want a worked example of the Compose SDK in a non-trivial app. Read it if you are deciding between building chat yourself and buying it; the setup steps are an honest preview of the operational weight that decision carries. Do not clone it expecting a library, a production auth pattern, or a maintained template for the current Gemini SDK. Before you invest a day in it, do three checks: open the Gradle files and compare the Gemini and Stream Compose SDK versions against the ai.google.dev Android quickstart and the getstream.io Compose documentation, confirm that the code on main still matches the setup steps in the README, and decide up front whether you are willing to run a Stream app with authentication enabled, since the README's Disable Auth Checks step is the first thing you will have to undo.
Editorial conclusion
Adopt gemini-android if you are building a Compose chat surface and want a working reference for how Stream's message layer sits next to Gemini calls, and you accept that the sample depends on a Stream account and a Google AI Studio key before it runs. Do not adopt it as a drop-in chat backend: it is a demonstration repository, not a published artifact, and the README's setup flow expects you to disable auth checks on a trial Stream app, which is not a production configuration. Before committing, verify the Gemini SDK version in the Gradle files against the current ai.google.dev quickstart, confirm the Stream Compose SDK version still matches the getstream.io Compose documentation, and check whether the two-year-old release tags reflect the code now on main.
Community notes