The OneSignal Android SDK is a thin Kotlin client around a hosted service

What the plugin is, and what it is not

OneSignal is described as a service for sending push notifications, in-app messages, SMS and email to mobile apps, and this repository is the plugin that connects a native Android or Amazon app to that service. The primary language is Kotlin, and the package is published on Maven Central under the artifact name com.onesignal.OneSignal, which is the coordinate you put in a Gradle dependencies block.

The wording in the project description is worth noticing. It calls itself free, and it lists the channels it covers, and the plugin's stated job is making the integration easy rather than implementing delivery. That distinction is the first thing to internalise, because it determines what happens when the service changes.

The repository itself is correspondingly compact. It holds the SDK source in a OneSignalSDK directory, a separate OneSignal-KMP-SDK directory for the Kotlin Multiplatform side, an examples directory with demo projects, a script directory, a migration guide, a code owners file, and the contribution guide. The README points to an Android Native SDK setup guide for installation steps and to a separate Android Native SDK API page for the list of available methods, which means the API surface is documented outside the repository rather than in it.

So the artefact you integrate is a client. The delivery infrastructure, the dashboard, the audience segmentation and the message editor all live in the hosted product.

The v5 migration is the decision most existing users face

The README opens with a migration advisory for current OneSignal customers, and it is more candid than most vendor notices. The new user-centric APIs and the v5.x.x SDKs offer an improved user and data management experience, however they may not be at 1:1 feature parity with the previous versions yet.

That sentence is the whole risk statement, and it is the reason a migration here is not a routine dependency bump. A client library that has not reached feature parity with the version it replaces will have behaviour differences that a version comparison will not surface, because the differences are in what the service accepts and reports rather than in method signatures.

The advice the project gives is about rollout rather than about code. If you are migrating an existing app, it suggests using Android's Phased Rollout capabilities to make sure there are no unexpected issues or edge cases, and it links the documentation for Google Play Staged Rollouts. The reasoning is sound: with a large installed base, a staged rollout turns a potential outage into a measurable signal from a small percentage of devices before the rest of your users are affected.

A migration guide sits at the root of the repository alongside the README, so the specific differences are documented there, and the support address given in the advisory is [email protected] for anyone who hits a case the guide does not cover.

Building the SDK needs a submodule for the shared logger

There is a build wrinkle in the README that will stop anyone cloning the repository and running a build without warning. The repository uses a git submodule for the shared Kotlin Multiplatform logger module, and the README explains that you should clone with git clone --recurse-submodules, or run git submodule update --init --recursive after cloning and before building.

This is a common consequence of splitting a code base across repositories, and it is more visible than usual here because the shared piece is a Kotlin Multiplatform module. The same module has to serve the Android SDK and the other targets, which is a sensible way to avoid duplicating logging code, but it means the SDK source is not self contained. The .gitmodules file at the root of the repository records the wiring, and the contributing guide has a building from source section with the details.

The rest of the repository layout supports the same story. There are separate directories for the Android SDK and the KMP SDK, a script directory for the build tooling, and CODEOWNERS, which is a signal that the project expects contributions and has a review structure for them. The examples directory contains a demo project and a build.md, and the README points to published demo projects in the examples folder as the way to make the integration easier to grasp.

The build itself runs on Travis CI, with a build status badge for the main branch, and the Maven Central badge in the README is the check that the published artifact matches what you would get from a release.

Android 5.0 through Android 14, and no API list in the repository

The supported platform range is stated in one line at the end of the README: tested from Android 5.0 at API level 21 to Android 14 at 34. For a library that runs in every app on a device fleet, that range is the compatibility contract, and it is the first thing to check against the devices your own users actually run.

The second thing to check is what the repository does not contain, which is a longer list than it might first appear. There is no method documentation here. The README routes every API question to the Android Native SDK API page, and installation questions to the setup guide, both on the OneSignal documentation site. The change log is not a file either, it is the repository's release tags, which the README points to for a complete change log of every released version.

That is a legitimate way to run a project whose centre of gravity is the service, and it has one advantage worth naming: the documentation on the site is the same one your whole team will read, and it is updated when the service changes rather than when the repository is tagged. The cost is that reviewing the SDK offline is harder, and that a version pin alone does not tell you what a release contains.

Support follows the same split. SDK specific bugs and feature requests go to the GitHub issue tracker, while account issues and support go to OneSignal support through the dashboard.

Licence, release cadence and the shape of the dependency

The licence attached to this repository is one GitHub cannot classify, which means there is a custom licence file and you should read it rather than assume a standard open source grant. That is worth doing before an SDK becomes a permanent part of your build, since a client library ends up vendored into every app you ship and its terms reach your users through your binary.

Release activity is steady. The repository is not archived and the last push was on 2026-10-19, and the recent releases are 5.10.2 on 2026-09-19, 5.10.1 on 2026-09-18 and 5.10.0 on 2026-09-08. The two releases a day apart in mid September are the shape of a patch release followed by a quick fix, which is normal for a client that has to keep pace with a service.

The topics attached to the repository describe the range the SDK covers, and they are broader than push alone. They include FCM, GCM, HMS PushKit, notification service, in-app messaging, SMS and email, along with the Amazon variant of the platform, so the plugin sits on top of several push transports rather than one.

What that means for an adopter is that the dependency is a client for a hosted service, and the trade is familiar. You get four channels, audience targeting and a dashboard from one integration rather than three, and in exchange your notification path depends on a vendor whose client library you do not control and whose API changes have been arriving with a feature parity gap. If your team later wants to change provider, the client library is the part that is cheap to replace, and the audience and device state management around it is the part that is not.

Editorial conclusion

Adopt the OneSignal Android SDK if you have already decided to use OneSignal as your messaging provider and you want its push, in-app, SMS and email channels behind one integration, because the alternative is three separate service integrations. Do not adopt it as a way to evaluate push delivery, since the SDK carries no API documentation of its own and every method list lives on an external site, and do not upgrade a large installed base without reading the migration guide first. Verify first by pinning a 5.10.x artifact, confirming which device types your new build reports, and running the staged rollout the project recommends before shipping the change to all users.

Frequently asked questions

Official sources

1. Issues
2. OneSignal/OneSignal-Android-SDK on GitHub
3. README
4. Releases