WebHomeTV: turning a CSP site homepage into a real web app

What problem WebHomeTV solves, and who it is aimed at

The FongMi/CatVod line of Android media players already handles playback, live TV, spider parsing, casting and a local HTTP service. What it does not give you is a homepage you can program. WebHomeTV keeps that stack and puts a web runtime in front of it: a CSP site homepage becomes a page you author in HTML, CSS and JavaScript, and the app exposes Native capabilities so that page can search, play, make cross-origin requests, proxy resources, read recent viewing history, check pan (cloud drive) links and sync state. The README is explicit that the goal is not to replace the CSP/Spider system. It is to make the homepage a real web application on top of it. The audience is therefore narrow and technical: people who maintain a site configuration, write spider scripts, and are willing to build an APK. The README points developers at webhome-devkit/ for homepages, extensions, templates, examples and AI skills, and at a separate CNB mirror for the same material. If you are looking for something to install from a store and press play, this is the wrong repository.

How the WebHome SDK, extensions and local HTTP API fit together

Three layers are visible in the repository. The first is the app itself, which retains the original FongMi capabilities and adds the enhancements listed in the README. The second is WebHome, a page loaded from the site configuration. The README's demo configuration shows the shape: a site entry with key Nostr, name Nostr推荐, type 3, api csp_Nostr and a homePage URL pointing at an HTML file. When the configuration file and the example HTML sit in the same server directory, the README states that homePage can be written as a relative path. The third layer is the extension system, which injects user scripts into real web pages. Extensions can be configured as a local file, a remote link or manifest, direct code, a generated form, or JSON. Matching defaults to a multi-select of the WebHome sites in the current 点播 configuration, and can be switched to CSP key regular expressions. A debug workbench provides web preview plus Console, Network and Elements panels. Alongside this, the app runs a local HTTP service. Endpoints include /m for the LAN management page, /api/playback/current for reading the current playback record, and /api/playback/progress, /api/playback/progress/batch and /api/playback/progress/delete for writing or clearing local progress when the user has enabled modification. The full protocol is in the 观影记录同步 chapter of webhome-devkit/docs/应用完整开发文档.md. The data flow is one direction for reads and opt-in for writes: a crawler can poll the current record, but writing progress requires the user to turn the switch on.

Building WebHomeTV from a clean clone

There is no install page for end users in the README. The build section is written for someone cloning the repository and packaging an APK, and it warns that the usual failure points are JDK, Android SDK 37, NDK and dependency downloads. The toolchain is command line only, with no IDE required. You need an independent JDK 21 on JAVA_HOME/PATH, Python 3.10 (the Chaquo runtime and build-time Python are pinned to 3.10, and installing only 3.11, 3.12 or 3.13 will fail), Android SDK Platform 37 with Build Tools 37.0.0, and the bundled Gradle Wrapper, which is Gradle 9.5.1 with Android Gradle Plugin 9.2.1. The module settings are compileSdk=37, minSdk=24 and targetSdk=28. Confirm the toolchain before you clone:

java -version
bash gradlew --version

If dependency downloads need a proxy, the README sets it in the current terminal:

export https_proxy=http://127.0.0.1:7897
export http_proxy=http://127.0.0.1:7897
export all_proxy=socks5://127.0.0.1:7897

Then point the build at your SDK and assemble the three common debug packages in one command:

git clone https://github.com/fish2018/webhtv.git
cd webhtv
printf 'sdk.dir=%s\n' "$ANDROID_HOME" > local.properties
bash gradlew :app:assembleMobileArm64_v8aDebug :app:assembleLeanbackArmeabi_v7aDebug :app:assembleLeanbackArm64_v8aDebug

If the SDK is missing API 37, Build Tools or Platform Tools, the README uses the sdkmanager bundled with Android SDK Command-line Tools:

"$ANDROID_HOME/cmdline-tools/latest/bin/sdkmanager" \
  "platform-tools" \
  "platforms;android-37.0" \
  "build-tools;37.0.0"
yes | "$ANDROID_HOME/cmdline-tools/latest/bin/sdkmanager" --licenses

