bilibilitv1.6.6-repair: patching the old Bilibili TV client back to life

The problem: a TV interface that upstream abandoned, and an API that kept moving

The 1.6.6 release of the Bilibili TV client is the version this project is built around, and the README opens with the author's reason: the 1.6.6 interface is simply more comfortable than what came later. The problem is not the interface. It is everything underneath it. Bilibili's endpoints change often, and an old client that hardcodes old endpoints degrades: the README's version history reads like a running battle with those changes, from swapping in a TV video source in v1.0 to replacing the whole source with the web source from bilibili-API-collect in v3.0, then falling back to a TV-first, web-second priority in v4.0 because, in the author's words, the interfaces change too frequently. The project is for people who own an Android TV box or TV, prefer the old layout, and are willing to compile an APK rather than install one. It is not a distribution: there is no release APK in the top-level listing, only source trees, a build script and an existing mybv.apk artifact.

How the repair works: Smali patches, swapped sources and a Java-layer rewrite

The repository is a decompiled APK tree plus a reference build. mybv/ holds the patched Smali, bv0/ holds the original for comparison, and the README tells you to run diff -r mybv bv0 to see what changed relative to the original. Two files carry the source-swapping logic: mybv/smali/bl/ql.smali for video sources and mybv/smali/bl/qh.smali for episode sources. That is the core mechanism. The project does not reimplement the client; it edits the compiled Smali of the original and rebuilds it. The version history shows how far that editing goes. v1.0 reused the libbili.so from a signature-stripped build because the original appears to have signature verification. v5.0 moved part of the work up to the Java layer, rewriting the live source logic in Java, locking the original quality and supporting ijk decoding only, with a rough implementation of live danmaku. v6.0 switched video and episodes to dash-format web sources and dropped HEVC support, which v9.0 partially reversed by allowing HEVC software decoding. Later versions add playback speed control, like and coin actions, cloud playback progress, a channel-switching experiment during live streams, and a customizable package name. The direction of travel is clear: the Smali patch is the substrate, and each release adds behaviour the 1.6.6 client never had.

Building the patched APK on Linux with apktool and build.sh

The README gives the build environment explicitly. It targets a Debian-style system with apktool, signapk and OpenJDK 8, and it pins javac to the Java 8 binary, which matters because apktool and Smali tooling of this vintage do not behave well on newer JDKs. Run these two commands first, exactly as the README lists them.

sudo apt install apktool signapk openjdk-8-jdk
sudo update-alternatives --set javac /usr/lib/jvm/java-8-openjdk-amd64/bin/javac

With the toolchain in place, the normal build is a single script call. The repository's build.sh is the entry point, and the README lists no other required step.

./build.sh

There is a second form for a custom package name, which the README documents as ./build.sh -s 包名, where the argument is the package name. The README immediately warns that changing the package name may cause runtime errors in parts of the program, so treat the default build as the supported path and the renamed build as an experiment. The repository ships platform.pk8 and platform.x509.pem at the top level, which is what signapk uses to sign the rebuilt APK. After the script finishes you should have a signed APK to install on the TV device. The README does not document what build.sh prints on success, and it does not document rollback, so keep the original APK before you install anything.

Where this breaks: signature checks, source drift and untested membership code

The first limitation is structural. The original client appears to carry signature verification, which is why v1.0 had to borrow libbili.so from a signature-stripped build. Any rebuild that touches native code inherits that constraint, and the README does not describe a general way around it beyond that one substitution. The second is source drift, and it is ongoing rather than solved. v3.0 forced web sources so that logged-in users could get 1080P. v6.0 forced dash web sources and lost HEVC, which meant no 8K. v9.0 allowed HEVC software decoding to bring 8K back. The todo list contains one checked item about web sources returning only 720P after June 1, and the v4.0 note says the author is picking whatever source gives acceptable quality because the interfaces change too frequently. If Bilibili changes an endpoint tomorrow, this project has no contract protecting it. The third is the membership warning at the top of the README. Bilibili changed the membership agreement on 2025-01-09 so that one account can use membership services on at most two devices at the same time, and the README states plainly that the membership-related modules in this software are untested and should be used with caution. That is not a small caveat. It means the paid features are the least verified part of the build. This is also the wrong tool if you want a maintained, installable client: there is no published APK release to download, and every update requires you to rebuild.

What to compare it against: a current official client, or a different patching approach

The obvious alternative is the current official Bilibili TV client. The difference is not just features, it is who owns the compatibility problem. The official client is updated by Bilibili when endpoints change; this project updates when the author has time, and the version list shows gaps of roughly a year between v8.0 in October 2023, v9.0 in May 2024 and v10.0 in April 2025. Choosing the official client means accepting the newer interface, which is exactly what this project exists to avoid. A second alternative is a different community patch of the same 1.6.6 base. The README names two: a signature-stripped version and a version it calls 改版4, whose TV source v1.0 borrowed. The difference in approach is that this project keeps iterating on one tree and layers fixes on top, while those builds are referenced as one-off sources. If you only need a working APK and not the extra features, a prebuilt patch is less work than setting up apktool and OpenJDK 8. If you need the specific additions here, channel switching, danmaku filtering, custom CDN, custom splash wallpaper, you have to build this one.

Maintenance, licensing and the cost of keeping up

The repository is not archived and the last push was on 2026-09-02, so the tree is being touched. That is not the same as a support commitment. The release cadence in the README is one release per year for v8.0, v9.0 and v10.0, with v11.0 still labelled test. Several v10.0 entries are explicitly marked experimental: video filtering, CC subtitles implemented through advanced danmaku, danmaku filtering, custom CDN, video seeking and custom splash wallpaper. Experimental means you should expect to debug them yourself. Upgrade cost is real. Each new version is a new Smali patch, so upgrading means re-running the build after pulling, and if you changed the package name with ./build.sh -s, you carry the runtime errors the README warns about. The repository states no license. That is a gap you have to resolve before redistributing anything built from it, and the README's disclaimer forbids promoting the project on Bilibili itself, on WeChat public accounts, or for profit, and describes automated evidence collection and reporting against those who do. The disclaimer is the author's stated position, not a legal opinion, and it does not substitute for a license file that is not there.

Editorial conclusion

Adopt it only if you are comfortable decompiling and rebuilding an APK yourself, and only for personal viewing on a device you control; the README's own warning about the membership agreement and the untested VIP modules means anyone relying on paid membership features should stay away. Before building, read the wiki and the troubleshooting discussion, check that your Java 8 toolchain matches the build instructions, and verify the license, which the repository does not state.

Frequently asked questions

Official sources

1. Issues
2. qidian55/bilibilitv1.6.6-repair on GitHub
3. README
4. Releases