# Anikku: an Android anime player that adds a library layer to Aniyomi

> Anikku is an Apache-2.0 Kotlin fork of the Aniyomi Android player that layers a management interface over the source-and-extension model, with categories, tracking sync, backups and a manga companion app. The judgement is that its contribution is the library and organisation layer rather than the player, and that the source-extension design is where its risk and its flexibility both live.

**komikku-app/anikku** — Free and open source anime watcher for Android

- Repository: https://github.com/komikku-app/anikku
- Website: https://anikku-app.github.io
- Stars: 1,116 · Forks: 76
- Language: Kotlin
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/komikku-app-anikku

## A fork of Aniyomi with a library layer on top

Anikku is a free and open source anime watcher for Android, written in Kotlin, and it is built on Aniyomi.

The README is explicit about what it adds and what it inherits. It describes itself as a full-featured player based on Aniyomi, for discovering and watching anime, cartoons and series on an Android device. Then it splits the feature list three ways. Features under the Anikku heading are the project's own additions. Features under the Aniyomi heading are the upstream player: watching videos, local watching of downloaded content, a configurable player built on mpv-android with multiple options and settings, tracker support for MyAnimeList, AniList, Kitsu, Simkl, Shikimori and Bangumi, categories to organise the library, and backups to watch offline or to a cloud service of your choice.

A third group is labelled as coming from other forks. Torrent support, credited to Diegopyl1209, which the documentation notes needs the right extensions. Cast functionality, credited to Animetail. Group by tags in the library, credited to Kuukiyomi. And Discord Rich Presence, credited to Animiru, Kuukiyomi and Animetail.

That three-way split is the most honest description of what a fork like this is. Anikku is a downstream integrator. It gathers improvements from a family of related projects, layers its own management features on top, and ships the result as one application.

The homepage is at `anikku-app.github.io`, and the app requires Android 8.0 or higher.

## The additions are about managing a library, not about playback

Reading the Anikku feature list tells you what the project considers its own contribution, and it is overwhelmingly about organisation rather than media.

The features are grouped under labels from the source websites. `Anime Suggestions` automatically shows the source site's recommendations, suggestions and related entries for the current item across all sources. `Auto theme color` derives the interface colour from each entry's cover art, in the entry view and the reader. `App custom theme` with colour palettes is offered for people who want to pick their own colours. `Bulk-favorite` marks multiple entries at once. `Fast browsing` is described as being for people with a large library who experience slow loading.

Then come the features marked as coming from SY, meaning SyncYomi. `Anime Recommendations` shows community recommendations from Anilist and MyAnimeList. `Anime Info` can be edited manually or filled from MyAnimeList, Kitsu, Shikimori, Bangumi or Simkl. `Custom cover` accepts a file or a URL. The `Feed tab` shows the latest entries or a saved search from multiple sources at once, and there is `Saving searches` with filters that can be used with the feed tab. `Pin anime` puts an entry at the top of the library with a `Tag` sort. `Merge anime` combines separate anime and episodes into one entry. There is a `Lewd filter` to hide lewd entries in the library, a `Tracking filter` to show tracked or untracked entries, and a search tracking status in the library. `Mass-migration` moves all your anime from one source to another at once. `Dynamic Categories` lets you view the library in multiple ways, and `Custom categories` let you build your own versions and put any sources in them. Cross device `Library sync` works with SyncYomi and Google Drive.

The smaller items are the same kind of thing. Anime `cover on Updates notification`, a `Panorama cover` showing a wide cover in full, a `to-be-updated` screen showing which entries will be checked with smart-update, an `Update Error` screen for migrating away from failures, a `Source & Language icon` on the library, `Grouped updates` in the update tab, drag and drop reordering of categories, the ability to enable or disable a repository with an icon, a search for sources, a quick NSFW sources filter, an in-app `progress banner` for library syncing, backup restoring and library updating, long-click to add or remove a single entry from the library anywhere, docking the watch or resume button to the left or right, auto-install of app updates, and a configurable interval to refresh entries from downloaded storage.

## Two release channels, and a separate preview repository

The distribution arrangement is more elaborate than a single release page, and the reason is that the app and its extensions are versioned separately.

