anyapk: Installing Any APK on Android Without Google's Approval

What anyapk Solves, and Who It Is Actually For

The README frames the project as a response to Google's developer verification requirements. Its stated method is not to patch Android or to gain root, but to route installation through the local ADB daemon that Android already ships. The app describes itself as "a lightweight Android application installer that bypasses Google's developer verification requirements by using local ADB (Android Debug Bridge) connections."

That places the audience precisely. If your device's package installer refuses an APK, or if a regional or carrier build has removed the sideload path, anyapk is an alternative front end for the same operation. It is also aimed at people installing split bundles: the feature list names `.apks`, `.apkm` and `.xapk`, installed as a single session with only the splits the device needs, plus `.obb` expansion files copied over ADB, including OBB files bundled inside an `.xapk`.

It is not for someone who simply wants to double-tap an APK. The README's own setup flow requires Developer Options, a notification permission on Android 13 and above, and a pairing code typed from a notification. That is a real cost, and the project acknowledges it by calling the ADB install "the last time you'll need to do this the hard way."

How anyapk Uses Local Wireless ADB Instead of the Package Installer

The mechanism is a local ADB session. Android's wireless debugging exposes an ADB endpoint on the device itself; anyapk pairs with it and then issues install commands to that endpoint rather than handing the file to the system package installer. Because the command comes from ADB, the verification path that normally gates a sideloaded APK is not the one being used.

The repository layout matches a normal single-module Android app: `app/`, `build.gradle`, `settings.gradle.kts`, `gradle/`, `gradlew` and `gradlew.bat`. The primary language is Kotlin. There is a `docs/` directory holding the screenshots referenced in the README and a `public/` directory, consistent with the project website hosted at sam1am.github.io/anyapk.

Two integration points are described. First, anyapk registers as an APK handler, so Android's "Open with" chooser lists it next to the Package installer and Termux; the README's screenshot caption says: "Open any APK, pick anyapk instead of the Package installer, and it installs." Second, there is a built-in file picker for when no file manager is available. The self-updater uses the same ADB connection to fetch and install new releases from GitHub.

Installing anyapk and Completing the One-Time Pairing

The recommended path is to download a release APK and open it on the device. The README lists four builds and says to take `arm64-v8a` unless you know otherwise, since it covers virtually every phone made in the last decade. The `universal` build works everywhere at roughly twice the size.

If the normal installer refuses the file, the documented fallback is ADB from a computer with SDK Platform Tools and a USB cable. After enabling Developer Options and USB debugging, the command is:

adb install anyapk-<version>-arm64-v8a.apk

The README states this is the last time you need a computer. After that, setup happens on the device. On Android 13 and above, notification permission is required because the pairing code arrives as a notification; the README is explicit that this is "required, not optional."

Pairing then runs through Developer Options. You tap Start Pairing, turn on Wireless debugging, approve your WiFi network, and choose Pair device with pairing code rather than the QR option. The README warns that the six-digit code dialog must stay open and visible behind the notification shade the whole time. Once paired, the connection is reused, and installing a file becomes a matter of opening it and choosing anyapk in the chooser.

Where anyapk Breaks: Pairing, Permissions and Platform Limits

The pairing step is the fragile part, and the README says so. The dialog showing the six-digit code must remain open and visible behind the notification shade. If you dismiss it, or if Android closes it when you leave Settings, the code is gone and the flow restarts. The notification permission on Android 13 and above is not a nicety; without it there is no way to type the code, because the code is delivered as a notification you reply to.

Wireless debugging itself is a prerequisite that some devices do not expose, and the README does not document a fallback for that case. Nor does it document rollback or uninstall behaviour, and the repository carries no licence file at the top level, so the terms under which the code may be reused are not stated in the README. The README also does not describe what happens when an install fails midway through a split session.

The framing is worth reading critically too. The README calls anyapk "not a solution to the problem - it's a tool that helps you bypass the problem," and points to keepandroidopen.org for the policy argument. That is an honest boundary: this is a workaround for a device you control, not a change to how Android verifies packages.

anyapk Compared with a Plain Sideload or a Desktop ADB Session

The obvious alternative is doing nothing special: let Android's package installer handle the APK. That works whenever the file is a single APK and the device permits sideloading, and it requires no pairing, no notification permission and no Developer Options. anyapk only earns its setup cost when that path is blocked, or when the file is a split bundle or an `.xapk` with OBB data, which the stock installer does not assemble.

The second alternative is running `adb install` from a computer every time, which is what anyapk replaces. A desktop ADB session gives you the same underlying mechanism with a cable and a terminal, and it is more transparent when something fails because you see the command output. anyapk's difference is that the ADB endpoint is on the phone, so the computer is needed once, for the initial install, and never again. The trade-off is that diagnostics now live in an Android UI rather than in a terminal you can scroll.

Maintenance, Releases and What the Repository Does Not State

The last push to the default branch was on 2026-09-18, and the most recent release, v0.0.16, carries the same date. Before that, v0.0.15 and v0.0.14 both landed on 2026-08-11. That is a steady cadence of small releases, and the version numbers, still in the 0.0.x range, indicate the project has not declared a stable interface.

Upgrade cost is low by design: the README states the self-updater checks GitHub releases and installs new versions over the same ADB connection, and that it picks the right build for the device on its own. That means once pairing works, you are not repeating the ADB-from-a-computer step for updates.

The licence is the open question. No licence file appears in the top-level repository entries, and the README does not name one. Until that is resolved, treat the terms of reuse as undetermined rather than assuming a permissive default; this is a factual gap, not legal advice.

Editorial conclusion

anyapk is for Android users whose devices restrict or block the normal package installer, who are willing to pair wireless debugging once and keep a persistent notification available. It is not for anyone who wants a zero-setup installer, and it is not a tool for iOS, PC or Android TV in the documented flow. Before relying on it, verify two things on your own device: that Wireless debugging and Pair device with pairing code both exist in Developer Options, and that the pairing notification survives long enough to type the six-digit code without the dialog being dismissed.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. sam1am/anyapk on GitHub