# Android-Touch-Helper watches your screen and taps the skip button

> A Java Android app that uses an Accessibility Service to find and click skip controls on launch ads, ships with no network permission, and carries a maintenance note that points readers somewhere else.

**zfdang/Android-Touch-Helper** — AdSkip — an Android assistant for automatically skipping app launch ads

- Repository: https://github.com/zfdang/Android-Touch-Helper
- Website: https://TouchHelper.zfdang.com
- Stars: 5,323 · Forks: 504
- Language: Java
- License: MIT
- Published: 2026-10-08 · Updated: 2026-10-08 · Language: en
- Canonical page: https://hysenlabs.com/projects/zfdang-android-touch-helper

## What an Accessibility Service can see on a splash screen

The repository describes itself as an Android helper app that automatically skips splash ads, and the mechanism it names is Android Accessibility Service. That single choice is the whole design, and it is also where both the usefulness and the reputation problem come from.

An accessibility service is an Android component that a user grants permission to observe and act on the interface of other apps. Once enabled, it receives events describing what is on screen and can perform gestures, including taps, at coordinates it computes itself. That is why a repository with 5,312 stars and 507 forks exists at all. No app developer exposes an API for dismissing their own launch ad, so the only route is to watch the screen and tap the skip button the way a finger would.

The package is com.zfdang.touchhelper, the language is Java, and the build is Gradle. The top-level tree is small enough to read in one glance and tells you what you are dealing with: a single application module, a Gradle wrapper for both platforms, a docs directory, and a Chinese README sitting next to the English one. There is no library to depend on and no API to call. You install an app, grant it a permission, and it does its work in the background while you use other apps.

## Three ways the app decides where to tap

The README lists the detection strategies as three, and the list is worth reading closely because it explains why the app works on some launches and quietly fails on others.

Keyword detection looks for buttons whose text contains certain keywords and taps them. This is the most portable strategy because it does not depend on a resource identifier, and also the bluntest, since the word skip appears on plenty of buttons that have nothing to do with advertising.

Specific UI controls means locating a predefined view for a named app and clicking it. That is more precise and more fragile, because it depends on the other app's view hierarchy staying exactly as it was when the rule was written.

Specific screen positions means clicking a configured area for a named app, with no inspection at all, only geometry. It is the strategy most likely to break on a different aspect ratio or after a system update changes the height of the status bar.

The ordering is a design position rather than a list. The project accepts that precision comes from specificity, and that specificity means the rules have to be maintained one app at a time. The repository itself ships no rule catalogue, which is why the answer to how many apps it actually handles is not written down anywhere in the documentation.

## The permission claim and the observation it does not address

Because Accessibility-based tools can potentially access sensitive on-screen information, privacy is the biggest concern for this kind of app. The README raises that concern itself, then answers it with a claim rather than an argument: the project is open source, does not require network permission or storage permission, and does not collect or upload personal data.

The permission half of that claim is checkable, and this is where it carries weight. A manifest that declares neither the INTERNET permission nor storage permissions makes network exfiltration structurally impossible for that binary, not merely discouraged. The MIT license means anyone can read the source and confirm the manifest instead of taking the README's word for it.

What it leaves open is what the app does with what it reads. An accessibility service still receives text from every screen it observes while it is enabled, including screens belonging to apps that have nothing to do with advertising. The README addresses collection and upload. It does not address observation, and those are separate questions. The mitigation is operational rather than technical: switch the service on when you want launch ads skipped and switch it off when you do not.

Distribution runs through F-Droid and Google Play, with a project site at TouchHelper.zfdang.com. Both stores build on the same source tree, which gives a reader two independent reasons to look at that manifest rather than one.

## A maintenance note that disagrees with the release page

Two facts in this repository point in opposite directions, and anyone deciding whether to install should hold both at once.

The README carries a maintenance note. It started as a personal project several years ago, the author no longer has much time to actively improve or maintain it, and new feature requests may be difficult to support. Pull requests, the note continues, will still be reviewed and merged on a best-effort basis.

Then look at the releases. Three are published, all on 2026-09-22, less than an hour apart: tag-274 at 12:18 UTC, tag-276 at 12:49, tag-277 at 13:14. The last push to the default branch is 2026-09-22 as well, so the source and the published artifacts are in sync rather than weeks apart.

Neither fact overrides the other, and the useful distinction is what produced each one. Every release body is empty. The tags are bare numbers with no version name and no changelog, which is the signature of a pipeline that publishes an artifact on every successful build rather than a maintainer curating what ships. The Build_TouchHelper_APK workflow badge in the README points the same way. So the releases are evidence that the build still runs and the app still installs. They are not evidence that anyone is designing new features. Read the note for feature work and the release page for build health, and do not merge the two.

## Installing from the two stores the README names

There are no install commands in this project, and that is not an omission. It is a sideloaded Android application with a user interface, not a library, not a CLI, and not something you assemble from a shell prompt. The README offers two distribution routes, both first party:

```text
https://f-droid.org/packages/com.zfdang.touchhelper/
https://play.google.com/store/apps/details?id=com.zfdang.touchhelper
```

F-Droid is the more interesting of the two for anyone who cares about the permission claim, because that build is assembled from the source tree in the repository and its metadata can be checked against the manifest independently of the author.

Building it yourself is possible but not the documented path, and the top level shows how little there is to it:

```text
app/
build.gradle
gradle.properties
gradle/
gradlew
gradlew.bat
settings.gradle
```

One application module, a wrapper script per platform, and no submodule or vendored dependency directory. The README does not document a source build beyond the CI badge, so the supported route is the store install and the Gradle tree is there for people who want to read the code or patch it.

## What the gkd pointer actually changes about the tradeoff

The README ends its maintenance note by pointing somewhere else, and that pointer is the most useful line in the file:

```text
Recommended open-source alternative:
https://github.com/gkd-kit/gkd

There are also many ready-made rule sets:
https://github.com/topics/gkd-subscription
```

gkd keeps the same underlying mechanism, an Accessibility Service, but makes the rule the unit of distribution instead of hard-coding knowledge into an app. In Android-Touch-Helper a rule is a fact about one other app's layout, and it lives inside the binary, so shipping a fix for a broken layout means shipping a release. In a rule-driven project the same fix is an entry in a subscription that other people can publish without waiting on the app maintainer at all.

The second URL is where the practical difference shows. The gkd-subscription topic collects ready-made rule sets, which moves the maintenance burden from one person to a population and leaves the consuming app as the stable part.

The repository also credits AccessibilityTool by LGH1996 for borrowed ideas and code, and records sponsorship from ZMTO through a free VPS program for open source projects, which is where the hosted side of this repository runs.

The choice between the two is short. If you want one install and never want to think about rules, this app is the shorter path. If you want ad skipping that survives the next layout change in the apps you use most, the subscription model is the one built for that, and the README points you at it rather than hiding it.

## Conclusion

Android-Touch-Helper is a finished, MIT licensed app that solves one narrow problem without asking for a permission you would rather not grant, and its Accessibility Service approach is still the only route an app developer does not have to cooperate with. The maintenance note says feature work has slowed while the release page shows three builds from 2026-09-22 with empty bodies, so treat the releases as proof the build runs rather than as a roadmap. Install from F-Droid, check the manifest for yourself, and if you expect launch layouts to keep changing, read the gkd-subscription topic the README points at before you settle on this one.

## FAQ

### Does Android-Touch-Helper need internet or storage permission?

The README states that the project does not require network permission or storage permission, and that it does not collect or upload personal data. Because the app is open source under the MIT license, the manifest can be inspected directly rather than taken on trust.

### How does Android-Touch-Helper skip splash ads?

It uses an Android Accessibility Service to inspect on-screen content and tap the skip control. The README lists three detection strategies: matching keywords in button text, finding predefined UI controls for a named app, and clicking a configured screen region for a named app.

### What is the difference between Android-Touch-Helper and gkd?

Both rely on an Accessibility Service, but this app hard-codes its detection rules inside the application, while gkd distributes rules separately. The README recommends gkd as an open-source alternative and links to the gkd-subscription topic for ready-made rule sets.

### Is Android-Touch-Helper still being maintained?

The README carries a maintenance note saying the author no longer has much time to improve it and that feature requests may be difficult to support. Three releases were published on 2026-09-22 with empty release notes, and the last push was on the same date.

### How do I install Android-Touch-Helper?

The README links to both an F-Droid listing and a Google Play listing for the package com.zfdang.touchhelper. The project also maintains its own site at TouchHelper.zfdang.com. There is no documented source build, though the repository contains a standard Gradle wrapper.

## Sources

- [License: MIT](https://github.com/zfdang/Android-Touch-Helper/blob/master/LICENSE)
- [Project website](https://TouchHelper.zfdang.com)
- [README](https://github.com/zfdang/Android-Touch-Helper/blob/master/README.md)
- [Releases](https://github.com/zfdang/Android-Touch-Helper/releases)
- [zfdang/Android-Touch-Helper on GitHub](https://github.com/zfdang/Android-Touch-Helper)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zfdang-android-touch-helper