The main repository publishes a stable build. The badge points at the latest release, and the workflow that produces it is `build_release.yml`. There is also a separate `anikku-preview` repository with its own releases and its own `build_app.yml` workflow, and the README labels that one a preview build. The CI workflow in the main repository is `build_push.yml`.

So there are two artefacts in play: a stable channel for everyday use and a preview channel for what is coming. That is the standard arrangement for a plugin-and-host architecture where the plugin ecosystem moves faster than the host, and it is a reasonable design for a project whose users install third-party extensions.

The documentation is hosted separately from the repository, with the website at `anikku-app.github.io` and a FAQ page at `anikku-app.github.io/docs/faq/general`, and the README points contributors to the changelog before reporting an issue. The contribution rule is stated plainly: pull requests are welcome, and for major changes, please open an issue first to discuss what you would like to change.

There is a Discord server badge, a sponsor link to the maintainer's GitHub profile, and a translation status badge pointing at a Weblate project for the repository, which is the community translation platform. The `.weblate` directory at the repository root is the Weblate configuration.

The release history is short: v0.1.6 on 2026-04-14, v0.1.7 on 2026-06-12, and v0.2.0 on 2026-09-11. The last push was on 2026-10-13 and the repository is not archived. A 0.2.0 version on a project that started at 0.1.x is a young project, and the version numbers reflect that.

## A modular Gradle layout with a separate translations layer

The repository layout shows a much more structured application than a typical single-module Android project, and the structure is the interesting part.

There is a `core/` directory, a `domain/` directory and a `presentation-core/` directory, plus a `presentation-widget/` directory, which is the separation of the Android app into UI, domain logic and shared core. The `core-metadata/` directory holds the extension metadata, and `source-api/` and `source-local/` define the interface a source implements and a local file source. The `data/` directory holds the data layer and `flagkit/` is a separate module, which by its name is a feature flag framework.

Then there are the internationalisation directories, and there are a lot of them. `i18n/` is the project's own translations, and then `i18n-aniyomi/`, `i18n-animiru/`, `i18n-ank/`, `i18n-kmk/` and `i18n-sy/` are translation sets inherited from the other forks in the family, with `ank` presumably the Anikku specific set and `sy` the SyncYomi one. Keeping each lineage's strings in its own module rather than merging them into one file means an update from one upstream does not conflict with another's, at the cost of several modules to load.

The `macrobenchmark/` directory is a Macrobenchmark module, used for measuring startup and runtime performance of the app. There is a `telemetry/` module, a `fastlane/` directory for release automation and store listing metadata, and a `buildSrc/` directory for shared Gradle build logic.

The build itself is Gradle with Kotlin DSL, with `build.gradle.kts` at the root, `settings.gradle.kts`, `gradle.properties` and the `gradlew` wrappers. The `AGENTS.md` and `CLAUDE.md` files at the root are the same kind of agent-instruction files that have become common in Android repositories, and there is a `CHANGELOG.md` and a `CONTRIBUTING.md`.

The `core-metadata/` directory being separate from the app is the structural decision that matters most for the fork's future, and the reason is that extension metadata is what the upstream community shares.

## What the fork inherits, and where that becomes a constraint

The honest limitation of this project is structural and it is worth stating plainly.

Anikku is a player whose catalogue is not in the app. It comes from sources that are installed as extensions, and the extension model means the app and the content it can reach are versioned independently. The README's own feature list shows the dependency in practice, since torrent support is described as needing the right extensions, and since the `Search for sources` and quick NSFW sources filter live in the Extensions, Browse and Migration screens.

That design gives enormous flexibility and it is the reason a whole family of forks exists. It also means the user, not the app, decides what the app can show. A user who installs a misbehaving extension has a problem the app cannot diagnose.

The `Update Error` screen is the visible acknowledgement of this. The feature list mentions an `Update Error` screen for migrating away from entries that fail to update, and a `to-be-updated` screen showing which entries are going to be checked with smart-update. Those screens exist because a source-side failure is a normal event in this architecture, and the app has to make it recoverable.

The `Mass-migration` feature, moving all your anime from one source to another at once, is the same lesson in a different direction. It is there because entries are tied to sources, sources change, and the user needs a way to carry their library across. The `Merge anime` feature, which combines separate anime and episodes into one entry, is related: the boundaries between entries are a property of the source, not of the work, and the user has to be able to correct them.

So the fork's own contribution is largely about making a source-driven system survivable. Categories, merge, mass-migration, error recovery and cross-device sync are all answers to the same problem, that in an extensible architecture the user needs authority over their own library.

## Apache-2.0, an active repository, and a family of upstream credits

The licence is Apache-2.0, with the `LICENSE` file at the repository root and a licence badge in the README pointing at it. That is a permissive grant with an explicit patent clause, so the code can be used in a commercial or closed-source context without an obligation to publish anything. This is a licensing observation rather than legal advice, and the `LICENSE` file governs.

The maintenance picture is current. The repository is not archived, the last push was on 2026-10-13, and the v0.2.0 release was on 2026-09-11, so the code and the release are close together.

What makes this project different from an ordinary Android app is the credit structure in the feature list. Every feature that is not Anikku's own is attributed. Aniyomi provides the player core. The features marked as from SY come from SyncYomi. Torrent support is credited to Diegopyl1209, Cast functionality to Animetail, grouping by tags to Kuukiyomi, and Discord Rich Presence to Animiru, Kuukiyomi and Animetail. The README also points at the maintainer's other app, Komikku, a manga reader, and says the remaining features come from the same maintainer's app for that.

That is a project built entirely on other people's work, credited openly, with the additions clearly separated from the inheritance. For a user, that separation is also a signal about where to look when something breaks. A problem with the player is an Aniyomi problem. A problem with the library organisation is an Anikku problem.

The Weblate translation setup and the Discord server are the community infrastructure, and the sponsor link to the maintainer's GitHub profile is the funding route the README offers.

## Conclusion

Anikku fits an Android user who watches anime through a source-and-extension setup and wants the library half of the problem handled properly, with categories, cross-device sync, backups and tracker integration rather than just playback. It does not fit someone who wants a self-contained streaming service, since the catalogue comes from sources installed as extensions rather than from the app, and it does not fit a team that needs a stable API, because the app is a 0.x line whose extension surface is still moving. Verify first that the source extensions you rely on work with the release you install, since the app and its extensions are versioned separately, that your tracker credentials are handled the way you expect, and that the preview channel's changes suit you, because the preview repository is where the next release is built.

## FAQ

### What is Anikku and how is it different from Aniyomi?

Anikku is a Kotlin Android anime player forked from Aniyomi. The player core, the mpv-android based player, the tracker integrations, categories and backups come from Aniyomi, while Anikku adds the library management layer, including categories, merging entries, mass-migration between sources, a feed tab, dynamic and custom categories and cross device library sync.

### Where do I download Anikku and what Android version does it need?

The stable build is on the main repository's releases page and the preview build is on the separate `anikku-preview` repository's releases page. The app requires Android 8.0 or higher.

### Which trackers and metadata sources does Anikku support?

Tracker support comes from Aniyomi and covers MyAnimeList, AniList, Kitsu, Simkl, Shikimori and Bangumi. Entry information can also be filled in from MyAnimeList, Kitsu, Shikimori, Bangumi and Simkl, and community recommendations are pulled from Anilist and MyAnimeList.

### How does Anikku handle sources that fail to update?

There is an `Update Error` screen for migrating away from entries that fail, and a `to-be-updated` screen showing which entries will be checked with smart-update. The `Mass-migration` feature also lets you move all your anime from one source to another at once.

### Can I sync my Anikku library across devices?

Yes, the feature list includes cross device `Library sync` with SyncYomi and Google Drive. There is also an in-app `progress banner` that shows library syncing, backup restoring and library updating progress.

## Sources

- [komikku-app/anikku on GitHub](https://github.com/komikku-app/anikku)
- [License: Apache-2.0](https://github.com/komikku-app/anikku/blob/master/LICENSE)
- [Project website](https://anikku-app.github.io)
- [README](https://github.com/komikku-app/anikku/blob/master/README.md)
- [Releases](https://github.com/komikku-app/anikku/releases)

---

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