# XposedFakeLocation and the case for spoofing position at the app level > XposedFakeLocation is a rooted Android app and LSPosed module that replaces the location a selected app receives, with per-app scoping, sensor-level detail and randomization, without touching the developer options mock location switch. The cost is a root requirement and a module that only loads on a modern LSPosed build. **noobexon1/XposedFakeLocation** — Android application and Xposed module that allows you to spoof your device's location globally or for specific apps without using "mock location" from the developer options. - Repository: https://github.com/noobexon1/XposedFakeLocation - Stars: 733 · Forks: 111 - Language: Kotlin - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/noobexon1-xposedfakelocation ## Why not the developer options mock location switch Android already has a mock location feature in the developer options, so the first question is what this project adds. The project description is explicit that XposedFakeLocation lets you spoof your device's location for specific apps and, optionally, at the system level, without using the mock location setting from developer options. The system-level part is optional and behind a toggle. There are two practical reasons to prefer the Xposed route. The first is scope. The developer options switch is global, and any app that reads the location sees the fake one, including the maps app you are using for directions. Per-app scoping means only the app you selected is lied to, and everything else keeps working normally. The second is that the built-in mock location is conspicuous to applications, because it carries the flag that marks a location as a mock. A module that intercepts the location API at a different level can present the position as a normal one, and this project goes further than position alone, letting you set the sensor fields that normally accompany a fix. That capability is also why the project guide carries a disclaimer, and why this article treats the tool as a development and privacy utility rather than a neutral one. ## The module needs root, Android 11, and a modern LSPosed The prerequisites are strict, and one of them is a moving target. Rooted Android device is the first requirement, stated as needed for the app to function properly. The minimum Android version is 11, which is API level 30. The third requirement is the one that catches people out. The module targets the modern libxposed API, which the guide calls Xposed API 101+, and it requires a recent LSPosed build that supports the new API. Legacy Xposed and EdXposed, and older LSPosed managers, are explicitly not supported. The guide points to a Telegram channel for getting the latest LSPosed. The failure mode here is quiet rather than loud. An older manager will not load the module, so the app installs, the module enables, and nothing happens. There is no error message saying the API is too old, because from the manager's point of view the module is simply one it cannot use. The root requirement has a similar character. Nothing about the app prevents installation on an unrooted device, but the spoofing hooks it relies on will not be in place. For anyone planning an install, the practical order is to confirm the LSPosed build and the root setup before spending time on the app itself. ## Scope is managed from the app, not in the LSPosed manager The design decision that makes this project pleasant to use is where you choose which apps get the fake location. You pick the apps inside XposedFakeLocation, on the Target Apps screen, and that selection drives the LSPosed module scope automatically. The guide is emphatic about this from both directions: there is no need to manage scope by hand in LSPosed, and you should not edit the module's scope manually there. That is a real improvement on the usual Xposed workflow. The conventional pattern is to enable a module in the manager and then work out its scope by trial and error, checking one app at a time until the right one is included and the wrong ones are not. Here the app owns the list, and the manager receives it. There is one asymmetry the guide points out. The first time an app is added to the scope you need to force-stop and restart that app. After that, changes made in the manager app, whether to the location, the settings, or the start and stop state, reflect in the running target app immediately, with no restart required. That is a useful property for a testing workflow, where the location changes are the point and restarting the app under test each time would dominate the loop. ## The detail level is what separates this from a coordinate paste Setting latitude and longitude is the easy part, and the guide covers it by tapping the integrated map. The interesting part is the field set that goes with a position. The fine-tuned settings cover horizontal and vertical accuracy, altitude, mean sea level and its accuracy, speed and its accuracy, and GPS noise. Every one of those is a field a real receiver reports alongside a fix, and an application that sanity-checks its location input will notice if they are all zero while the position claims to be a rooftop in a city. The map interface is the primary location selection surface, with a Favorites screen for saved locations, which is a straightforward and well-understood design for picking a place on a map. Randomization is the other substantial feature. You set a radius for location randomization, described as a way to mimic real-world movement patterns, and the app reports a position that varies within it rather than a fixed point. For privacy use, the randomization is arguably the more important of the two. A perfectly static fake coordinate is itself a fingerprint, and a position that drifts within a small radius is much harder to single out. For testing, the accuracy and noise fields are what determine whether the app under test behaves correctly. ## System-level hooks and root relaunch are the two heavier options Two features go beyond the per-app case, and both carry a visible cost. The system-level hooks extend spoofing into system_server, referred to as the system package, and into the phone process, com.android.phone, and the guide says this is for deeper coverage, enabled with a single toggle in Settings. The cost is a reboot: the guide says to reboot the device for the change to take effect, and to reboot again after turning it off. That reboot requirement is worth understanding rather than accepting. A system-level hook changes behaviour for components that a great many apps depend on, and the hook has to be in place before those components start. A per-app change takes effect in the running app immediately, so it does not have that requirement, and that difference is the clearest signal of how much blast radius each option carries. Root relaunch is the other one, and it is simpler. You can force-stop and relaunch a target app straight from the Target Apps screen so spoofing takes effect immediately, and it requires root. It overlaps with the reactive updates described earlier, and the difference is that relaunch works even for the first application of a change to an app, and for apps that do not pick up the change reactively. There is also a headless mode, driving the module from another app or from adb shell via broadcast intents, which is off by default. That is the feature that turns this from a settings app into something scriptable in a test harness. ## Building and installing it for the first time A stable release is available from the releases page, so building is optional. The guide still spells out the path for anyone who wants to work on the code, and the steps are the standard Android ones. The repository is cloned with: ```shell git clone https://github.com/noobexon1/XposedFakeLocation.git ``` Then the project is opened in Android Studio and the APK is built from the Build menu, with the alternative being a Gradle invocation: ```shell ./gradlew assembleDebug ``` The resulting APK is installed with adb, pointing at the debug output path: ```shell adb install app/build/outputs/apk/debug/app-debug.apk ``` Activation is the part that is not standard. You open a recent LSPosed Manager that supports the new API, enable the XposedFakeLocation module, and reboot once. After that, target apps are selected from inside XposedFakeLocation, and the LSPosed scope updates itself. The tree is a conventional Gradle Android project, with build.gradle.kts and settings.gradle.kts at the root, an app/ module, gradle.properties, the wrapper scripts for Unix and Windows, and a docs/ directory. The primary language is Kotlin. ## Release cadence, licensing and the disclaimer The project is young and moving quickly, which is visible in the release list. The tags are v0.1.2 from 2026-06-08, v0.1.3 from 2026-07-25 and v0.1.4 from 2026-08-02, and the last push to the repository was on 2026-08-02 as well. Version numbers below 1.0 signal that the API and the interface may still change, and the pace of those three releases in about two months suggests active work rather than abandonment. The licence is MIT, which for an Xposed module is unremarkable but worth noting, since Xposed modules have traditionally been distributed under varied terms. The repository also carries a LICENSE file, a CONTRIBUTING.md, an .gitattributes file and a docs/ directory. The disclaimer is the part to read before installing. The project is a tool for making a device report a position it is not at, and such a tool has obvious legitimate uses in development and privacy and obvious illegitimate ones in defeating region checks, faking attendance, or cheating in a game that reads location. The guide's own framing, with the location of a service, is a developer tool that happens to have a privacy angle, and the honest reading is that the responsibility for the use sits with the operator. One other thing to know is where the module is distributed. The project publishes to its own releases page, and there is also a separate Xposed-Modules-Repo distribution channel, with download badges pointing at both, so an LSPosed user will find it through a module repository rather than by hand. ## Conclusion XposedFakeLocation suits an Android developer who needs an app under test to believe it is somewhere else, or a privacy-minded user who wants one app to stop learning their real position, because the per-app scoping and the sensor-level detail are what make the result look like a genuine fix rather than a crude mock. It does not suit an unrooted device, and it does not suit a project that needs to defeat a location check on a stock phone, since the module requires root and a modern LSPosed build. Before you install it, read the disclaimer in the project guide, note that spoofing location to defeat a service's region rules or a game's rules is likely to break its terms, and check that your LSPosed build supports the libxposed API, since older managers will simply not load the module. ## FAQ ### What does XposedFakeLocation do? It is an Android application and Xposed module that spoofs your device's location for specific apps, and optionally at the system level, without using the mock location setting from developer options. You can set coordinates on a map, tune sensor values, and add randomization within a radius. ### What do I need to run XposedFakeLocation? A rooted Android device, Android 11 or newer, and a recent LSPosed build that supports the libxposed API, which the guide calls Xposed API 101+. Legacy Xposed and EdXposed, and older LSPosed managers, are not supported and will not load the module. ### How do I choose which apps get the fake location? You select them inside XposedFakeLocation on the Target Apps screen, and that selection updates the LSPosed module scope automatically. The guide says not to edit the module's scope manually in LSPosed, and notes you need to force-stop and restart an app only the first time it is added to the scope. ### How do I build and install the APK myself? Clone the repository, open it in Android Studio and build the APK from the Build menu, or run ./gradlew assembleDebug. Then install it with adb install app/build/outputs/apk/debug/app-debug.apk, enable the module in a recent LSPosed Manager and reboot once. ### Can XposedFakeLocation spoof location for the whole system? Yes, optionally. Enabling Enable system-level hooks in Settings adds system_server and the phone process, com.android.phone, to the scope. The guide says to reboot the device for the change to take effect, and to reboot again after turning it off. ## Sources - [Issues](https://github.com/noobexon1/XposedFakeLocation/issues) - [License: MIT](https://github.com/noobexon1/XposedFakeLocation/blob/master/LICENSE) - [noobexon1/XposedFakeLocation on GitHub](https://github.com/noobexon1/XposedFakeLocation) - [README](https://github.com/noobexon1/XposedFakeLocation/blob/master/README.md) - [Releases](https://github.com/noobexon1/XposedFakeLocation/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/noobexon1-xposedfakelocation