# Countly Android SDK and the analytics client behind a self hosted product platform > The Countly Android SDK is the Java client that connects an Android application to Countly Lite, Flex or Enterprise, covering analytics, push notifications, user profiles, crash reports, A/B testing, performance monitoring and feedback widgets. It is a well maintained client for an existing platform, and the interesting question for an adopter is what happens when the server side is not Countly. **Countly/countly-sdk-android** — Countly Digital Analytics Android SDK - Repository: https://github.com/Countly/countly-sdk-android - Website: https://countly.com/ - Stars: 696 · Forks: 290 - Language: Java - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/countly-countly-sdk-android ## One client, three server editions The repository contains the Countly Android SDK, which can be integrated into Android applications, and it states up front that the SDK is intended to be used with Countly Lite, Countly Flex or Countly Enterprise. That structure is the single most important fact about the SDK for anyone evaluating it. The three are different shapes of the same platform. Lite and Flex and Enterprise are the commercial tiers, and the SDK is written to work against all of them, which means the client code you write for a small deployment is the same client code that works for an enterprise one, with the differences handled by the server you point it at. Countly itself is described as a product analytics solution and innovation enabler that helps teams track product performance and customer journey and behavior across mobile, web and desktop applications, with privacy by design as a stated principle, and the goal of helping teams innovate and enhance products to provide personalized and customized customer experiences. The framing in the readme is that you track, measure and take action all without leaving Countly. That is the difference from a raw analytics library: this is not a firehose of event callbacks that you aggregate yourself, it is a client for a platform that does the analysis, the segmentation and the dashboards, and for the experimentation and messaging features described below. The repository also points you to the Countly Server repository if you are looking for the server side, and to an overview of all Countly SDKs for mobile, web and desktop if you need a different platform. So the client is one piece of a wider system, and the SDK directory is not the product. If you are evaluating Countly as a platform rather than as a client library, this repository is the wrong place to start, because everything it shows you is the easy part. ## Seven features, and one of them is a push notification client The supported feature list is what makes this more than a page view counter, and it is worth reading the list as the product surface of the client. Analytics, user profiles, crash reports, A/B testing, performance monitoring and feedback widgets are the familiar set, and each of them links to its own documentation page in the Countly support system. Feedback widgets in particular cover surveys, NPS and ratings, which is a feature many analytics clients do not carry because it needs a UI surface in your app rather than just an event call. Push Notifications is the entry that stands out, because it is not analytics at all. A push notification client has to deal with the device token, the notification channel, the permission prompt and the service integration, which is a different kind of code from the rest of the list and a different kind of failure. It also means the SDK has a server counterpart, since push campaigns are sent from the Countly side and delivered through the platform's push service. That combination, analytics plus messaging plus experimentation, is the reason the SDK exists rather than a lighter event library. It also explains why the readme separates the support question for push from the analytics documentation, and why the feature list mixes things that would normally be separate dependencies. The API level requirement is stated in a badge at the top of the readme, API 21 and above, which is the floor for the whole client. One thing the readme does not do is describe what the SDK sends and when. There is no section on batching, on offline buffering, on how events are queued when the network is unavailable, or on what the SDK does with a device identifier. For a client that is embedded in every release of an application, those are the questions that determine whether you want it, and they are answered in the Countly support documentation rather than here. ## The repository holds the SDK, the native layer and four sample apps The top level directory listing shows a project with more than one thing in it, and the shape tells you what the SDK is built from. There is `sdk/`, which is the main Java SDK, and `sdk-native/`, which is paired with a `.gitmodules` file, so the native part is a separate repository pulled in as a submodule rather than code kept in this tree. There is also an `app/` directory, and the readme points to it for an example integration of the SDK. The other application directories are `app-native/`, `app-kotlin/` and `app-benchmark/`, which is a set of sample applications rather than a set of production modules. The `app-kotlin/` one tells you the SDK is usable from Kotlin, which matters more than it sounds for an Android client in 2026, and `app-benchmark/` tells you there is a performance harness in the repository, though the readme does not describe what it measures or how to run it. The `upload-plugin/` directory is separate from the SDK and from the apps, and its name suggests it is a Gradle plugin rather than Android code. A plugin with a name like that in a build system usually has one of two purposes, either publishing the SDK to a repository, or gathering and publishing build artefacts. Which one it is, the readme does not say, and it is worth finding out if you maintain a fork, because a change to how the SDK is published is a change to your release pipeline. The build itself is Gradle. There is a `build.gradle` at the root, a `settings.gradle`, a `gradle.properties`, the `gradle/` directory, and the `gradlew` and `gradlew.bat` wrapper scripts, so a clone is buildable with the wrapper and no local Gradle installation. There is also a `ruleset.xml`, which is a Checkstyle ruleset, and a `.travis.yml`, which is a leftover from the Travis CI era even though the badge in the readme points at the Codacy dashboard rather than a build status. The `CHANGELOG.md` at the root is where the version history lives, and it is the file to read before you pick a version. ## The integration instructions live in the support system, not the repository This is the structural weakness of the repository as a piece of documentation, and it should be weighed before you adopt the SDK. The readme offers four pointers and not one code sample of an actual integration. For a detailed description on how to use this SDK, check out the Countly documentation. For information about how to add the SDK to your project, check this section of the documentation. Minimal SDK integration information is in another section of the documentation. And for an example integration, you can have a look at the `app` directory in the repository. So the practical sequence for a new user is: read the support articles, then read the example app in the tree. That is workable, but it means the repository alone does not tell you how to use the SDK, and it means the SDK's usability depends on a documentation site that is outside the project's version control. When the SDK changes, the support articles change with it, and there is no diff to read. The example app is the more durable artefact, because it is in the repository and versioned alongside the code. It is the piece to actually read if you want to know how the SDK is meant to be initialised, what the configuration object looks like, and how sessions and events are reported. The four sample apps together, Java, native, Kotlin and the benchmark, are a reasonable sample of the integration surface. The one thing the readme does include as literal code is the badge markup, which is at least concrete: ```js Countly - Product Analytics ``` That is a small signal about the project's tone. The platform asks users to display a badge, offers a Discord community for support, and asks for pull requests and community involvement. Whether you want a vendor whose ecosystem is organised around a community server rather than around a support contract is a reasonable thing to decide explicitly. ## Two release tags with the same version number and a suffix The release history has a detail that deserves attention before you pin a version. The three most recent releases are 26.1.6-nw on 2026-09-09, then 26.1.7-nw and 26.1.6 both on 2026-09-30, and the last of those was pushed to the repository as 26.1.6 at 07:38:56, three minutes after 26.1.7-nw at 07:35:00. Two things follow. First, there are at least two release flavours distinguished by the `-nw` suffix, and the repository does not explain what the suffix means. Second, the version numbers are not strictly increasing across the tagged releases, because 26.1.6 and 26.1.7-nw were both published on the same day. Whatever the suffix denotes, the ordering of the tags is not simply numeric, and a build script that resolves the latest release by version comparison rather than by publish date will get this wrong. The numbering scheme itself is also worth noting. The versions carry a year and a minor number, 26 for 2026 in the style the wider Countly ecosystem uses, which is at least self-describing when you look at a build a year later. For the security side, the repository has a SECURITY.md and the readme states a simple policy: if you discover any issue regarding security, disclose the information responsibly by sending an email to security@count.ly and not by creating a GitHub issue. That is the right convention, and it means the SDK has a private disclosure path even though the SDK itself is open source and MIT licensed. ## Conclusion The Countly Android SDK fits a team that has chosen Countly as its product analytics backend and needs a client that reports sessions, crashes and push on modern Android. It is the wrong choice if you want to evaluate analytics platforms, because the SDK is the part that commits you, and it is the wrong choice for a self hosted deployment that has to work without any Countly service at all. Before you integrate, verify three things: the minimum API level, since the badge marks API 21 and above, the push provider configuration on your chosen platform, and the release line you install, because the recent tags include an `-nw` suffix on two of the three newest releases and the distinction is not explained in the repository. The code is MIT licensed, the last push was on 2026-10-19, and the newest release tag is 26.1.7-nw from 2026-09-30. ## FAQ ### What is the Countly Android SDK and what does it cover? It is the Java client for the Countly platform, intended to be used with Countly Lite, Countly Flex or Countly Enterprise. It supports analytics, push notifications, user profiles, crash reports, A/B testing, performance monitoring and feedback widgets, and requires API level 21 or above. ### How do I integrate the Countly Android SDK into an app? The repository points to the Countly support documentation for the detailed description, for adding the SDK to a project and for minimal integration information, and separately to the `app` directory in the repository as an example integration. The repository itself does not contain a code sample of the integration. ### Is the Countly Android SDK open source? Yes. The repository records the MIT licence, and the source is in the `sdk/` directory with a `sdk-native/` submodule alongside it. There are four example applications in the tree, `app/`, `app-native/`, `app-kotlin/` and `app-benchmark/`. ### How should I report a security issue in the Countly Android SDK? The readme asks that security issues be disclosed responsibly by emailing security@count.ly rather than by creating a GitHub issue. A SECURITY.md file is present in the repository as well. ### What is the difference between the 26.1.6 and 26.1.7-nw releases? The repository does not explain it. The three most recent tags are 26.1.6-nw from 2026-09-09, 26.1.7-nw from 2026-09-30 and 26.1.6 from 2026-09-30, so there are at least two release flavours distinguished by the `-nw` suffix and the tag order is not simply numeric. ## Sources - [Countly/countly-sdk-android on GitHub](https://github.com/Countly/countly-sdk-android) - [License: MIT](https://github.com/Countly/countly-sdk-android/blob/master/LICENSE) - [Project website](https://countly.com/) - [README](https://github.com/Countly/countly-sdk-android/blob/master/README.md) - [Releases](https://github.com/Countly/countly-sdk-android/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/countly-countly-sdk-android