BBZQ: a Kotlin Xposed module that strips Bilibili's promotional surface

What BBZQ removes, and who is expected to run it

BBZQ is an enhancement module for the Bilibili Android client. Its README describes the goal as removing unnecessary content and tuning the core experience, and the feature list backs that up: splash ad cleanup, recommendation-feed filtering, comment-section trimming, download thread control, and a sponsor-segment skipper. Nothing here adds new ways to watch video. The module subtracts.

The intended user is someone who already has an Xposed-compatible runtime. The README's usage steps assume a framework supporting libxposed API 102, a scope containing Bilibili, and a reboot of the target app. There is no standalone mode that works on a stock, unmodified phone without one of those two paths.

The second path is the no-root route. BBZQ integrates NPatch-Remote-API, and the README recommends NPatch v1.0.7 or higher for that setup. In this mode you open the BBZQ app from the launcher, change settings there, and the configuration syncs both ways through NPatch's Remote Store. That is a real architectural decision, not a checkbox: it means settings do not have to be re-patched into the host app each time you toggle something.

Version support is narrow on purpose. The README states the module only adapts to Bilibili 9.0.0 and above, including the probability build. The old international white-icon release is explicitly out of scope, as is anything before 9.0.0. If you are pinned to an older client, this project is not for you.

How the module hooks into the host: entry point, scope and settings

The registration mechanism is visible in the repository structure. BBZQ declares its entry through META-INF/xposed/java_init.list, and the README names io.github.bbzq.BbzqModule as the core logic entry. That is the standard libxposed shape: the framework reads the init list, instantiates the named class, and the class installs hooks against the host process.

The settings UI is embedded in the Bilibili app itself, reached through 我的 → 设置 → 关于哔哩哔哩 → BBZQ 设置. That placement is the module's main structural risk. The entry depends on the host's settings page layout, and the README says outright that after a major host version update, adaptation may not arrive promptly. In other words, a Bilibili release can break the way you reach the switches even when the hooks themselves still work.

One feature has a documented data flow. The 空降助手 (sponsor-segment skipper) uses the BilibiliSponsorBlock community database. Segment data is looked up by the SHA-256 prefix of the video's BV number against the bsbsb.top API, results are cached for 5 minutes, and matching is limited to the cid of the current part. The README notes the feature is off by default and its entry point is hidden by default. Ten categories are supported, including sponsor, selfpromo, interaction, intro, outro, preview, music_offtopic, poi_highlight, filler and exclusive_access.

The rest of the feature list is filtering and interception rather than networked logic: card-type filters, keyword blocking on titles, tab filtering, component-level hiding, and player-layer ad suppression.

Installing BBZQ and enabling the first filter

The README gives six usage steps. Install the module APK, enable it in an Xposed framework that supports libxposed API 102, add Bilibili to the scope, restart the target app, then open 我的 → 设置 → 关于哔哩哔哩 → BBZQ 设置 and turn on what you want. If you are going the no-root route, the recommended path is NPatch v1.0.7 or higher, with settings changed from the standalone BBZQ app and synced through NPatch's Remote Store.

Building from source needs JDK 21, Android Gradle Plugin 9.2.1, Kotlin 2.4.10 and Gradle Wrapper 9.4.1. A debug build is one command:

./gradlew assembleDebug

The release variant is the other:

./gradlew assembleRelease

After the module is active and the host restarted, the first useful thing to toggle is the recommendation-feed cleanup. Open BBZQ 设置 and enable 移除首页推荐广告, which the README describes as filtering large banners, in-feed ads and promotional videos out of the recommendation stream. If cards still appear, the settings entry is the first thing to check, not the filter: a missing entry means the host settings page moved and the module never got a chance to draw its UI.

A second low-risk switch is 跳过开屏广告, which clears the splash ad response at launch. Both are visible effects, so they are easy to confirm without digging into logs.

The HMA warning is the sharpest limitation in the README

The README carries a warning block that is unusual in its specificity: do not enable hidden-app lists for either 哔哩哔哩 or BBZQ in app-hiding modules such as Hide My Applist (HMA). The stated consequence is that features stop working or the app crashes, with two issue links as references. This is a real conflict, not a preference. App-hiding tools work by interfering with package visibility, and an Xposed module that needs to resolve and hook the host package is directly in the path of that interference.

