GKD clicks Android nodes when selector rules match
At commit 199f104, GKD watches the current Android interface through Accessibility and acts when a rule finds the requested node or screen condition. A rule can identify text, connect a node to nearby context, then click a node or position or perform another action. The README gives two ordinary uses: confirming a desktop login inside an app and skipping an unwanted startup flow. This is personal device automation, with the decisions expressed as selectors instead of a recorded macro.
Rules are the product and also the work. GKD ships with none, so a new user must write local rules or add a remote subscription. Its snapshot inspector helps rule authors see the interface tree and build selectors with surrounding-node context. The project is substantial enough for that job: our measured checkout contained 439 files and about 44,793 source lines, yet the repository itself occupied only 2 MB before setup.
Chinese documentation limits who can operate it safely
The repository tree at commit 199f104 contains one README, and it is written in Chinese. The disclaimer, setup text, selector explanation, and latest release notes are also Chinese. Issue 1416 asks for English language support, and the discussion describes translation as work spanning the app, inspector, subscription template, and documentation. That open scope matters because a mistaken rule can click inside another app, so users need to understand more than an install button.
The Chinese material is fairly direct. It says the app has no built-in rules, links to troubleshooting, shows how subscriptions work, and points rule authors to a selector guide. GitHub listed 41,217 stars and 11 open issues and pull requests when fetched. The repository was pushed on August 27, 2026, and several commits landed on August 26 and 27, so the May 20 v1.12.1 release tag is not evidence of a dormant project.
What happened when we ran it
Our sandbox installed GKD successfully in 16 seconds. The build then stopped after 12 seconds with exit code 126. The final log line was bash: line 1: ./gradlew: Permission denied. That log establishes the failed command and the permission error. It does not establish why the command lacked permission, so we would not blame Java, Gradle, Android tooling, or the container policy without another run designed to separate those possibilities.
Tests reached the same boundary. They stopped after 9 seconds with exit 126, and their log also ended with ./gradlew: Permission denied. We therefore have no passing build and no executed test result to cite for commit 199f104. The unprivileged sandbox had 3 CPUs, 10 GB of RAM, and JVM 21. Its checkout included 2 CI workflow files, no Dockerfile, and no tests directory. Those inventory signals do not turn the failed commands into passing checks.
Accessibility access makes subscription choice consequential
At commit 199f104, GKD's Android manifest declares Accessibility service use and permissions covering installed-app queries, overlays, notifications, foreground services, network access, and battery-optimization handling. It needs visibility into other apps because screen matching is its purpose. Some permissions may depend on Android version or the selected operating mode. A remote rule source can influence where the app clicks, so its author and updates deserve the same scrutiny as any code that operates across applications.
Normal use does not require a hosted API credential according to the README. You install the Android app, enable the required service, then add local rules or a subscription URL. That is simpler than running a server, but it is not zero-configuration automation. Our 2 MB checkout and 16-second install say little about the time needed to inspect selectors, choose rule groups, and verify behavior against the exact versions of apps on your phone.
Shizuku reports show why device testing still matters
Two open reports describe failures around Shizuku-assisted modes. Issue 1410 says an app list became blank after enabling Accessibility or automation mode with Shizuku authorization on one device. Issue 1417 reports that enabling Shizuku optimization stopped a launch-ad rule from firing until the target app was moved to the background and foreground. These are specific reports rather than proof that every device has the same fault, but they concern core actions: finding apps and triggering rules.
Our 3-CPU, 10 GB JVM container could inspect installation and repository commands; it did not reproduce an Android phone, grant Accessibility access, or run a subscription against real apps. A serious trial should use the phone models and Android versions you plan to support. Check app-list visibility, background behavior, battery restrictions, snapshots, and every high-impact rule after GKD, Android, or a target app changes.
GKD suits phone-side rules better than test automation
GKD is the best fit here when the automation should live on an Android phone and come from selector subscriptions. uiautomator2 gives Python developers direct device scripting, while Appium is built for WebDriver-style testing across platforms and CI. Auto.js gives Android users a broader JavaScript programming surface, although its current repository is archived. Each asks for more explicit programming than importing a GKD subscription.
The measured result keeps the recommendation narrow. A 16-second install makes the source easy to obtain, while failed build and test commands mean we cannot endorse commit 199f104 as cleanly buildable in our stated sandbox. Use the released app if Chinese documentation, Accessibility access, and rule auditing are acceptable. Choose a developer automation framework when repeatable CI runs matter, or walk away if a third-party subscription controlling taps is outside your security policy.