Open-source project
Predidit/Kazumi avatar
Predidit/Kazumi

Kazumi: a Flutter anime client where the sources are XPath rules you write yourself

基于自定义规则的番剧采集APP,支持流媒体在线观看,支持弹幕,支持实时超分辨率。

29,944 stars893 forksDartGPL-3.0

At a glance

What is it?
Kazumi is a cross-platform Flutter app that scrapes streaming sites through user-authored XPath selectors instead of bundling a fixed catalogue. It is a rule engine with a video player attached, and that distinction decides who should install it.
Who is it for?
Adopt Kazumi if you are comfortable writing XPath selectors and want one Flutter client for Android, Windows, macOS, Linux and sideloaded iOS. Do not adopt it if you want a catalogue that works out of the box, because the app ships no content and every source is a rule you or someone else maintains.
Can I use it commercially?
Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
Is it still maintained?
Yes. The repository received new commits within the last day.
What is it written in?
Mainly Dart, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The problem Kazumi solves is source churn, not discovery

Streaming sites for anime move, rename their markup and disappear. An app that hardcodes a source list needs a new release each time that happens. Kazumi inverts this: the README describes it as a collection and online viewing program built on custom rules, where a rule is at most five selectors written in XPath syntax. When a site changes, the rule changes, not the binary. Rules can be imported and shared, and there is a separate repository, Predidit/KazumiRules, accepting community submissions. The audience is therefore narrower than the download page suggests. It is for people who will open a rule editor and read a site's HTML, or who will trust a rule someone else published. The README is explicit that no ads are inserted by the project and that ads seen during playback come from the video source, which tells you the app is a client pointed at third-party infrastructure rather than a service.

Five XPath selectors, a webview fallback, and a player that caches aggressively

The rule format is the whole architecture. According to the README, a rule is built from at most five XPath-based selectors, and the project credits XpathSelector as its foundation. That library is what turns a page into structured results the Flutter UI can render. Playback has two paths. The default is the built-in player, which the README says gives smoother playback and danmaku support. The alternative is a webview mode, enabled by turning off the built-in player option for a custom rule, which the README recommends when a rule can search but cannot play. That fallback exists because some sources use anti-hotlinking measures: the README states these can be handled by Kazumi but not by an external player, which is also why a few titles fail when handed off to an external player. Around the video itself, the app caches as much as it can into memory for smoother viewing, and the low memory mode in playback settings caps that cache. Upscaling runs through Anime4K, and the README's own troubleshooting says it is GPU-heavy: on a machine without a discrete card, pick the efficiency preset over the quality preset, and upscaling a low-resolution source costs less than upscaling a high-resolution one.

Platform coverage is wide, with two entries that need a caveat

The README lists Android 10 and above, Windows 10 and above, macOS 10.15 and above, Linux as experimental, iOS 13 and above, and HarmonyOS 5.0 and above. Two of those are not ordinary installs. iOS requires sideloading, and the README links to a dedicated documentation page for the procedure. HarmonyOS builds live in a separate branch repository, ErBWs/Kazumi, and also require sideloading. Linux has three distribution routes: Flathub, the AUR with kazumi for a source build and kazumi-bin for a binary package, and a .deb or tar.gz from Releases. The README answers a question about the Linux build lacking icons and tray support by pointing at the packaging: the .deb installs them, the tar.gz does not, because that format is intended for repackaging. Android is also on F-Droid. If your target is an iPhone or a HarmonyOS device, treat this as a sideloaded app with the update friction that implies, not a store install.

Getting it running: Releases, AUR, and a build that needs a clean network

The primary install path is the Releases tab on the GitHub repository, which is where the 2.3.x builds live. On Arch, the README gives two commands: yay -S kazumi to build from source, or yay -S kazumi-bin for the binary package, with paru listed as an equivalent. Flathub and F-Droid carry their own packages. Building from source is the part worth reading before you try it. The developer Q&A states that compilation needs a good network environment because, beyond Google-hosted Flutter dependencies, the project pulls resources from MavenCentral, GitHub and SourceForge. Contributors in mainland China are told to configure appropriate mirrors. That is a real setup cost, and it is the kind of thing that turns a weekend build into a debugging session. There is no configuration file documented in the README; the settings that matter, low memory mode and the built-in player toggle, are UI options in playback settings and rule settings rather than keys you edit by hand.

The rule engine is deliberately incomplete, and that is the main limitation

The rules Q&A contains the sentence that should shape expectations: XPath support is not complete, and only selectors beginning with // are supported. If your target site needs an absolute path or a more exotic expression, the rule will not work, and the README's advice is to model your rule on the provided examples. This is not a bug report, it is a stated boundary of the engine, and it means rule authoring is a constrained dialect rather than general XPath. The second failure mode is playback without search, or search without playback, which the webview toggle sometimes fixes and sometimes does not. The third is performance: upscaling is GPU-bound, and memory use during playback is high by design unless low memory mode is on. The fourth is legal and practical, and the README states it without hedging: usage must comply with local law, must not infringe third-party intellectual property, and cached data should be cleared within 24 hours, with use beyond that requiring authorization from the rights holder. If you want a tool that is indifferent to where its streams come from, this project is not that, and its own documentation says so.

Against a fixed-catalogue client such as Aniyomi-style source extensions

The closest comparison in this space is a client whose sources are packaged extensions installed from a repository, which is the model Aniyomi and its forks use. That approach gives you a list of sources that mostly work without you reading any HTML, and the extension author absorbs the breakage. Kazumi's rules are closer to configuration than to code: five XPath selectors, importable and shareable, editable inside the app. The trade is that you own the breakage. When a site changes its markup, an extension ecosystem ships an update and you tap install; with Kazumi you open the rule editor and fix the selector, or wait for someone to publish a corrected rule. In exchange, adding a source that nobody has packaged is a few minutes of work rather than a plugin project. The two models also differ in scope: Kazumi bundles danmaku through the 弹弹play open platform, metadata through the Bangumi open API, SyncPlay for watch-together, trace.moe for image-based identification, and media-kit for cross-platform playback. It is a full client, not a thin scraper, and the rule layer is what you are choosing when you pick it over an extension-based app.

GPL-3.0, bundled assets, and the cost of keeping up

Kazumi is licensed under GPL-3.0, and the README's disclaimer disclaims all warranties of fitness, reliability and accuracy, and limits liability for damages arising from use. If you fork it or ship a modified build, GPL-3.0 obligations attach to your distribution; that is a statement about the licence text, not legal advice, and anyone redistributing should read the licence itself. Two asset carve-outs matter more than people expect. The application icon is copyrighted by its original author Yuquanaaa and is used under a specific permission; the README states it is not freely usable and may not be copied, modified or distributed without the author's explicit authorization. The embedded font is Mi Sans, owned by Xiaomi. A fork that keeps the icon is on shaky ground even though the code is GPL. On maintenance, the release cadence visible in the supplied material is roughly weekly through August and September 2026, with 2.3.1 on 2026-09-07 and the last push on 2026-09-10, so the app itself moves quickly. The rules do not move with it. Expect to re-check your selectors whenever a source site is redesigned, and expect the webview fallback to be the first thing to try when playback breaks.

Editorial conclusion

Adopt Kazumi if you are comfortable writing XPath selectors and want one Flutter client for Android, Windows, macOS, Linux and sideloaded iOS. Do not adopt it if you want a catalogue that works out of the box, because the app ships no content and every source is a rule you or someone else maintains. Before installing, open the rule editor and confirm your target site parses under the documented restriction that only selectors beginning with // are supported, then check the video source for the ads the README warns about.

Official sources

  1. License: GPL-3.0
  2. Predidit/Kazumi on GitHub
  3. Project website
  4. README
  5. Releases
Community notes

Community notes