Lin-arm/GKD_subscription: a community fork of GKD ad-skip rules

What Lin-arm/GKD_subscription actually is, and who it is for

GKD is an Android automation app that watches the accessibility tree and clicks or dismisses UI elements when a selector matches. It does not ship rules. Rules come from subscriptions, which are JSON5 files describing apps, groups and selectors. Lin-arm/GKD_subscription is one such subscription, and its README states plainly that it is a fork published after the original repository stopped updating. The original is named as AIsouler/GKD_subscription, and the upstream of that is gkd-kit/subscription.

The audience is narrow. You need an Android device, GKD already installed, and a reason to prefer this rule set over the upstream one. The README lists 977 adapted apps, 2431 app rule groups and 3 global rule groups at release v592. Those numbers describe coverage, not correctness. A subscription with 977 apps is a large surface, and large surfaces contain stale selectors, because app vendors change their layouts and nobody re-tests every rule on every release.

The project is written in TypeScript, not JSON. The repository holds src/, scripts/, dist/ and docs/, and package.json declares a gkd block that points outDir at dist and file at gkd.json5. So the JSON5 you import into GKD is a build artifact. That matters for anyone who wants to read the rules before trusting them: the readable source is the TypeScript, and dist/gkd.json5 is generated.

How the rule pipeline works: TypeScript in, gkd.json5 out

The data flow is a build step, not a service. Rule authors write TypeScript under src/, the build script in scripts/build.ts runs tsc --noEmit first and then emits the subscription, and the result lands in dist/ as gkd.json5 alongside a version file, gkd.version.json5, and a generated README. GKD itself never sees the TypeScript. It fetches the JSON5 over HTTPS and evaluates selectors against the live view hierarchy on the device.

That split explains the update model. The README states that adapted rules only take effect after a release, that a release is attempted automatically at 03:00 Beijing time each day, and that no release is published when no rule changed. So the release list is a changelog of rule edits, and v590, v591 and v592 landing within a few days of each other in September 2026 is normal rather than a sign of instability.

The dependency list is worth reading before contributing. @gkd-kit/api, @gkd-kit/define and @gkd-kit/tools are the rule-authoring packages, and the project pins them at 0.9.3, 0.0.1 and 0.8.0. TypeScript is pinned at 6.0.3 and Node at 24.17.0 through the volta field. A contributor whose local toolchain differs from those pins is working against a different API surface than the one CI uses. The repository also carries a Python test path: the pre-push hook runs pnpm run check and then bash scripts/python/tests/run_tests.sh, and lint-staged runs ruff against *.py files. That is an unusual mix for a TypeScript project and it means rule validation is partly implemented outside the Node toolchain.

Installing the subscription and enabling a first rule

There is nothing to install on the phone. The README says to copy one of the subscription URLs into the + button at the bottom right of the GKD subscription screen. The primary source it recommends is the CXPLAY-hosted Cloudflare endpoint, described as usable from mainland China:

https://gkd667.vv.ax/gkd.json5

Two further sources are listed as usable from mainland China: the Cloudflare Pages endpoint at https://gkd-subscription-667.pages.dev/gkd.json5 and the Xget mirror at https://xget.xi-xu.me/gh/Lin-arm/GKD_subscription/raw/main/dist/gkd.json5. The raw GitHub URL is listed as requiring a proxy from mainland China, and the jsdelivr mirror is described as possibly unstable with updates lagging by 24 hours. After importing, GKD should show the subscription with its app and group counts. If it shows zero, the URL did not resolve and you are looking at a network problem, not a rule problem.

The second step is choosing what to turn on. The README states that only the 开屏广告 (splash ad) category is enabled by default and that every other rule must be switched on manually. It also says GKD's rule category view can enable a whole category at once, and warns against enabling everything. That warning is specific: too many enabled rules can cause rule blocking, which makes triggers slow or stops them firing, and more enabled rules means more battery use. The linked power note lives at gkd.li/guide/faq#power.

For anyone building their own subscription rather than consuming this one, the README points at gkd-kit/subscription-template and at the @gkd-kit API documentation, and it recommends the GKD Toolkit VS Code extension for opening multiple snapshots at once. The repository's own contribution path is CONTRIBUTING.md plus docs/Selectors.md, which the README describes as a collection of general-purpose selectors and the situations they fit.

The maintenance caveats the README states about itself

The declaration section is unusually direct. It says the repository is a community continuation after the original stopped updating, that redistribution on domestic (Chinese) platforms is forbidden, that it is for study and exchange only, and that 精力有限，随缘更新, roughly "limited energy, updates as they come". That last line is the honest description of the project's cadence, and it should be read literally. The last push was on 2026-09-22 and the newest release is v592 from 2026-09-20, so the repository is not dormant today, but the stated intent is best-effort maintenance by a small group, not a service with an on-call rotation.

