# mixpanel-android: Mixpanel's Android SDK split into three artifacts > The official Android tracking library for Mixpanel, published as separate analytics, common and OpenFeature provider modules, with feature flag evaluation bundled into the analytics artifact. The repository README is a short pointer document, so most of what a user needs is on Mixpanel's own docs site rather than in the code. **mixpanel/mixpanel-android** — Official Android Tracking Library for Mixpanel Analytics - Repository: https://github.com/mixpanel/mixpanel-android - Website: http://mixpanel.com/ - Stars: 1,048 · Forks: 374 - Language: Java - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/mixpanel-mixpanel-android ## A README that points elsewhere The repository is described in one line as Mixpanel's Android libraries, and the README is correspondingly short. It says that for installation and implementation steps you should see the official Mixpanel docs, and it links two pages: the Android SDK page, for event tracking, identity and people properties, and the Android Feature Flags page, for feature flag evaluation, with a note that the flags are bundled in the analytics library. That is the entire README, apart from the modules table and the licence line. It is worth being explicit about what that means for a reader. Almost none of the substance of this library is documented in the repository. There is no API reference here, no list of methods, no sample code, no guidance on consent, no lifecycle advice, no description of the network protocol. The repository is where the code lives and where the coordinates are published, and the documentation is a product surface hosted elsewhere. For an evaluation that is a real constraint. You can see the module structure, the version lines and the shape of the build, but you cannot answer the questions that decide an analytics SDK, such as what happens when a device is offline, whether the library batches events or sends them one at a time, how much data is persisted on the device, and how a user opts out. Those are all on the docs site, or they are not answered at all. The project is Apache-2.0 licensed with a `LICENSE` file at the root, the primary language in the metadata is Java, the default branch is master, and the last push was on 2026-10-02. ## Three published artifacts and what each one is for The modules table is the most useful thing in the README, because it tells you which coordinate to put in your build file and what the boundaries between the artifacts are. The `analytics` module publishes as `com.mixpanel.android:mixpanel-android`, and it is the one most applications need. The `common` module publishes as `com.mixpanel.android:mixpanel-android-common`, and the name suggests the shared code that the other modules depend on. The third is the one that makes the table interesting. The `openfeature-provider` module publishes as `com.mixpanel.android:mixpanel-android-openfeature`, which is an implementation of the OpenFeature provider interface backed by Mixpanel's feature flags. That module is the interesting design decision in the whole repository. By shipping a provider rather than only its own flag API, Mixpanel lets an application that already uses OpenFeature for its flags plug Mixpanel in as one more source without changing the call sites. An application that does not use OpenFeature can still call the feature flag API directly, since the README says the flag evaluation is bundled in the analytics library, so the provider is an adapter rather than a requirement. The practical consequence is that the flag support does not require a second dependency for the common case, but the OpenFeature provider is a separate coordinate that you add only if you want the interop. The table gives the Maven Central badge for each, so a reader can check the published versions directly rather than trusting the README. ## Two version lines, and a module the table does not list The release list is the most revealing part of the repository metadata, because it shows two independent version lines running in parallel. The analytics SDK is on version 8.11.0, published on 2026-09-11. Alongside it are `session-replay-v1.6.0` from 2026-10-02 and `session-replay-v1.5.0` from 2026-09-09, which are dated by the same cadence as the main line but numbered independently, on a 1.x scheme rather than an 8.x one. So session replay ships as a separate artifact with its own version line, and the two lines move at their own pace. That is the normal shape for a feature that is newer and more volatile than the core library, and it has a direct effect on how you manage dependencies: the session replay artifact is the one that will force you to revisit a version constraint, and pinning it to a 1.5 or 1.6 line independently of the analytics 8.x line is a decision you have to make rather than one the build makes for you. Now look at the repository layout against the modules table. The top level contains `analytics/`, `common/` and `openfeature-provider/`, which match the table, and it also contains `session-replay/`, which does not. There is also a `context/` directory and a `scripts/` directory, neither of which appears in the README. So the README's module table is not a complete inventory of the repository. It documents the artifacts that are published under the `com.mixpanel.android` group, and the session replay module is in the tree without a table entry. The releases say it is published, but under which coordinate is not something the README states, and a reader who assumes the table is complete will miss it. ## The build layout, and the agent files in the tree The build system is Gradle, and the layout is the multi-module style that a large Android library uses. There is a `build-logic/` directory, which is where the convention plugins live, so that the shared configuration is a plugin rather than a copy in each module. There is `gradle.properties`, a `gradle/` directory with the wrapper, `gradlew` and `gradlew.bat` for the wrapper scripts, and a `settings.gradle` that lists the modules. There is also a `build.gradle` at the root, a `.classpath` and a `.project` file, which are the Eclipse project files, and a `.settings/` directory. That combination is a signal worth noticing. The Eclipse metadata is not needed by Gradle, and it suggests that the project is still imported into Eclipse by some of its contributors, or that the IDE configuration predates the Gradle setup and was never removed. Either way, an open source project that carries both is one that other people are working in with mixed tooling. The repository also contains a set of files that say something about how the project is developed today: an `AGENTS.md`, a `CLAUDE.md`, a `.claude/` directory and a `.cursor/` directory. That is a project that has formalised how coding agents participate, alongside the more conventional `CONTRIBUTING.md` equivalent, and it is increasingly common in repositories that receive a lot of machine-generated contributions. There is a `SECURITY.md` for vulnerability reports, and the `README.md` links the licence as Apache 2.0 with a pointer to the `LICENSE` file. ## What adopting a vendor tracking library actually commits you to The last thing to think about is not technical, and it is the reason this repository is worth reading carefully rather than glancing at. A tracking library is a client for a hosted service. The code in this repository is the part that runs on your user's device, and the data it produces ends up on somebody else's servers, where you do not control the retention, the access policy or the terms of use. The library is Apache-2.0, and the licence covers the code, not the behaviour of the backend behind it. That has a few concrete consequences for an evaluation. The feature flag evaluation is bundled in the analytics library, so the flags are delivered by the same backend that receives your events, which means a team that wanted flags to be independent of its analytics vendor cannot get that from this library alone. The identity model, with people properties, means you are sending identifiers about your users to a third party, and the questions of consent and of what a user can see about their own data are answered by the vendor's documentation rather than by anything in this repository. None of that is an argument against the library. It is the normal bargain for an analytics SDK, and for a team that has already chosen Mixpanel the official library is clearly better than a hand-rolled HTTP client against the same API. The thing to check before you commit is the documentation. The README delegates to two pages, and the review of an analytics SDK has to be a review of those pages, because that is where the behaviour, the data collected and the consent model are described. ## Conclusion mixpanel-android suits an Android team that has already chosen Mixpanel as its analytics backend and wants the official library, the official feature flag evaluation and the OpenFeature provider rather than a hand-rolled wrapper. It does not suit a team deciding between analytics vendors, and it does not suit a project that needs to inspect, self-host or intercept the data, because the library is a client for a hosted service and the documentation lives on the vendor's site rather than in the repository. Before adopting it, read the Android SDK and the Android feature flags pages on the Mixpanel docs site, since the README defers almost everything to them, and check which artifact you actually need, because the feature flag support is bundled in the analytics library while the OpenFeature provider is a separate coordinate. ## FAQ ### Which Maven artifacts does mixpanel-android publish? Three, according to the modules table: `com.mixpanel.android:mixpanel-android` for the analytics module, `com.mixpanel.android:mixpanel-android-common` for common, and `com.mixpanel.android:mixpanel-android-openfeature` for the OpenFeature provider. ### Are feature flags part of the Mixpanel Android analytics library? Yes. The README says feature flag evaluation is bundled in the analytics library, and the OpenFeature provider is published as a separate module for applications that want to use Mixpanel's flags through the OpenFeature specification. ### How is the session replay library versioned? On its own line. The release list shows `session-replay-v1.6.0` from 2026-10-02 and `session-replay-v1.5.0` from 2026-09-09 alongside the main library's v8.11.0 from 2026-09-11, so the two lines version independently. ### Where is the mixpanel-android documentation? On the official Mixpanel docs site rather than in the repository. The README links the Android SDK page for event tracking, identity and people properties, and the Android Feature Flags page for flag evaluation. ### What licence is mixpanel-android released under? Apache 2.0, with the licence file at the repository root and the README pointing to it. ## Sources - [License: Apache-2.0](https://github.com/mixpanel/mixpanel-android/blob/master/LICENSE) - [mixpanel/mixpanel-android on GitHub](https://github.com/mixpanel/mixpanel-android) - [Project website](http://mixpanel.com/) - [README](https://github.com/mixpanel/mixpanel-android/blob/master/README.md) - [Releases](https://github.com/mixpanel/mixpanel-android/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mixpanel-mixpanel-android