Baka, a Flutter client for rule-driven anime streaming

A client that resolves sources through rules, not a service

Baka is a Flutter application for aggregating and playing anime across platforms. Its own description of itself is a cross-platform anime aggregation, media playback and danmaku client, and the mechanism it uses to find and play anything is described as a rule-driven video source system that handles search, detail pages and playback parsing.

That architecture is the whole design, and it is a legal boundary as much as a technical one. The project states plainly that the repository contains the complete source code, and that Baka itself does not host, upload, store or distribute video content; the content and services a rule reaches are provided by the corresponding third parties. So what you are looking at is a parser and a player, not a streaming platform. The rules describe where to look and how to read what is found there.

The functionality list is broad for a client of this kind. There is a player built on `media_kit` with episode selection, source switching, playback speed, subtitles and progress tracking. Danmaku can be loaded, sent, blocked and stored as local files. MP4 and HLS content can be cached offline with a download task manager, and there is Magnet and Torrent downloading with play-while-downloading. DLNA casting is supported, along with local folder and WebDAV media libraries, local play history with sync for signed-in users, and separate interfaces for Windows, Android, macOS, iOS and Android TV.

The audience is a viewer who watches on more than one platform and is tired of separate applications per site, and it is a developer who wants to add or fix a source rule.

One thing the project says about itself deserves repeating. It is a general-purpose media player and rule parsing tool that does not provide content licensing, and users are expected to confirm that the content, sites and network services they access comply with local law and the applicable terms of service.

Rules are a data format, and they live in another repository

The rule system is the project's most distinctive engineering decision, and its packaging tells you how carefully it is versioned.

Built-in rules ship inside the application, and community rules are maintained in a separate repository, AniBakaRule, and fetched through a rule center. The distinction between bundled and community rules matters operationally, because a user can add rules that the maintainers never saw, and the quality of the experience depends on that third-party content being correct.

The synchronisation between the two is disciplined. The built-in sources and the rule repository use the same integer `rev` from `anx-rulehub/2`, and that revision is independent of the application version. To update the bundled sources you sync the rule files and the version manifest together from the rule repository and do not change the version number separately. The synchronisation result lands in `assets/rules/`, where `index.json` records the corresponding version and a content digest, and a test checks that the version manifest matches the packaged content.

The two commands that do the work are in the repository.

dart run tool/sync_bundled_rules.dart ../AniBakaRule
dart run tool/sync_bundled_rules.dart ../AniBakaRule --check

The second form checks rather than writes, which is what a CI job wants. Built-in sources that the rule repository has not registered use `rev: 0`, so an unregistered source is visible as such rather than silently treated as current.

This is a mature way to handle the problem, and it is also the answer to the obvious objection to a rule-driven client: the rules are versioned, digested and tested rather than being a pile of scraped URLs committed into the app. The rules still depend on third-party site behaviour, and the documentation is explicit that those interfaces and page structures can change at any time, so a rule that works today can break tomorrow with no change on your side.

Pinning the toolchain with FVM before touching the code

The build setup is conventional Flutter, with one detail that matters: the Flutter version is pinned in a `.fvmrc` file, and the project documentation recommends using FVM to match it.

The environment requirements are explicit. Flutter `3.44.9`, with the version fixed through `.fvmrc`, and FVM as the recommended way to get it. Dart `>=3.8.0 <=4.0.0`. The Flutter desktop or mobile toolchain for whichever target platform you are building. And for Android builds specifically, JDK 17 and Android SDK 36.

Getting the source and running it takes four commands.

git clone https://github.com/AniBakaBaka/AniBaka.git
cd AniBaka
fvm install
fvm flutter pub get
fvm flutter run

The `fvm install` step is the one that reads the pinned version and installs it, and the documentation notes that if you do not use FVM you should make sure your current Flutter version matches `.fvmrc` and then drop the `fvm` prefix from the commands.

The release builds follow the same pattern with a target flag.