The second caveat is the licence. The repository metadata carries no licence identifier, and the README's declaration does not grant one either. For a rules file that is fetched and executed on your device, the practical question is what you may do with the rules themselves. Redistributing them on Chinese platforms is explicitly forbidden by the README. Nothing in the README says what is permitted elsewhere. That is a gap, not a permission, and treating an absent licence as permissive is the mistake to avoid here.

The third caveat is scope. The README frames the goal as the highest rule-writing efficiency, the lowest false-trigger rate and the widest coverage, which are three goals that pull against each other. Coverage of 977 apps is the measurable one. False-trigger rate is not measurable from the repository, and no false-trigger data is published.

Where this subscription is the wrong choice

If you want a subscription whose upstream is alive, this is the wrong fork. It exists because the upstream stopped, and the README says so in its first declaration line. Choosing it means accepting that the continuation itself is a fork with a stated best-effort cadence, and that a future maintainer could stop too. There is no continuity guarantee in the README.

If you need to know the licence before shipping rules into a product, this is the wrong source. No licence identifier appears in the repository metadata, and the README's declaration restricts rather than grants. The safe reading is that the rules are offered for personal use within GKD under the stated conditions, and anything beyond that is unresolved.

If you want predictability, enabling broad rule categories is the wrong move even if you use this subscription. The README's own warning about rule blocking and battery drain is a description of a failure mode: more enabled rules can mean slower triggers or none at all. A user who enables all 2431 app rule groups to "get everything" is more likely to hit that mode than a user who enables 开屏广告 and a handful of specific apps. The subscription's own default reflects this, since only one category ships enabled.

Finally, if you are on a device or region where the listed mirrors are unreachable, the subscription is unusable regardless of rule quality. Four of the five URLs are described as usable from mainland China and one is not; the jsdelivr mirror is described as unstable and up to 24 hours behind. There is no offline bundle documented.

How it differs from gkd-kit/subscription and AIsouler/GKD_subscription

The three projects form a chain, and the README acknowledges both ancestors in its thanks section. gkd-kit/subscription is the upstream project associated with GKD itself; AIsouler/GKD_subscription is the fork the README credits as the direct predecessor; Lin-arm/GKD_subscription is the continuation of that fork. The difference is not architectural. All three produce a gkd.json5 consumed by the same GKD app, and this repository's package.json uses the same @gkd-kit/api, @gkd-kit/define and @gkd-kit/tools packages that any GKD subscription uses.

The real difference is editorial. A rule subscription is a set of judgements about which UI elements are ads, which buttons dismiss them, and how aggressively to click. Two subscriptions covering the same 977 apps can disagree entirely about a given app's splash screen. This fork's stated position is that only 开屏广告 is on by default, which is a conservative default: it targets the one category with the least ambiguity and leaves everything else to the user. That is a different posture from a subscription that enables more by default.

The other difference is the release cadence. The README states an automatic daily release attempt at 03:00 Beijing time, skipped when nothing changed. A subscription that releases daily and one that releases weekly are not better or worse in themselves; what matters is whether the selectors in the release still match the apps on your phone. Neither this repository nor its ancestors publish a per-rule success rate, so the only verification available to a user is observation on their own device.

Upgrade cost and what a version bump means

Upgrading is a pull, not a push. The README says you can pull down in the GKD subscription screen to check for updates, and the changelog lives in GitHub releases. There is no migration step, no schema version to reconcile and no config file to edit, because the subscription is a single fetched document. The cost of upgrading is therefore near zero, and so is the cost of not upgrading, which is the actual risk: a stale subscription keeps working on apps that have not changed and quietly fails on apps that have.

For contributors the cost is higher. The pre-push hook runs pnpm run check, which is tsc --noEmit followed by tsx ./scripts/check.ts, and then the Python test script. Commits are gated by commitlint with the conventional config, and staged files are formatted by eslint and prettier, with ruff handling Python. That is a conventional but non-trivial toolchain, and the pinned versions in package.json mean a contributor should match them rather than use whatever is installed globally.

The licence situation does not change with upgrades. No licence identifier is present in the repository metadata, and the README's declaration forbids redistribution on Chinese platforms while describing the repository as for study and exchange. Anyone intending to reuse these rules outside personal GKD use should treat the licence as unresolved and ask the maintainers directly rather than infer permission from the absence of a file.

Editorial conclusion

Adopt Lin-arm/GKD_subscription if you already run GKD, want the 开屏广告 rule set on by default, and can tolerate a fork whose README says 精力有限，随缘更新 and which forbids redistribution on Chinese platforms. Do not adopt it if you need a maintained upstream, a documented licence, or a rule set you can audit without reading TypeScript. Before importing, verify three things: that the subscription URL you pick actually resolves from your network, that the release version shown in GKD matches the latest tag, and that the rules you intend to enable are the ones you want, because the README states that enabling too many rules can cause rule blocking, slow or missing triggers, and higher battery use.

Frequently asked questions

Official sources

1. Issues
2. Lin-arm/GKD_subscription on GitHub
3. README
4. Releases