The Stream Chat Android SDK ships six artifacts, and only two of them are chat UI

Two low level artifacts and two UI toolkits

The SDK is described as a low-level chat SDK plus a set of reusable UI components, with the stated intent that most users start with the UI components and drop to the lower level API when they need to customise things.

The two low level artifacts are the Client, described as a low-level client for making API calls and receiving chat events, and Offline support, which provides local caching and automatic retries exposed through Flow and LiveData APIs.

The two UI SDKs sit on top. Compose UI Components are reusable, modular Composables for conversations and channel lists. UI Components are the XML based Views, described as reusable and customizable chat Views, for older UI solutions.

Both UI options cover the same ground, which is why choosing between them is the first decision rather than a detail. The README's position is explicit: it released the Compose components one day after Jetpack Compose 1.0, describes them as mature and stable enough to recommend for all new applications, and points anyone wanting high customisation and performance at the Compose SDK.

Kotlin and Java are both supported, with a strong recommendation to use Kotlin. The exception is spelled out: the Compose SDK supports only Kotlin, because Compose uses Kotlin compiler plugins to process the UI. That is a hard constraint on a Java codebase with existing chat screens.

Artifact sizes are published, with a caveat attached

The README carries size badges for each published artifact: the client at 6.20 MB, the UI components at 11.51 MB, the Compose module at 13.18 MB, the AI compose components at 2.03 MB and the on-device model at 1.66 MB.

The caveat under them is the part worth carrying into your evaluation. The sizes reflect the maximum possible addition if none of the internal dependencies are already in your app, and in most cases the actual impact will be smaller.

That means these numbers are an upper bound on a cold dependency graph, not a forecast for your build. If your app already pulls in the Compose runtime and the Kotlin coroutines stack, the Compose artifact's marginal cost is lower than 13.18 MB suggests.

The AI artifacts are worth separating from the rest, because they are the ones you can leave out. The README states that no other Chat SDK artifact depends on them.

The minimum floor is API 21, per the badge, which sets the oldest Android version the SDK will run on.

The two AI artifacts do different jobs

For AI assistants there are two separate artifacts, and the descriptions make the split clear.

AI Compose Components are Composables for AI replies: streaming text, reasoning and tool-call steps, tool approvals and a composer. That is a UI layer for showing what an assistant is doing, including the intermediate steps, and for handling the case where the app must ask the user to approve a tool call.

The on-device model is a model on the device, such as Gemini Nano, to answer when your agent cannot. That is a fallback path, not a replacement: the framing is answering when the backend agent is unavailable, which is a resilience feature rather than a local inference strategy.

Neither is required to ship chat. Since no other artifact depends on them, a team evaluating the SDK for messaging can leave both out and add them when an assistant feature is actually scheduled, which is the cleanest way to avoid paying for a dependency before it is used.

Installation goes through Stream's own Maven repository

Releases are published to the Stream Maven repository, and the README's instruction is to add it in settings.gradle.kts:

dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
        maven("https://jitpack.io")
        maven("https://stream-io-repo.com")
    }
}

Earlier versions remain available from Maven Central, which is the escape hatch if a repository host blocks the Stream domain or if you need a pinned older release.

The repository list also includes jitpack.io, which is needed because some artifacts are published through JitPack. There is a jitpack.yml at the repository root and the project publishes its own samples as modules.

The starting point for learning is a tutorial rather than the API docs. The Compose Chat Messaging Tutorial is the recommended entry and covers frequently required changes; the Android Chat Messaging Tutorial is the XML equivalent for older UI toolkits. Sample projects exist for the client, the UI components, the Compose components and the AI compose components, and the API reference is generated with Dokka.

Offline support is the layer that changes your failure behaviour

The offline artifact is described as local caching with automatic retries, surfaced through Flow and LiveData. That is the part of the SDK with architectural consequences rather than visual ones.

Caching means a channel list and message history survive a process death, which changes what your UI has to handle:. Automatic retries mean transient failures are handled by the SDK instead of by each screen.

Flow and LiveData together is a compatibility choice rather than an endorsement of both. LiveData is what existing Android code uses and what survives a configuration change without extra work; Flow is what new Compose code consumes. Supporting both means the SDK meets an existing codebase rather than requiring a migration.

If you take only the Client artifact and build your own screens, you also take on the retry and caching behaviour, because the README describes offline support as a separate artifact rather than as part of the client.

Licensing, cost and what is not in this repository

Two commercial facts sit next to the technical ones.

The SDK is free for most side and hobby projects under a stated threshold: the project or company needs fewer than five team members and under $10k in monthly revenue. Pricing detail lives on the vendor's chat pricing page, and the README links it rather than reproducing terms. This is a commercial SDK with a commercial service behind it, and the client talks to that service, so the licence of the code is not the whole question.

The repository itself is classified as carrying a custom licence that GitHub cannot categorise, with the LICENSE file at the root as the authority, so read that file rather than the badge.

On the engineering side, the repository shows how large this project is. There are modules for the client, core, offline support, both UI toolkits, UI common and guides, a markdown transformer, preview data, AI compose, on-device AI, benchmark and two test suites including end to end tests. Build tooling is Gradle with a checked-in wrapper, plus fastlane, a Gemfile for release automation, dokkasaurus_filter.json for docs, AGENTS.md and CLAUDE.md alongside CONTRIBUTING.md and SECURITY.md.

The default branch is develop, and the release cadence is visible in the tag list: v6.46.0 on 2026-10-14, v6.45.4 on 2026-10-13 and v6.45.3 on 2026-10-09, with the last push on 2026-10-16.

Editorial conclusion

Adopt the Compose SDK for a new Android chat feature and the XML UI Components only where an existing view based screen still has to host chat, since the README recommends Compose for all new applications and warns that the Compose SDK is Kotlin only. Do not adopt the low level client unless you intend to build your own screens, because offline support and the UI modules are the parts that carry the retry and caching behaviour. Verify first that your build can reach https://stream-io-repo.com in dependencyResolutionManagement, since releases are published there and earlier versions live on Maven Central instead.

Frequently asked questions

Official sources

1. GetStream/stream-chat-android on GitHub
2. Issues
3. Project website
4. README
5. Releases