fvm flutter build apk --release
fvm flutter build windows --release
fvm flutter build macos --release
fvm flutter build ios --release --no-codesign

Multi-platform release packages are produced by the project's GitHub Actions using Fastforge, with the configuration in `distribute_options.yaml`. Prebuilt binaries are published on GitHub Releases, and the documentation tells you to pick the package matching your system and CPU architecture.

The dependency story has one wrinkle worth knowing before you touch the lock file. Two packages, `media_kit_video` and `screen_brightness`, are pulled as git dependencies pointing at organisation forks, with `pubspec.yaml` fixing the commit and `pubspec.lock` recording the resolution. The documentation is clear that running `fvm flutter pub get` is enough and that there is no need to copy a `third_party` directory or modify the pub cache. The forks carry the Windows player enhancement patch, including a CMake flag `MEDIA_KIT_VIDEO_ENABLE_DLSS` and the GPU backend under `windows/runner/dlss_realtime`, and a change that removes the Windows brightness plugin registration while keeping the upstream Dart API and the other platform implementations. Updating a patch means merging it into the fork's `main`, then updating the `ref` in `pubspec.yaml`, running `fvm flutter pub get` and committing the lock file.

On Windows, the graphics features are the differentiator

Two Windows-specific capabilities are worth separating from the cross-platform feature list, because they are the reason a Windows user would pick this client over a simpler one.

The first is Anime4K real-time quality enhancement, which the feature list names for Windows. The second is DLSS 5 experimental video enhancement, documented separately. The documentation describes it as a laboratory switch that can enable NVIDIA neural rendering, 2x super-resolution and frame generation for all built-in playback, and it applies only to the built-in player. The word experimental is doing real work in that sentence, and the separate documentation page is where the caveats live.

The reason the enhancement is scoped to the built-in player is structural. These are GPU-side processing pipelines that need to sit in the video decode and render path, and the built-in player is the one the project controls. The same is true of the DLNA casting feature and of the download pipeline, they are features of this client's own playback stack rather than of the source sites.

The player itself is built on `media_kit`, and the feature list names what it supports: episode selection, source switching, playback speed, subtitles and playback progress. Source switching is a rule-driven capability in the sense that the rules describe multiple sources for the same episode, and being able to move between them when one is down is the practical value of the whole rule system.

For a non-Windows user, none of this applies, and the client is a straightforward Flutter media app with danmaku, downloads, casting and a local library.

The network surface is documented down to the endpoint

Privacy documentation of this quality is rare, and this one is specific enough to be checked rather than taken on trust.

The app can enable DoH and ECH separately under the network settings, both off by default and both requiring a restart to take effect. DoH uses the RFC 8484 DNS message format with a default endpoint of `https://1.1.1.1/dns-query`. With ECH alone, the ECH configuration is fetched through that service for HTTPS records while IP addresses still resolve through the system DNS. With both enabled, IP addresses resolve through the service as well, and sites that publish no ECH configuration continue to use ordinary HTTPS. The generic implementation lives in the organisation's `ech_http` repository, which keeps the upstream project's history, and AniBaka references it by a fixed git commit. The native build notes are in that repository's `ANIBAKA_CHANGES.md`, and the first build downloads native dependencies that are verified by SHA-256.

The endpoint list is equally explicit. `www.anibaka.com` is the default community API and can be replaced in the app's server settings. `version.anibaka.com` and `app.anibaka.com` serve version and download information, and `bgm.anibaka.com` and `p1.anibaka.com` are Bangumi metadata proxies. The rules repository is fetched through a GitHub acceleration node by default, falling back to jsDelivr and then GitHub. Third-party sites declared in each rule file are only accessed during the corresponding operation, such as search, viewing details or playing.

One request happens on every start: the app sends an anonymous install identifier to `https://dau.anibaka.com/track` to count daily active installations per platform. The identifier is generated locally on first run using a secure random number, has the form `install_<platform>_<random>`, and is stored in local settings and reused afterwards. The report contains no account token, username or hardware identifier, and the implementation is in `lib/services/dau_tracker.dart`.

