VPN Hotspot: putting a phone's VPN behind a Wi-Fi access point
Share your VPN connection over hotspot or repeater! (root required)
At a glance
- What is it?
- An Android app that takes a VPN running on the phone and shares it over the hotspot or a Wi-Fi Direct repeater, so devices that cannot speak VPN themselves can reach the tunnel anyway.
- Who is it for?
- This app solves one problem that Android does not: getting clients that have no VPN client of their own through a tunnel you already pay for. The Chromecast behind a corporate firewall case in the README is the clearest example, and the honest scope note is that the tool is meant to sit alongside a real VPN or a DNS-level blocker rather than replace one.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 37 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 11, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The gap it fills: clients with no VPN client of their own
Android's VPN service routes traffic for the device that runs it. Devices that join the phone's hotspot do not inherit that tunnel, which is why a streaming stick or a smart speaker behind a corporate firewall simply will not reach the internal network even though the phone can. VPN Hotspot bridges the two, exposing the tunneled network over the hotspot or over a Wi-Fi Direct repeater.
The README lists the situations it is aimed at, and they are specific rather than general. Connecting hardware that does not support VPN, such as Chromecasts, behind a corporate firewall is first. Setting up Google apps behind the same kind of firewall is second. Third is the reverse case: you want to connect to your own mobile hotspot but do not want to configure a VPN on the device you are tethering from. Fourth is visibility: identifying, monitoring and blocking unwanted clients on the shared network.
The tethering-limit workaround is where the README is most careful about its own limits. It lists three options in order of preference: use the app together with a real VPN or socksifier, use it with ad-blocking or DNS apps that implement the system VPN service APIs, which it calls fake VPNs, or simply use the app alone and see what happens. That ordering is a candid admission that the app is a network plumbing tool and not a VPN service, and it points readers at a discussion thread listing apps known to work.
The README closes that section by noting the same trick is documented for Windows, macOS and iOS, which is a useful reality check: the Android version exists partly because no other platform has an equivalent app that needs no computer in the loop.
Root is required, and some features need a system app on top of that
Root is the baseline requirement, stated in the repository description and repeated in the README's opening line. Above that baseline, a second tier exists: features that only work if the app is installed under `/system/priv-app`.
The named case is `android.permission.OVERRIDE_WIFI_CONFIG`, the permission to read and write the system Wi-Fi hotspot configuration, documented as applying to Android 8 through 10 and available since app version 2.4.0. The README suggests App systemizer for Magisk as one route to installing an app as a system app, which tells you the expected environment is a rooted device running a custom setup rather than a stock phone.
Installing as a system app also changes the runtime behaviour in the app's favour. The list of privileged permissions the app can then hold includes `android.permission.CONNECTIVITY_USE_RESTRICTED_NETWORKS`, `android.permission.LOCAL_MAC_ADDRESS`, `android.permission.MANAGE_USB`, `android.permission.OVERRIDE_WIFI_CONFIG`, `android.permission.READ_WIFI_CREDENTIAL`, `android.permission.TETHER_PRIVILEGED` and `android.permission.WRITE_SECURE_SETTINGS`, and the README says having them means the root daemon has to be launched less often.
That last point comes with a maintenance instruction. When an app update adds a new protected permission, the copy installed as a system app needs updating too, or the system will not grant it. The README dates the most recent protected-permission addition to version 2.17.1, which gives you a concrete marker: if you installed the system-app copy before that version, it is out of date regardless of which release you are on now.
What the app leaves on the device, in the maintainer's own list
The README has a section titled around what persistent changes the app can make to the system, and its answer is worth reading closely because it contains both the reassurance and the list. The framing is that the app only writes persistent changes indirectly through system APIs and so should be generally safe. Then it enumerates three things that do survive.
In supplicant mode, the repeater asks `wpa_supplicant` to create a persistent group on startup, and Android persists that group in `/data/vendor/wifi/wpa/p2p_supplicant.conf` or `/data/misc/wifi/p2p_supplicant.conf`, depending on the device. Changes you make to the system Wi-Fi hotspot configuration through the app persist. And toggling tethering hardware offload through the app flips the global `tether_offload_disabled` setting, which also persists, and can be reverted from the app or from the matching Developer options entry.
Everything else is transient: routing, firewall rules, addresses and daemon or service state are cleaned up when the app stops, when you use its Clean action, or on reboot. That distinction is the useful part of the section, because it separates the three durable writes from the large amount of network state the app manipulates while running.
A fourth heading in the same section is just a link, pointing at issue 62 for the question of whether the app can run without root. The README does not carry the answer, so a reader looking for an unrooted path is sent to the issue tracker, which is consistent with the rest of the document's habit of pushing detail into discussions rather than duplicating it.
Repeater instability usually means the Wi-Fi channel moved
There is a troubleshooting entry for a repeater that fails to create a group with an internal error, or that shuts down after a while, and the diagnosis is a channel problem rather than a bug. Either the device cannot operate on the channel you selected, or a nearby Wi-Fi Direct device has advertised that it cannot operate on it either.
The fix is to set the channel to 0 and let the device choose automatically. The README offers a second, more surgical option: connect a 2.4GHz-only device with WPS to force the repeater to switch from 5GHz to 2.4GHz for that session.
This is a small piece of documentation but a good example of the project's tone. Rather than describing the repeater as flaky, it names the two conditions that cause the failure, ties each to an Android or Wi-Fi Direct constraint, and gives both a blunt remedy and a targeted one.
An index of private APIs, pinned to a commit
The README includes a section of private Android APIs the app depends on, subtitled as an explanation of things that can go wrong if they are unavailable. It labels itself an index rather than documentation, points readers to the source for detail, and states that the API restriction list it tracks is current as of a specific commit in a separate `Mygod/hiddenapi` repository, identified by SHA-256 checksum `9102af02fe6ab68b92464bdff5e5b09f3bd62c65d1130aaf85d3296f17d38074`.
The entries are annotated with the Android release they apply to and their hidden-API restriction flags. Several are marked as pre-API 30, including `ConnectivityManager->getLastTetherError` and a run of `EXTRA_*` tethering constants. Others are marked as since API 30 or 31, such as `ConnectivityModuleConnector->IN_PROCESS_SUFFIX` at API 30, and `INetd$Stub->asInterface` plus `INetd->ipSecUpdateSecurityPolicy` at API 31. A couple are flagged `blocked`, including `IIntResultListener`.
This matters more than a normal dependency list would suggest. Hidden API restrictions are enforced by Google and can change with any Android release, so an app built on greylisted or blacklisted methods has an expiry date tied to the platform rather than to its own release cycle. Publishing the tracked commit hash makes that coupling checkable: you can tell whether the app's assumptions have been re-verified against a newer Android build. The list also explains the otherwise puzzling support range, since entries that only exist on one side of API 30 explain why the app carries version-conditional code paths.
What changed in version 3, and how releases are distributed
The release notes are the clearest statement of what version 3 cost existing users. Version 3.0.6, dated 2026-06-20, was the promotion to stable, and it lists compatibility requirements rather than features: Android 10 and API 29 or newer is now required, with Android 9 users told to stay on v2.19.2. Users are told to avoid updating while VPN tethering is active, either turning it off first or rebooting afterwards. Release APKs are now split by CPU ABI, so sideloaders must pick the matching file. Android 17 is listed as officially supported. And the mode names changed, with repeater unsafe mode replaced by a new supplicant mode while safe mode was renamed framework mode.
That mode rename is the one that affects the README. The persistent-changes section describes supplicant mode as the current mode, which only makes sense after the v3 rename, so a reader running v2.19.2 on Android 9 is looking at a document written for a later generation of the app.
Distribution is the other thing the notes are specific about. Version 3.0.7 changed APK compression from zip to `tar.xz` for smaller downloads, and told Obtainium users to update their configuration, linking to a config whose filter regex targets the `.tar.xz` pattern. The README badge points at the same Obtainium configuration, along with a pre-release channel variant. Version 3.0.8, dated 2026-08-02, is a fixes release that also bumps the Gradle wrapper from 9.6.0 to 9.6.1.
The repository tree gives the rest of the shape. `mobile/` holds the Android app, `scripts/` the build helpers, `docs/` the documentation, `external/` submodules, `.cargo/` Rust components, and `AGENTS.md` an agent instruction file at the root, which is unusual for a project of this type and hints that some development happens with tooling in the loop. The default branch is `master`, the license is Apache-2.0, and the last push was on 2026-09-04.
Editorial conclusion
This app solves one problem that Android does not: getting clients that have no VPN client of their own through a tunnel you already pay for. The Chromecast behind a corporate firewall case in the README is the clearest example, and the honest scope note is that the tool is meant to sit alongside a real VPN or a DNS-level blocker rather than replace one. Two things to settle before relying on it: whether the repeater mode you need is one of the modes the version you install actually has, given that v3 replaced unsafe mode with supplicant mode and renamed safe mode to framework mode, and whether you accept the persistent writes the README itemizes, since the supplicant mode group survives in a wpa_supplicant config file. Read the persistent-changes section before the first run, then check `docs/` and the issue tracker for the mode-specific behavior.
Frequently asked questions
Is a VPN the same as a hotspot?
No, they operate at different layers. A VPN tunnels traffic for the device running the VPN client, while a hotspot shares a Wi-Fi access point with clients that have no VPN client of their own. VPN Hotspot exists to join the two, forwarding the hotspot's clients through the tunnel the phone already has.
Can you hotspot off a VPN?
Yes, and that is exactly what this app does. The README frames it as sharing a VPN connection over hotspot or repeater, and the canonical example is getting a Chromecast or other non-VPN device through a corporate firewall by routing it through the phone's existing tunnel. Root is required.
Does VPN Hotspot leave any permanent changes on the phone?
Three, according to the README. In supplicant mode the repeater creates a persistent group that Android stores in a wpa_supplicant config file, hotspot configuration edits you make in the app persist, and toggling hardware offload flips the global `tether_offload_disabled` setting. Routing, firewall and address state is cleaned up on stop, on Clean, or on reboot.
Why does the repeater shut down or fail to create a group?
The README attributes it to the Wi-Fi channel you chose no longer being available, either because your device cannot operate on it or because a nearby Wi-Fi Direct device advertised the same restriction. Set the channel to 0 so the device picks automatically, or use WPS with a 2.4GHz-only client to force the repeater down to 2.4GHz for that session.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/mygod-vpnhotspot)