# nightscout/AndroidAPS: the open source closed loop for diabetes, and the repository that is mostly a signpost

> AAPS is an AGPL-3.0 licensed Kotlin implementation of an automated insulin delivery system, a closed loop. Its README is not a manual: it points at a wiki, a Discord support server, a translation platform, a documentation build and a test coverage service, and the real engineering content is in a tree split into app, core, shared, implementation, plugins, pump, database, workflow, ui and wear modules.

**nightscout/AndroidAPS** — Opensource automated insulin delivery system (closed loop)

- Repository: https://github.com/nightscout/AndroidAPS
- Website: https://wiki.aaps.app
- Stars: 1,220 · Forks: 7,300
- Language: Kotlin
- License: AGPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/nightscout-androidaps

## What the repository is, and what it is not

AAPS is the open source automated insulin delivery system, a closed loop, written in Kotlin. That is the one line description the project gives, and it is the whole of what the README says about what the software does.

That is unusual for a project of this size, and it is a deliberate choice rather than an oversight. The README opens by pointing at the wiki at wiki.aaps.app, and what follows is a set of links: the documentation build with a Read the Docs status badge, a Discord support server, a CircleCI build status for the master branch and a second one for the dev branch, a codecov coverage badge for each, and a Crowdin badge linking to the translation project at translations.aaps.app.

So the repository is a signpost. The documentation is on the wiki, the support is on Discord, the translations are on Crowdin, the CI is on CircleCI and the coverage is on codecov, and the code sits underneath all of that.

For a medical device project, that separation is defensible. The wiki moves faster than a repository README can, it is versioned with the documentation, and it is where the safety documentation belongs. It also means that an evaluation based on the repository alone will be shallow, and anyone writing about this project has to be honest about that limit rather than inventing a feature list the README does not contain.

## The repository tree is the real architecture

Since the README is thin, the top level directory listing carries most of the information about how the project is put together.

There is `app/`, which is the Android application itself, and `core/` for the shared domain logic, `shared/` for code shared across the modules, `implementation/` for the concrete implementations, and `plugins/` for the extension points. Then there is `pump/`, `database/`, `workflow/` and `ui/`, plus a separate `wear/` module for a watch companion, a `benchmark/` directory, `buildSrc/` for the Gradle build logic, and `_docs/` for documentation sources.

Two of those names deserve a second look because they explain why the project is structured this way. A `pump/` module at the top level, next to `plugins/`, is the shape you would expect for a system that has to talk to insulin delivery hardware from several vendors, with the vendor specific parts behind an interface. And `workflow/` as a separate module, alongside `core/`, is the shape you would expect for a system whose treatment logic, that is the algorithm that decides doses, is deliberately separated from the delivery mechanism and from the interface.

That is an inference from the module names rather than a claim the documentation makes in so many words, but it is a reasonable one, and it is the reason the project can support both a phone app and a watch app from one codebase.

The build is Gradle, in the modern Kotlin DSL form, with `build.gradle.kts` at the root, `settings.gradle`, `gradle.properties` and the `gradlew` wrapper, and a `jacoco_aggregation.gradle.kts` for merging coverage across the modules.

## Two branches, two pipelines, two release lines

The badge layout makes the branching model visible. There is a CircleCI badge and a codecov badge for the `master` branch, and a second pair for the `dev` branch, each with its own build link.

The release history shows both lines in use. The recent tags are 3.4.2.5 on 2026-07-30, 3.4.2.6 on 2026-08-02 and 4.0.0-beta1 on 2026-10-08, and the last push to the repository was on 2026-10-15.

The patch numbering is worth a look. A version like 3.4.2.6 has four components, which is a convention used when a release line needs to ship many fixes without burning through the minor or major number, and it is what you would expect from a project that ships a patch roughly every week or two during an active period. 3.4.2.5 and 3.4.2.6 are three days apart.

Meanwhile 4.0.0 exists only as a beta. So the practical reading of the release table is that 3.4.x is what people are running, and 4.0 is where the next major work is landing. For a system where a user runs the app on their own body, that distinction matters, and it is the same distinction you would expect from any project with real users and a regulatory awareness around changes.

The wiki's own versioned documentation, with a latest and an en/latest build, is the other half of that story, since a user reading the documentation needs to be reading the version that matches the app they have installed.

## Translations, coverage and the helper scripts

The Crowdin badge and the `crowdin.yml` file in the tree point to a hosted translation platform rather than a directory of `.xml` files in the repository. That is the usual choice for an application with a large and international user base, since a translation platform lets a translator propose a string and lets a maintainer review it, and it keeps the repository free of merge conflicts on translation files.

The coverage story is similar in spirit, reported through codecov. There is a `codecov.yml` at the root and a `jacoco_aggregation.gradle.kts`, which is the piece that merges coverage reports from the several Gradle modules into one number. For a project with an `app/` module, a `core/` module, a `shared/` module and a `wear/` module, per module coverage is not comparable, so the aggregation step is what makes the badge meaningful.

The root also has a set of small helper scripts that reveal how the project is worked on. There is `runtests.sh` and `runtests.bat`, the shell and Windows equivalents of running the test suite, and `dependencyGraph.bat` and `connectwsa.bat`, which are the kind of one off utilities a project accumulates to inspect its own dependency graph and to attach a debugging client. The presence of both `.sh` and `.bat` variants is the small signal that contributors run on both platforms.

The repository also carries `CONTRIBUTING.md`, an `ISSUE_TEMPLATE.md`, a `.editorconfig` and a `CODEOWNERS`-style `.github/` directory, which together describe a project with a defined contribution process rather than a loose collection of patches.

## Where this is the wrong choice

The first and most important wrong case is treating this as ordinary software. A closed loop insulin delivery system calculates and delivers doses, and the consequences of a misconfiguration are not a failed build. The project's own framing reflects that, with a request that everyone who has been looping with AAPS fill out a form after three days of looping, and a support channel on Discord rather than an issue tracker for most questions. A system that decides doses needs documentation, clinician involvement and a conservative upgrade path, and none of that is in the repository.

The second wrong case is using it as a library or a dependency. This is an application, and the AGPL-3.0 licence is the specific reason it is a poor choice for a closed source product, especially one in the health space.

The third is picking the branch by curiosity. A developer who wants to build a plugin should work against the 3.4 line that people are running, not against 4.0.0-beta1, and the wiki and the documentation build both need to be at the matching version.

The fourth is expecting a stable, small dependency. The tree has more than a dozen Gradle modules, an active beta line and weekly patch releases, so the upgrade cadence is a factor to plan for rather than a detail.

On the state of the project, the repository is not archived and the last push was on 2026-10-15, with the licence AGPL-3.0 and the project hosted under the Nightscout organisation on GitHub.

## Conclusion

Adopt AAPS only if you are a technical user of the platform who is prepared to read the wiki, understand the safety implications and take responsibility for the configuration, because this is a system that decides insulin doses and the repository itself is a pointer to documentation rather than a description. Do not adopt it as a development dependency for a commercial product, since the AGPL-3.0 licence is a real constraint on a health related codebase, and do not treat the master branch as the place to start if you want a stable release, since the current line is the 3.4.x series while 4.0.0 is still a beta. Verify first with your own clinician what the system does in your configuration, that the wiki version you are reading matches the app version you are running, and that the translations and the documentation you rely on are current.

## FAQ

### What is AAPS?

AAPS, the AndroidAPS project, is an open source automated insulin delivery system, a closed loop, written in Kotlin and licensed under AGPL-3.0. The README points to the project wiki at wiki.aaps.app for documentation rather than describing the software in the repository itself.

### Where is the documentation for AAPS?

On the project wiki at wiki.aaps.app, with a versioned documentation build published through Read the Docs, and the wiki's own build badge in the repository README. There is also a Discord support server linked from the same page.

### How are AAPS translations handled?

Through the Crowdin translation platform, with a Crowdin badge and a `crowdin.yml` file in the repository pointing at the project on translations.aaps.app, rather than translation files being edited directly in the repository.

### Which AAPS release should I look at?

The recent tags are 3.4.2.5 on 2026-07-30, 3.4.2.6 on 2026-08-02 and 4.0.0-beta1 on 2026-10-08, so the 3.4.x line is the current stable series and 4.0 is still a beta. The repository also maintains a separate `dev` branch with its own CircleCI and codecov badges.

### How is the AAPS codebase structured?

The top level has `app/`, `core/`, `shared/`, `implementation/`, `plugins/`, `pump/`, `database/`, `workflow/`, `ui/` and a separate `wear/` module, alongside `benchmark/`, `buildSrc/` and `_docs/`. The build is Gradle in the Kotlin DSL form, with a `jacoco_aggregation.gradle.kts` that merges coverage across the modules.

## Sources

- [License: AGPL-3.0](https://github.com/nightscout/AndroidAPS/blob/master/LICENSE)
- [nightscout/AndroidAPS on GitHub](https://github.com/nightscout/AndroidAPS)
- [Project website](https://wiki.aaps.app)
- [README](https://github.com/nightscout/AndroidAPS/blob/master/README.md)
- [Releases](https://github.com/nightscout/AndroidAPS/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nightscout-androidaps