The documentation closes the section by pointing out that users can review the concrete requests and data fields in the source, and that login, comments and history sync send the data needed for those operations to the chosen community server.

Skipping openings and endings, with a two second tolerance

The auto-skip feature is more careful than the name suggests, and the details are the interesting part.

You turn on smart skip in the player settings, and the player jumps to the end of the current episode's OP and ED intervals. Where the data is missing, the identity is unclear or the version does not match, playback continues normally instead of guessing. A skip can be undone within five seconds, and a post-ending extra scene keeps playing.

Automatic binding uses a Bangumi ID and an explicit episode number that already exist in the playback metadata. When all you have is a title search result or a collection number, the documentation asks you to bind the specific episode in the annotation panel first.

Public timestamps come from AniSkip, linked to MyAnimeList entries through BangumiExtLinker, and they are only used automatically when the entry and episode are unambiguous and the actual duration differs from the reference duration by no more than two seconds. That tolerance is the design: the same total duration can correspond to different cuts, so a near match is trusted and a mismatch is not.

Manual annotations are stored on the machine and can be shared proactively after signing in. Two other users confirming an annotation is enough for it to be used for automatic skipping on the current source, and two reports pause it. Changing source, line, or the HLS ad-removal result re-runs the matching, and a filtered timeline only uses annotations confirmed on that version.

Sharing requires a matching backend. The documentation says the new interface needs a supporting backend, and that old servers can still use local annotations. The same split applies to the apply-to-all-episodes feature, where OP and ED can each be applied across the series in one click, existing per-episode calibration takes priority, intervals beyond the video length are not used, and episode one keeps its opening and ending.

Version 5.2.x, GPLv3, and a mixed signing story

The release cadence is fast. The recorded releases are 5.2.2 in October 2026, 5.2.1 earlier in the same month and 5.2.0 at the start of the month, and the last push to the repository was on 2026-10-21. The version strings carry a build number suffix, 5.2.2+1017 for example, which suggests a build counter layered on the release number.

The licence is GPL-3.0, with a LICENSE file at the top of the tree and a THIRD_PARTY_NOTICES.md alongside it for the third-party components. The project also states that it is provided under the GPLv3 as-is, without warranty, and that the availability, accuracy, security and copyright status of third-party sites is outside its control. If you intend to redistribute the app or a derivative work, that copyleft term is the fact to check first, and it is a different answer from the permissive licences most media clients carry.

Signing is inconsistent by platform and the documentation says so. The iOS artifacts are not signed and have to be signed by whoever installs them, with the specific status for each release described in its release notes. The Windows artifacts are code signed through SignPath.io, with the certificate provided by the SignPath Foundation, which is what makes free code signing on Windows possible for the project at all.

The maintainership picture is worth stating plainly rather than dressing up. The project is not archived, the last push was on 2026-10-21, and the 5.2.x line is moving. The caution is not about the client code but about the dependency on rule repositories and on third-party site behaviour, which no amount of activity in this repository can control.

The contribution rules in the documentation are sensible and worth reading before opening a pull request: keep feature changes scoped and avoid unrelated formatting or generated file changes, add tests where possible, run static analysis and the relevant tests before submitting, and when reporting a broken source, include the rule name, the reproduction keyword and the failing stage, and never commit personal cookies, tokens or other sensitive data.

Editorial conclusion

Baka suits a viewer who wants one cross-platform client instead of a separate app per streaming site, and a developer who wants to read and contribute to an open rule set for those sources. It does not suit a team that needs a licensed content catalogue, since the project states it does not host, upload, store or distribute video and that the third-party services a rule reaches are operated by others. Verify first that the rules you need exist and still work, since the documentation states that third-party site interfaces and page structures can change at any time, and check the signing story for your platform, because the iOS artifacts ship unsigned while Windows artifacts are signed through SignPath.io.

Frequently asked questions

Official sources

1. AniBakaBaka/AniBaka on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases