pure_live_TV: a remote-control live TV app for Android TV

A TV app whose only input is a remote control

The project describes itself in Chinese as a Flutter based open source multi platform live aggregation player designed for televisions and large screens, and in English as a third-party live stream aggregator built with Flutter for Android TV. The tagline in the README is the whole design brief: one thing only, watching live streams on a television with a remote, comfortably, with no touch screen needed at any point.

The interaction model is spelled out. Direction keys change channel, the OK button summons the bottom control bar, and a long press follows a streamer. The control bar and the side panel use an index selection model, so the highlight always stays in the remote's hands, and the README states the reason plainly: there is no focus you have to hunt for. Every screen is designed for D-pad operation.

The scope is large and explicit. The README counts 34 live sites plus IPTV custom sources, which is 35 adapters in total, made up of 18 domestic platforms and 16 overseas ones. The domestic list includes Bilibili, Douyu, Huya, Douyin, Kuaishou, YY Live, NetEase CC, AcFun, Miaoe FM, Inke, Kilakila, Xiaohongshu, Weibo Live, JD Live, Kugou Live, Baidu Live, Liujianfang and LOOK Live. The overseas list covers Twitch, SOOP Live, YouTube Live, TikTok LIVE, Kick, CHZZK, Bigo Live, 17LIVE, LiveMe, SHOWROOM, niconico, Picarto, TwitCasting, FC2 Live, Steam Live and PandaTV.

The platform layer is shared with the mobile version, pure_live, and the README says the section lists, search, danmaku and viewer-count conventions stay consistent between them. The mobile clients are pointed elsewhere, so this repository is explicitly the television half of a two-repository project.

Six APKs and the decision of which one to install

The distribution section is unusually practical, and it is the part that will decide whether your first install works.

Each release ships six packages, split by CPU architecture and by renderer. The architecture table maps arm64-v8a to most televisions and boxes with a note to prefer it, armeabi-v7a to older 32 bit boxes, and x86_64 to emulators. The renderer table then splits each into an Impeller build, described as the new renderer and the one to try first, and a Skia build, described as the old renderer and the one to use when the picture is broken, the screen is black, or the text is blurry.

The system requirements are equally concrete. A television or box needs Android 7.0, API 24, or newer, together with a paired remote or air mouse. Android 5.0 and 6.0 boxes are told to download the old v2.0.20 release from the release list, because the new version no longer supports them.

Some smaller operational details are worth knowing. The application package name is com.mystyle.purelive.tv and it uses a fixed signature, so an install over the top of an existing one works. First install requires allowing installation of unknown apps in system settings. There is in-app updating through Settings, then About, then the online update entry, which detects the current architecture and renderer and offers several mirror sources to download from, and the release page files have a SHA256 you are asked to check after downloading.

The troubleshooting table at the end of the documentation is the most useful artifact in the README. A parse error on install means the wrong architecture was chosen. A not installed prompt with no error means the system is below Android 7.0, so use v2.0.20. An antivirus blocking the install is down to the fact that open source software has no signature whitelist, and the README's advice is to decide for yourself and allow it. A black or garbled picture means switching either the renderer or the playback kernel, and a failed online update means trying a different mirror or going to the releases page directly.

Four playback kernels and a renderer switch for when things break

The player architecture is built around the assumption that one decoder will not handle every stream a platform serves, and the user should be able to change it.

The settings screen can switch the playback kernel at any time, and the README gives four of them. MPV, through media_kit, is the default. FVP, through libmdk, bundles a newer FFmpeg and platform hardware decoding, and exists to catch the old packaging that MPV will not play, with the example of codec-id-12 HEVC in FLV. EXOPlayer and IJKPlayer complete the list. The stated triggers for switching are a black screen, stuttering, or a hardware decoding compatibility problem.

Switching the kernel automatically refetches the playback address, and the README says expired stream addresses will not make the switch fail. That is a small detail with a large effect on the experience, because a stream URL that has gone stale is the most common reason a live player appears broken.

The renderer switch works the same way and for the same class of problem. The Impeller and Skia split is not about aesthetics, it is about compatibility, and the documentation gives you the diagnosis: if text is blurry and the picture is soft while the interface itself looks correct, switch to the Skia build to test whether it is an Impeller compatibility problem. If you have a black screen with sound, change the playback kernel instead. If an older device stutters, enable the dense layout and reduce the number of danmaku comments in the general settings.

That is a coherent troubleshooting model. Render problems and decode problems have different causes, and the project gives you one switch for each.

The pure audio mode is worth mentioning for a different reason. The bottom bar of the playback page switches to an audio only mode that does not render the picture but keeps the decoder warm, so switching back restores the image immediately. Combined with the timed playback stop described in the features, it is aimed at leaving sound running while falling asleep.

IPTV sources, danmaku and the phone as a remote

Beyond the platform aggregation, three subsystems carry most of the daily use.

The IPTV side supports importing M3U and M3U8 network and local live sources, with subscription management and automatic sync, organised by section and platform. The documentation describes the path as Settings, then IPTV, then adding a subscription source, with a network address or a local import, and automatic sync as an option.

