Managing Scope Selections for Individual Modules Inside LSPosed App

I learned the value of careful scope choices the hard way. A single careless tick in LSPosed Manager once sent my SystemUI into a restart loop on a Monday morning, and the only way out was a recovery session I had not planned for. The module itself was fine. My selection was not. That experience changed how I treat every checkbox in the manager, and it is the reason this guide starts with a simple idea: scope is a safety boundary, not a formality.

Scope decides which apps a module may touch. A module with no target does nothing at all. A module with a short, deliberate target list does exactly what its author designed. A module with a long, speculative list reaches into apps it was never tested against. If you are new to the framework, start by reading what LSPosed framework is so the loading model below makes sense before you change anything.

This guide walks through that loading model, shows real patterns for well-known modules, gives you an audit routine you can repeat monthly, and explains how to fix the three most common scope problems. It is written for people who already have LSPosed running and want a setup that stays stable for months rather than days.

How LSPosed scope loading works inside Android app processes

LSPosed does not inject a module into every app on your phone. When a new app process starts, the framework checks the module list for that app and loads only the modules you selected for it. A process that is already running keeps its old set of hooks until it restarts. That timing detail explains most of the confusion people report after changing a selection.

Imagine you remove a messaging app from a module and the tweak still appears in that app. Nothing is broken. The old process is still alive with the old hooks inside it. Force stop the app, open it again, and the effect disappears. A full reboot has the same result for every process at once, which is why it is the most reliable step after a large change.

System processes behave the same way, with higher stakes. SystemUI, the Android System entry, and the launcher are long-lived processes. Restarting them is not as simple as force stopping a chat app, and a bad hook inside SystemUI can take the whole interface down with it. That is why interface modules deserve a slower, more deliberate selection process than a single-app tweak.

What happens when an app process starts with a module attached

At process start, the framework reads the stored selection for each enabled module, decides which ones apply to the new process, and loads their code into it. Hooks then attach to the methods the module wants to change. If the module expects a method that does not exist in that app version, the load can fail or crash the process. This is the technical reason a narrow list is safer: fewer processes mean fewer chances to meet an unexpected method.

Why a scope change needs a restart before you judge it

Judging a change from a running process is judging old code. I now follow one rule without exception: change the selection, force stop the target app, open it again, and only then decide whether the tweak works. For SystemUI changes, I reboot. It takes an extra minute and removes a whole class of false bug reports, including the classic complaint that a module “does nothing” when it simply has not loaded yet.

Force stop versus reboot after a scope edit

Force stop is enough for an ordinary app. Open Settings, find the app, tap Force stop, then launch it again. Reboot is the right choice when you changed SystemUI, the Android System entry, the launcher, or several modules at once. A reboot also clears cached data that can make an old result look like a current one.

Choosing scope for a new LSPosed module from its documentation

Good documentation names its targets explicitly. It may name one app, a small group of apps, or a system process such as SystemUI. Follow that named list exactly the first time. Do not add extra apps because they feel related. Extra targets add crash surface without benefit, and they make troubleshooting harder later because the suspect list is longer.

When documentation is vague, start with the narrowest plausible list. Add one app at a time and test each addition separately. Widening later is easy when evidence supports it. Narrowing after a crash is stressful, especially if the crash involves a system process. The safe order is always narrow first, then widen slowly.

Reading a module description for hidden target hints

Some authors describe a feature without naming the process that hosts it. A tweak that changes the share sheet may need the Android System entry rather than the app you share from. A tweak that changes notification behaviour may need SystemUI rather than the app that sends the notification. When the description mentions the interface, the share sheet, the recents screen, or the lock screen clock, treat that as a hint that a system process is involved and check the project page or its issue tracker before guessing.

Questions to ask before you tick a system process

Ask whether the module truly needs that process to work. Interface modules often need SystemUI. Most single-app tweaks do not need any system process. A module that asks for many system processes should explain each one in its description. Unexplained system access is a warning sign. It may indicate careless design, or it may indicate data collection you did not agree to. Either way, pause and ask the author, or look for community answers, before you approve it.

Red flags in a module that wants broad system access

Watch for a module that requests every system process while its feature list mentions only one app, a module with no changelog and no issue tracker, and a module whose description promises several unrelated features at once. Any one of those is a reason to test on a spare device first, or to skip the module entirely. A short question in the project discussion can prevent a long recovery session later.

Scope patterns for GravityBox, XPrivacyLua, and other well-known modules

Real modules fall into a small number of patterns. Learning the patterns makes new modules easy to judge, because you can compare an unfamiliar module against a familiar one instead of starting from zero. The table below shows the patterns I use most often, with the reasoning behind each one.

GravityBox deserves special care because its target list is short but powerful. Three entries can reshape the whole interface, so I change one GravityBox option at a time and reboot after each batch. XPrivacyLua is the opposite shape: a long list is normal, but every entry should be a deliberate decision about one app. If you cannot say why a particular app is on the XPrivacyLua list, remove it and see whether anything changes. The roundup of top LSPosed modules for advanced users is a useful place to compare these patterns against other popular modules before you install something new.

GravityBox scope: SystemUI, Android System, and Settings explained

GravityBox changes the status bar, the navigation bar, the lock screen, and several quick settings behaviours. Those elements live in SystemUI, which is why SystemUI is its first target. Some of its options touch power menu behaviour and system-level settings, which is why the Android System entry appears. The Settings entry covers the options that appear inside the Settings app itself. Keep the list to those three unless a specific GravityBox version documents another one. Adding a messaging app or a browser to GravityBox gains nothing and only adds risk.

XPrivacyLua scope: one decision per app, not one global switch

XPrivacyLua works by giving each selected app restricted or fake data for categories such as location, contacts, identifiers, and sensors. The right way to use it is app by app. Pick an app, decide which categories it genuinely needs, and leave the rest restricted. A weather app may keep coarse location but lose precise location. A game may lose contacts entirely. A banking app should usually stay off the list, because fake identifiers can break login and fraud checks. I review my XPrivacyLua list after every app install, because a new app is unchecked by default and that is exactly how it should stay until I decide otherwise.

Single-app tweaks and the gold standard of one target

A tweak built for one messaging app, one camera app, or one social app should list exactly that app. This is the gold standard for stability. A crash in the target app points straight at that module. No other app can be affected. When you find a module that follows this pattern, prefer it over a general-purpose module that promises the same feature across many apps. The general module may work, but the single-target module fails in a smaller, safer place.

SystemUI, Android System, and launcher scope decisions

System processes are the most powerful targets in the manager and the most dangerous ones to get wrong. A faulty hook in an ordinary app crashes that app. A faulty hook in SystemUI removes the status bar, the navigation bar, and the notification shade until the process restarts or the module is disabled. Treat every system entry as a separate decision with its own justification.

SystemUI is the right target for clock position, battery icon style, notification shade layout, quick settings tiles, and navigation bar tweaks. The Android System entry is the right target for hooks that change how apps launch, how the share sheet behaves, or how system services answer requests. The launcher is the right target for home screen grid changes, icon labels, and gesture tweaks. If a module asks for all three and its feature list only mentions one of those areas, ask why before you approve the other two.

When the launcher belongs in scope and when it does not

Launcher scope is needed only when the feature changes the home screen itself. Icon pack tweaks, grid size changes, and dock options qualify. A module that changes in-app behaviour does not need the launcher, even if you launch the app from the home screen. I have seen people add the launcher to every module out of habit, which turns a simple home screen crash into a mystery with ten suspects. Keep the launcher off the list unless the feature visibly lives there.

Keeping a recovery plan ready before you touch system scope