For a release build intended for distribution, use the assembleMobileArm64_v8aRelease task instead. There is a shortcut for testing interfaces that only exist in release builds: passing -PfastRelease=true turns off R8 and resource shrinking, and the version string becomes <versionName>-fast-yyyyMMddHHmm in Shanghai time. The README is clear that fast packages are for temporary testing and do not replace a normal release package.

The build and runtime constraints you should weigh first

The most concrete limitation is the toolchain. Pinning Python to 3.10 means a machine with only 3.11 or newer will fail, and the README says so directly. Android SDK Platform 37 and Build Tools 37.0.0 are not the versions most machines already have installed. The NDK situation is split: NDK 29.0.14206865 (r29) is needed to rebuild MPV, FFmpeg, libplacebo and the MPV JNI, while NDK 28.2.13676358 (r28c) is still used for IJK and DVD. A normal Gradle build uses the committed binaries and does not require the NDK at all, so the cost only appears when you touch native code. The rebuild script scripts/build_mpv_player_jni.sh only rebuilds the JNI bridge libplayer.so; it does not recompile libmpv.so, FFmpeg or libplacebo. If you upgrade the MPV client API or bring in a libmpv.so whose headers are incompatible, that script will not save you. On the runtime side, several features are opt-in. Login-state learning happens only after the user manually enables it. Writing playback progress through the API requires the user to have enabled modification; reading the current record does not. The management page at /m runs on the LAN and is kept alive by a foreground service, which is a persistent notification and battery cost the README does not quantify. Remote hosting requires you to deploy your own relay on Cloudflare, Deno, Vercel, Go or Rust. The Go and Rust variants support a WebSocket channel and fall back to HTTP polling when it is unavailable, so the real-time behaviour of the other three is not described.

WebHomeTV against a plain FongMi/CatVod build

The honest alternative is upstream FongMi/TV, which WebHomeTV is based on. Upstream gives you the playback, live, spider, parsing, casting and local HTTP service that WebHomeTV also carries. The difference is everything layered on top of the homepage. With upstream you configure a site and its API; with WebHomeTV you can point homePage at an HTML file you wrote and call Native methods from it for search, playback, cross-origin requests, resource proxying, recent viewing and pan-link checking. Upstream also has no equivalent to the extension injector with its Console/Network/Elements workbench, no site health ranking that learns search, detail and playback success rates and prefers the healthier site for search and source switching, and no /m management page for files, login state, sync directories, site injection and push. If your need is simply to watch content with an existing configuration, upstream is less work: no JDK 21, no Python 3.10, no Platform 37. If your need is a homepage you control, upstream has no place to put it. The trade is development surface for build and maintenance surface.

Licence and the ongoing cost of staying current

WebHomeTV is GPL-3.0. That matters more here than for a typical library, because you are building an Android application. If you distribute a modified APK, GPL-3.0 obligations attach to that distribution; this article is not legal advice, and you should read LICENSE.md in the repository rather than rely on a summary. The maintenance picture is active: the last push was on 2026-09-11, and releases v5.6.0-202609061650, v5.6.0-202609051525 and v5.6.0-202608301534 landed within the preceding weeks. Frequent releases also mean frequent rebases if you carry local changes, and the build section warns that the current branch uses a new Android/Gradle/Media3/MPV native combination, so an environment that worked on an older branch may not work here. The upgrade path the README gives is git fetch origin followed by git pull --ff-only and bash gradlew clean, which implies fast-forward only and therefore no local commits on the branch. If you patch the app for your own deployment, that instruction stops applying and you are maintaining a fork of a fork.

Editorial conclusion

Adopt WebHomeTV if you already run a FongMi/CatVod style setup and want to write the homepage yourself in HTML/CSS/JS, or if you need the playback-recording API at /api/playback/current for a crawler. Do not adopt it if you want a store app, cannot supply JDK 21, Python 3.10, Android SDK Platform 37 and Build Tools 37.0.0, or expect the README to walk you through installing the APK. Verify first that the WebHome SDK method you need is documented in webhome-devkit/docs/应用完整开发文档.md, and check the GPL-3.0 obligations before you redistribute a build.

Frequently asked questions

Official sources

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