The danmaku system has a large number of knobs: on and off, opacity, font size, speed, display area, maximum line count, outline, and a uniform style. Keyword blocking and user blocking are managed separately, and can be maintained in bulk from a mobile web page after scanning a code. There is a two-level duplicate filter, exact and similar, and the README claims it does not leak across rooms or build up a backlog.

The phone remote is the most unusual piece. After scanning a code to pair with the television, a phone browser can control playback, manage danmaku keywords and blocked users, manage cookies for platforms such as Bilibili, Douyin and Douyu, edit tags, import IPTV sources and adjust sync settings. The cookie handling is worth noting: the credentials stay on the local machine, per the compliance statement, and the same statement says there is no intermediary proxy and no data forwarding, all requests go straight to the official interfaces, and there is no advertising and no tracking.

Data management covers local backup and restore with a configuration format that interoperates with the Windows version, plus local network sync between television, phone and computer for favourites, history and settings.

One item in the feature list needs its stated caveat. Watching high definition Bilibili streams requires being logged in, because of platform restrictions. You sign in through Settings, then Accounts, by scanning a code or pasting a cookie, and the credentials are kept on the machine.

Building the APKs yourself

The local build section is short and gives you the two commands that matter.

The project uses Flutter 3.47.x on the stable channel, with AGP 9 and Java 17, and after cloning you run flutter pub get and then one of two build commands:

flutter pub get

# Impeller 渲染器（默认推荐）
flutter build apk --release --flavor impeller --split-per-abi \
  --target-platform android-arm,android-arm64,android-x64

# Skia 渲染器（兼容模式）
flutter build apk --release --flavor skia --split-per-abi \
  --target-platform android-arm,android-arm64,android-x64

The output lands in build/app/outputs/flutter-apk/. Pushing a v* tag triggers GitHub Actions to build and publish a release automatically, which is how the six-package matrix is produced.

The split-per-abi flag is what generates the per-architecture packages, and the three target platforms in the command cover the arm, arm64 and x64 rows of the architecture table, which is why a single local build reproduces the same choice set the release page offers.

The repository layout shows a conventional Flutter project with some additions. There is lib for the application code, android and ios directories, a plugins directory for the platform plugins, a web_remote directory for the phone browser control, a tool directory, a test directory and a docs directory. There are also several files that suggest a specific workflow: build.yaml, distribute_options.yaml, analysis_options.yaml and devtools_options.yaml for the build and distribution pipeline, pure_live_rename.py for renaming the project during a fork, watch-git.ps1 for watching the upstream repository on Windows, and a run.MD that documents the local run steps.

That last file, pure_live_rename.py, together with the .gitmodules file, tells you something useful about how this project is maintained: the code is shared with or derived from the mobile pure_live repository, and there is tooling to rebrand the tree for the television variant.

Licence, legal posture and who should not deploy this

There is a discrepancy in the licence that you should resolve before shipping anything, and the project itself is unusually direct about the legal position of what the app does.

The README's compliance section states that the project is non-profit open source software following the GPL-3.0 agreement, for personal study and technical exchange only, and not for commercial use. The project level licence field says AGPL-3.0. Those are different licences with different obligations, and the LICENSE file in the repository is the version that counts. If you are considering anything beyond personal use, read that file rather than the badge.

The behavioural statement is the part worth reading carefully, because it defines what the app is and is not. The project provides no paid tier bypass, no video cracking and no stolen stream services; high definition streams require that you hold a legitimate account on the corresponding platform. All live content remains the property of the original platform and the software is a technical aggregation and playback tool. The privacy statement says the application collects no user personal data, that all requests go directly to the official interfaces with no intermediary proxy or data forwarding, that cookies are used only for local authentication and are never uploaded to any server, and that there is no advertising and no tracking. If you believe the project infringes your rights, the README asks you to file a GitHub issue.

On maintenance, the repository is not archived and the last push was on 2026-10-06, with releases v3.0.7 from 2026-09-27, v3.0.6 from 2026-09-26 and v3.0.5 from 2026-09-25, so the 3.0 line is being patched weekly. The primary language is Dart, and the build depends on Flutter 3.47, AGP 9 and Java 17, which is a current and demanding toolchain.

The realistic use is a personal television box, with the phone acting as a second screen, and the honesty of the compliance section is part of why the project is usable at all. What it is not is a component you can embed in a commercial product, which the non-commercial statement rules out and the AGPL classification in the metadata would also constrain.

Editorial conclusion

Adopt pure_live_TV if you watch live streams on an Android TV box and want one remote-driven interface across Chinese and international platforms, and you are prepared to pick the right ABI and renderer build. Do not adopt it as a general media player, since it is built around live platform aggregators, and skip it if you need a commercial deployment, because the README states the project is non-profit open source for personal study and technical exchange. Verify first that your box is arm64-v8a on Android 7.0 or newer, that you install the Impeller build and keep the Skia one as a fallback, and that you read the licence file, since the repository metadata and the README name different licences.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. liuchuancong/pure_live_TV on GitHub
4. README
5. Releases