Before I enable any module with SystemUI in its list, I make sure I know how to disable modules if the interface breaks. The practical guide to disabling modules from recovery covers the steps for the moment when the screen stops responding and the manager cannot be opened normally. Read it before you need it, not during a boot loop. I also keep a note of which modules touch SystemUI, so a recovery session starts with a short suspect list instead of a blind search.

Test system scope changes when you have time to recover

Never test a new SystemUI module five minutes before you need the phone for a call or a journey. Test it at home, with a charger nearby and time to reboot into recovery if needed. Change one thing, reboot, use the phone normally for an hour, and only then change the next thing. That pace feels slow. It is far faster than rebuilding a broken setup.

How to audit LSPosed module scope step by step every month

A monthly audit takes only a few minutes for a small module set, and it reverses scope creep before it causes trouble. Scope creep is the slow version of a broad selection mistake: an app added during an experiment, a system process added speculatively, a test entry that was never removed. Each one is harmless alone. Together they turn a clean setup into a fragile one.

1. Open LSPosed Manager and open the module list. Work through enabled modules one at a time, starting with the ones that touch SystemUI.
2. Open each module and read its checked list slowly. Ask of every entry: does this app still need this module, and can I say why in one sentence?
3. Remove entries that were added during an experiment and forgotten. Remove apps you no longer use with that module. Remove system processes unless the documentation justifies them clearly.
4. Check for apps that updated recently. An update can move a feature to a different process, so a module that worked last month may need a different target now.
5. Restart each affected app, or reboot once at the end, and confirm the features you care about still work. Write down any change you made and the date, so next month starts from a known state.

I keep that note as a simple list: module name, its targets, and the date I last reviewed it. When something breaks three weeks later, the note tells me what changed and when, which is usually enough to find the cause without guessing. A monthly scope audit plus a short written note is the cheapest insurance in this whole hobby.

Audit after app updates and Android version changes

An app update can rename a process, split a feature into a companion process, or move a screen into a different component. A module aimed at the old process may stop working silently, or start affecting an unexpected area. After a major update, open the target app, confirm the tweak still works, and check the module list for new processes the app may have gained. Split apps and companion apps complicate this check, because the feature you want may live in a helper process rather than the main app. Documentation usually clarifies which process hosts a feature, and when it does not, a careful trial with one process at a time reveals the answer.

Temporary scope and profiles for experiments

Advanced users sometimes keep two patterns: a daily pattern with stable modules on daily apps, and a testing pattern with experimental modules on test apps only. Switching patterns means changing selections rather than installing new modules. Temporary scope is a lighter version of the same idea: give a module its target for one task, then remove the target when the task ends. A screenshot tool needs its target only during a capture session. A testing module needs its target only during a test run. Set a reminder to remove temporary entries when the task ends, because forgetting them defeats the purpose entirely. A test device makes all of this safer still, because experimental selections live on the spare phone and never touch the daily one.

Troubleshooting scope problems: module does nothing, wrong app affected, crashes

Most scope problems show one of three symptoms, and each one points at a different cause. Working through them in order saves time, because the fix for a missing target is the opposite of the fix for an extra target.

A module that does nothing usually misses its target

Check three things. First, is the target app actually checked in the module list? Second, is the module itself enabled? Third, has the target app restarted since the change? A module with no target does nothing at all, and a module whose target process has not restarted yet behaves exactly the same way. Force stop the app, open it again, and test the feature. If it still does nothing, check whether the app updated recently and moved the feature to another process.

A module that affects the wrong app has an extra target

An unchecked app should never show module effects. If it does, the running process may still hold old hooks from before the change, so restart the app or reboot first. If the effect survives a reboot, the extra target is real: open the module list and look for the app, or for a shared process that hosts it. Narrow the list, restart, and confirm the effect is gone. A crash in an unexpected app points the same way. Review the modules that could reach that app, narrow their lists one at a time, and restart after each change until the crash stops.

Two modules fighting over the same app and the same feature

Conflicts often trace to overlapping selections. Two modules aimed at the same app may hook the same method, and their callbacks can interfere in unpredictable ways. Symptoms include missing features, flicker, and crashes that appear only when both modules are active. Isolate the pair by disabling one module at a time for that app, restarting the app after each change. Keep only one module per feature area for a given app. A single clear owner per feature avoids the overlap entirely, and it makes future troubleshooting a one-suspect job.

Stale cache can make a correct scope change look wrong

Apps cache data from earlier runs that reflects old hook results. A location app may show a cached position after a change. A theme app may show cached colours after a change. Clear the app cache, or reboot the device, before you judge the result. A fresh process plus a fresh cache gives a trustworthy verdict, and that combination should be the standard for every scope test.

Scope as a privacy boundary for data access on rooted phones

Scope is also a privacy tool, because a module can only observe the apps inside its list. A narrow list limits observation to a small set. A broad list grants observation across many apps. Treat a selection with the same seriousness as a camera or location permission. Grant it as carefully, review it as often, and remove it as soon as the need ends.

A module with a broad list deserves the same scrutiny as an app with broad permissions. Both can observe more than you intended. Privacy audits pair well with permission audits: review module selections and app permissions together each month. An app with broad permissions plus a module with a broad list compounds exposure. Reducing either side reduces total exposure. Reducing both sides gives the strongest result, and the combined audit takes little extra time because you are already looking at the same apps.

That said, scope is a boundary, not a guarantee. It limits which processes load a module, but it does not audit what the module does inside those processes. A module aimed at one app can still misbehave inside that app. Read the module source or its project page when it handles sensitive data, prefer modules with a visible changelog and an active maintainer, and remove anything you cannot explain. Understanding what runs inside your apps is the foundation of real privacy control on a rooted phone.

Frequently asked questions about LSPosed module scope

What happens if I leave a module with no apps selected?

Nothing happens. The module loads into no process, so its features stay inactive and it cannot crash any app. That state is safe but useless, and it is the correct state for a module you installed but have not configured yet. Select its targets only when you are ready to test it, one app at a time.

How do I know which apps a new module needs?

Read the module documentation first, because good authors name their targets. If the documentation is silent, think about where the feature lives: inside one app, inside SystemUI, or inside a shared service. Start with the narrowest plausible list, test one addition at a time, and watch for the feature to appear. Community discussions for that module often name the correct targets when the documentation does not.

Why does a module still work after I remove an app from its scope?

The app process is still running with the old hooks loaded. Scope is checked when a process starts, not continuously, so a running process keeps its old set until it restarts. Force stop the app and open it again, or reboot the phone. If the effect survives a reboot, check for a shared process or a second module that provides the same feature.

Can two modules share the same app in scope safely?

Yes, when they touch different features. A privacy module and a visual tweak can share a messaging app without conflict if their hooks target different methods. Problems start when both modules change the same feature, such as two modules reshaping the same menu. In that case keep one owner per feature, disable the other for that app, and test again.

Should SystemUI be in scope for every interface module?

No. SystemUI belongs in scope only for modules that change the status bar, the notification shade, the navigation bar, the lock screen, or quick settings. A module that changes in-app behaviour does not need SystemUI, and adding it only widens the blast radius. Judge each module by where its feature lives, not by a habit of ticking SystemUI for everything.

A scope routine you can keep for years

Start every new module with the narrowest list its documentation supports. Restart the target app after every change before you judge the result. Audit every module once a month, prune entries you cannot justify in one sentence, and re-check targets after major app updates. Keep one module per feature area for each app, and keep a recovery plan ready before you touch SystemUI. That routine is short, it fits on a single note, and it is the difference between a setup that runs quietly for years and one that needs rescue every few weeks.

Your next step is concrete: open LSPosed Manager today, pick the module you use most, and read its checked list out loud. If any entry makes you pause, remove it, restart the app, and see whether you miss it. A clean scope list you can explain entry by entry is the goal, and the audit above is how you get there.