Three other limits are listed under 预期限制. The old international white-icon build is no longer adapted, and neither is anything before Bilibili 9.0.0. The settings entry depends on the host's settings page structure and may lag behind major host updates. Region unlocking is explicitly not planned.

That last point matters for expectations. A user coming from other Bilibili modules may assume region switching is part of the package. It is not, and the README says it is not on the roadmap. If region unlocking is your reason for installing a module, BBZQ is the wrong tool regardless of how many of its filters you would use.

There is also a build-level limit worth noting: the README does not document rollback. If a toggle causes a crash, the documented recovery path is not spelled out, so the practical fallback is disabling the module in the framework and restarting the host.

BBZQ versus BilibiliSponsorBlock: overlapping features, different scope

The clearest comparison point is BilibiliSponsorBlock, which BBZQ credits as the source of its segment database. BilibiliSponsorBlock is built around one job: crowd-sourced segment skipping, with its own categories and its own submission flow. BBZQ borrows that data through the bsbsb.top API and folds it into a much wider module.

The difference in approach is scope and dependency. BBZQ does not maintain the segment database; it queries it by SHA-256 prefix of the BV number, caches for 5 minutes, and matches only the current part's cid. That means the skipper's accuracy is inherited from a third-party service, and BBZQ's own code is not where segment quality is decided. If you care about contributing segments or controlling which categories exist, the upstream project is the place to look.

What BBZQ adds is everything around the video: feed filtering by card type, title keyword blocking, tab removal, comment-section trimming, download thread control, and the 我的 page customizations such as hiding the 大会员 entry while optionally keeping its placeholder space to avoid layout jumps. A single-purpose segment skipper does not attempt any of that.

The trade-off is maintenance surface. A module that hooks the feed, the player, the comment section and the settings page has more places to break when the host ships a new version, and the README already flags settings-page drift as a known risk. The narrower tool has fewer failure points.

Licence, build stack and what upgrades cost you

BBZQ uses the Mulan Public License, version 2 (Mulan PubL v2), with the full text linked from the repository. The GitHub metadata reports the licence as NOASSERTION, which means the platform could not map the file automatically; the README and the badge both name Mulan PubL v2, and the LICENSE file is at the repository root. If you plan to redistribute a modified build, read the actual licence text rather than the badge, since Mulan PubL v2 has its own conditions and this is not legal advice.

The build stack is current and pinned: JDK 21, Android Gradle Plugin 9.2.1, Kotlin 2.4.10, Gradle Wrapper 9.4.1. Pinning the wrapper means a contributor does not have to guess the Gradle version, and the JDK 21 requirement is the first thing that will bite anyone on an older toolchain.

Upgrade cost is driven by the host, not by BBZQ. The last push to the repository was on 2026-09-17, and releases v1.4.1, v1.4.0 and v1.3.0 landed on 2026-09-12, 2026-09-11 and 2026-09-01 respectively. That cadence suggests the module tracks Bilibili releases, but the README's own limitation list says adaptation after a major host update may not be prompt. So the practical upgrade question is not whether BBZQ ships, it is whether it has caught up with the Bilibili version you just installed. Check the release notes against your host version before updating either side.

Editorial conclusion

Adopt BBZQ if you already run a libxposed API 102 framework, or NPatch v1.0.7 or higher without root, and you are on Bilibili 9.0.0 or newer. Skip it if you need region unlocking, use the old white-icon international build, or rely on Hide My Applist to hide Bilibili, since the README states that hiding either package breaks the module or crashes the app. Before enabling anything, verify three things: that your framework reports API 102, that the Bilibili build is 9.0.0 or above, and that the settings entry actually appears under 我的 → 设置 → 关于哔哩哔哩 → BBZQ 设置. If that entry is missing, the module is loaded but the host settings page has moved, which the README already lists as a known adaptation limit.

Frequently asked questions

Official sources

1. HSSkyBoy/BBZQ on GitHub
2. Issues
3. README
4. Releases