Gemini Android by GetStream: a Kotlin reference app for Gemini plus Stream Chat

The gap Gemini Android is meant to fill

Most Android chat samples stop at a list of messages. This repository goes one step further: it puts a generative model on the other side of the conversation. According to the README, the purpose is to demonstrate the Gemini API for Android, implement the entire UI with Jetpack Compose, apply Android architecture components including Hilt and AppStartup, run background work with Kotlin Coroutines, and integrate Stream Chat Compose SDK for real-time event handling. That list is the whole scope. It is a teaching artifact published by Stream, and the README routes readers to a companion blog post titled "Build an AI Chat Android App With Google's Generative AI" for the architecture discussion.

The audience is therefore narrow and specific. You are an Android developer who already knows Compose and wants to see how a model call is threaded into a message list. You are not a product team looking for a drop-in assistant, and you are not someone who wants a packaged SDK. Nothing in the README describes a reusable library artifact, a Maven coordinate, or a public API surface. What you get is an application module tree: app/, core/, feature/, build-logic/, buildSrc/, and a baseline-profile/ directory, plus a spotless/ folder for formatting configuration. That layout tells you the authors care about modularity and build hygiene, and it also tells you the code is meant to be read and forked rather than depended on.

How the pieces fit: Compose UI, Hilt, coroutines, Stream

The data flow implied by the README is a chat loop. Stream Chat Compose SDK handles messaging and real-time event handling, so message delivery, presence and the conversation list come from Stream rather than from anything this repository implements. The Gemini API handles generation. Kotlin Coroutines carry the background work, which is where the model call and any Stream network activity would sit so the main thread stays free. Hilt supplies dependency injection across the modules, and AppStartup handles initialization ordering at process start.

Two consequences follow from that arrangement. First, the repository is a client-side integration sample: there is no server component described, which means the Gemini API key lives in the app's build configuration. The README has you put it in a file named secrets.properties at the project root, and the repository ships a secrets.defaults.properties alongside it, which is the conventional pattern for keeping real keys out of version control. Second, because Stream owns the messaging layer, the interesting code in this project is the seam between a Stream message and a Gemini request. If you are evaluating the repository, that seam is what to read first; the rest is standard Compose and Hilt wiring that you have seen before.

Building Gemini Android: two keys and a Stream user

The build steps are entirely about credentials. The README says to sign up on the Stream login page, create an app from the dashboard, and copy the key it shows you. Then create a file named secrets.properties in the root directory of the Android project and add the key.

STREAM_API_KEY=..

Next, the README instructs you to open the app in the Stream dashboard, find the Authentication category under Overview, and switch on Disable Auth Checks before submitting. That setting is what lets the sample talk to Stream without a token server, and it is a development convenience, not something to carry into production.

Still in the dashboard, open the Explorer tab, go to users, click Create New User, and create a user named gemini with the ID gemini. The README uses that exact name and ID, and the sample expects it to exist.

The second key comes from Google. Go to Google AI Studio, sign in with a Google account, and select Get API key. Add the result to the same file.

GEMINI_API_KEY=..

With both entries in secrets.properties, the project is ready to build from Android Studio. The README does not document a command-line build, a rollback path, or what happens when a key is missing, so expect the failure to surface at runtime rather than at configuration time. The README also does not state which Gradle task or wrapper invocation to use, even though gradlew and gradlew.bat are present in the repository root.

Where this repository stops being the right answer

The most concrete limitation is the auth setting. Disable Auth Checks is a dashboard toggle that the README asks you to turn on so the sample can run without a backend issuing Stream tokens. Any real deployment needs token issuance, and the README does not cover that path. If you copy the sample's networking setup into an app that faces users, you are copying the part the sample deliberately skipped.

A second limitation is that this is a demonstration repository, not a maintained library. The newest release listed is 1.0.1, tagged on 2024-08-06, and 1.0.0 before it on 2024-01-22. The last push to the default branch was on 2026-07-09, so the tree has moved since the last tag, but there is no versioned artifact to upgrade to and no changelog in the README. If your project needs a dependency with a release cadence, this is the wrong shape of thing.

A third case is offline or privacy-sensitive use. The design depends on two remote services: Stream for messaging and Google's Generative AI for generation. There is no described local model path. If your requirement is that message content never leaves the device, this architecture cannot satisfy it, and no amount of reading the sample will change that. Finally, the README is silent on error handling, retries and streaming responses, so you will be designing those yourself if you adopt the pattern.

Compared with building on Firebase and the Gemini SDK alone

The obvious alternative is to skip Stream and use the Gemini SDK directly with a messaging backend you already have, such as Firebase Realtime Database or Cloud Firestore. The difference is what you inherit. With this repository, the chat layer arrives complete: the README lists real-time event handling as the reason Stream Chat Compose SDK is there, and the Compose UI components come from that SDK. You write the Gemini call and the surrounding screens. With the Firebase route, you own message ordering, delivery state, typing indicators, offline queues and the Compose list that renders them, and you own the token model on both sides.

That trade is not about which stack is better. It is about where you want to spend the first two weeks. If the chat surface is incidental to your product and you already run Firebase, adding Stream means a second vendor, a second dashboard and a second key to manage. If the chat surface is the product, and you want a Compose message list that already handles real-time events, the sample shows you that integration working end to end. The repository is also a reasonable read even if you choose neither path, because the Hilt and AppStartup arrangement across app/, core/ and feature/ is a clean example of modular Android wiring.

Licence, maintenance and what an upgrade actually costs

The repository is licensed under Apache-2.0, and the README carries the standard Apache 2.0 badge linking to opensource.org. For a sample application that you fork, that is a permissive starting point, but the licence covers this code only. Stream Chat SDK and the Gemini API are separate products with their own terms, and the README's sign-up flow makes clear that using them means accepting a Stream account. Nothing here is legal advice; read the licence file and the vendors' terms yourself.

Upgrade cost is the more practical question. Because there is no published artifact, upgrading means diffing the repository against your fork. The last push was on 2026-07-09, months after the 1.0.1 tag, so any diff will mix genuine improvements with unrelated churn in the build-logic/, buildSrc/ and spotless/ directories. Two external dependencies move independently of the repository: the Stream Chat Compose SDK and the Gemini API. A breaking change in either will not appear as a new release here. If you fork this project, pin your dependency versions and treat the upstream tree as reference material you consult, not a branch you merge from. The README does not document a migration or upgrade process, so there is nothing to follow.

Editorial conclusion

Adopt it if you are building a Compose chat screen and want a working reference for combining the Gemini API with Stream Chat, or if you are studying how Hilt, AppStartup and coroutines are arranged in a modular Android project. Do not adopt it if you need a maintained library, an offline assistant, or anything you can ship without a Stream account. Before you start, verify three things: that you can create a Stream app and copy its key, that you can generate a Gemini API key in Google AI Studio, and that Disable Auth Checks on the Stream dashboard is acceptable for your environment, because the README turns it on for local runs. The last push to the repository was on 2026-07-09, and the newest tagged release is 1.0.1 from 2024-08-06, so treat the code as a snapshot to read rather than a dependency to track.

Frequently asked questions

Official sources

1. GetStream/gemini-android on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases