You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem?/你的请求是否与某个问题相关?
Yes. When I use a module (requiring API 100) and target a specific app (e.g., HungerStation), the app immediately force closes upon launch. In the official LSPosed manager, this specific crash can be bypassed using the "Invalidate inline hooks" feature. Since Vector currently lacks this feature, the app remains completely inaccessible when targeted by the module.
Describe the solution you'd like/描述你想要的解决方案
I would like to request the implementation of the "Invalidate inline hooks" (Cleanup libart.so for listed apps) feature in Vector's settings, similar to how it exists in the official LSPosed manager. This would serve as a necessary workaround to allow stubborn apps to launch successfully when targeted.
Additional context/其他信息
Device: Tecno Camon 30 (Model: CL6)
Vector Version: 2.0 (3021)
Note to developer: As requested, I am attaching the crash logs to this issue to demonstrate the force close that occurs due to the absence of this feature.
Some apps use digital encryption, so if you hook these apps, it won't work unless you use “Invalidate inline hooks”.So I think the feature is useful.Hopefully you'll add the feature.
I have been requesting this exact feature for two months now, and still zero progress. At this point, I honestly can't tell if the developer just lacks the technical skills to figure out how to implement it, or if it's just pure laziness. Either way, it's really frustrating.
I have been requesting this exact feature for two months now, and still zero progress. At this point, I honestly can't tell if the developer just lacks the technical skills to figure out how to implement it, or if it's just pure laziness. Either way, it's really frustrating.
Are you paying him to do this? No, right? When he has time, he can look at it and implement it. He has his own life and it doesn't revolve around an open-source project. It's good to always remember that developers have lives too. You were very rude in that comment of yours.
Reacted by steupz, abitorae, Tethergate Enterprises, Ryan Conrad Salazar and Ujhhgtg
I have been requesting this exact feature for two months now, and still zero progress. At this point, I honestly can't tell if the developer just lacks the technical skills to figure out how to implement it, or if it's just pure laziness. Either way, it's really frustrating.
Are you paying him to do this? No, right? When he has time, he can look at it and implement it. He has his own life and it doesn't revolve around an open-source project. It's good to always remember that developers have lives too. You were very rude in that comment of yours.
I understand how open-source works, and I fully respect the developer's time and personal life. My frustration doesn't come from the delay itself, but from the complete radio silence.
Leaving a highly requested issue hanging for two months without even a simple "I'm busy right now" or "This is too complex to implement" is what led to my assumption. A quick 10-second reply to manage expectations would have prevented this entirely.
If my wording was too harsh, I take that back. But as users, we just want basic communication, not magic overnight.
This feature is certainly not of high priority of Vector.
From a technical viewpoint, if you execute invalidate inline hooks for a module injected into the target app, then the module is only effective for a very short of time (till the chosen time we decide to invalidate in the actual implementation), and hooks won't be effective at all when you actually interact with the app.
There does exist need for such short-time window modifications, and it is better implemented as a Zygisk module.
@Hassinalhadi After all, from my undertanding of this context, you were simply testing if an app can detect Xposed injection, which is not a practical need for most users at all. Xposed detection for injected app is trivial.
Current priority of Vector is UI refactoring, which I still struggle of finding time slots to do.
P.S.: GitHub is a technical platform, not an after-sale service platform. A maintainer saying something I'm busy right now doesn't help to resolve any technical issues.
We are in need of experienced developers for such highly technical projects. When my start-up is making actual profits, I will hire people to develop some of my projects.
This feature is certainly not of high priority of Vector. From a technical viewpoint, if you execute invalidate inline hooks for a module injected into the target app, then the module is only effective for a very short of time (till the chosen time we decide to invalidate in the actual implementation), and hooks won't be effective at all when you actually interact with the app. There does exist need for such short-time window modifications, and it is better implemented as a Zygisk module.
@Hassinalhadi After all, from my undertanding of this context, you were simply testing if an app can detect Xposed injection, which is not a practical need for most users at all. Xposed detection for injected app is trivial.
Current priority of Vector is UI refactoring, which I still struggle of finding time slots to do.
P.S.: GitHub is a technical platform, not an after-sale service platform. A maintainer saying something I'm busy right now doesn't help to resolve any technical issues.
We are in need of experienced developers for such highly technical projects. When my start-up is making actual profits, I will hire people to develop some of my projects.
Thank you for taking the time to provide this detailed technical explanation. I appreciate you breaking down the limitations of invalidating inline hooks and explaining why a Zygisk module would be a more practical approach for this.
For context, my goal wasn't just trivial testing, but rather dealing with highly aggressive root and hook detections in certain restricted apps. However, I completely understand your reasoning and why this doesn't fit Vector's current priorities.
I also accept your point about GitHub being a technical platform rather than a customer service desk. Point taken.
I will look into the Zygisk route for my specific needs. Good luck with the UI refactoring, and I genuinely wish you the best of luck with your startup!
Following #921, I opened #1013 with a central application list as an alternative. I understand the earlier preference for the application's drawer on a module's scope page. Since the underlying setting is already shared across modules, that placement may suggest independent per-module choices. If the behavior were actually module-specific, I would keep the control there and would not propose a central list.
The PR retains the existing cleanup implementation and documents its validation and compatibility limits.
Activity
JingMatrix commentedon Apr 6, 2026
Do you mean that #634 doesn't happen for other targeted applications, such as
Instagram?Hassinalhadi commentedon Apr 6, 2026
No, it happens with other apps as well. If I target any app (even Instagram), it forces closes immediately.
JingMatrix commentedon Apr 6, 2026
@Hassinalhadi In this case, are other Xposed modules working on your devices with Vector ?
Hassinalhadi commentedon Apr 7, 2026
Yes, other Xposed modules are working fine with Vector on my device. The force close issue seems to happen specifically when using this module
JingMatrix commentedon Apr 7, 2026
@Hassinalhadi Your issue is likely to be a problem of the module, did you try to contact the module developer ?
JingMatrix commentedon Apr 7, 2026
Here are the logs:
AndroidFakerwith different targets #634 as a duplicate of this issue[-][Feature Request] Implement "Invalidate inline hooks" to prevent target app crashes[/-][+][Feature Request] Implement "Invalidate inline hooks" to bypass detection points[/+]sujanf5 commentedon Apr 17, 2026
Same problem with some specific app like TextNow, DevCheck in Android 15 and 16 based roms
xhdie commentedon May 9, 2026
Some apps use digital encryption, so if you hook these apps, it won't work unless you use “Invalidate inline hooks”.So I think the feature is useful.Hopefully you'll add the feature.
Hassinalhadi commentedon May 9, 2026
I have been requesting this exact feature for two months now, and still zero progress. At this point, I honestly can't tell if the developer just lacks the technical skills to figure out how to implement it, or if it's just pure laziness. Either way, it's really frustrating.
Dev4Mod commentedon May 9, 2026
Are you paying him to do this? No, right? When he has time, he can look at it and implement it. He has his own life and it doesn't revolve around an open-source project. It's good to always remember that developers have lives too. You were very rude in that comment of yours.
Hassinalhadi commentedon May 9, 2026
I understand how open-source works, and I fully respect the developer's time and personal life. My frustration doesn't come from the delay itself, but from the complete radio silence.
Leaving a highly requested issue hanging for two months without even a simple "I'm busy right now" or "This is too complex to implement" is what led to my assumption. A quick 10-second reply to manage expectations would have prevented this entirely.
If my wording was too harsh, I take that back. But as users, we just want basic communication, not magic overnight.
JingMatrix commentedon May 9, 2026
This feature is certainly not of high priority of Vector.
From a technical viewpoint, if you execute
invalidate inline hooksfor a module injected into the target app, then the module is only effective for a very short of time (till the chosen time we decide toinvalidatein the actual implementation), and hooks won't be effective at all when you actually interact with the app.There does exist need for such short-time window modifications, and it is better implemented as a Zygisk module.
@Hassinalhadi After all, from my undertanding of this context, you were simply testing if an app can detect Xposed injection, which is not a practical need for most users at all. Xposed detection for injected app is trivial.
Current priority of Vector is UI refactoring, which I still struggle of finding time slots to do.
P.S.: GitHub is a technical platform, not an after-sale service platform. A maintainer saying something
I'm busy right nowdoesn't help to resolve any technical issues.We are in need of experienced developers for such highly technical projects. When my start-up is making actual profits, I will hire people to develop some of my projects.
Hassinalhadi commentedon May 9, 2026
Thank you for taking the time to provide this detailed technical explanation. I appreciate you breaking down the limitations of invalidating inline hooks and explaining why a Zygisk module would be a more practical approach for this.
For context, my goal wasn't just trivial testing, but rather dealing with highly aggressive root and hook detections in certain restricted apps. However, I completely understand your reasoning and why this doesn't fit Vector's current priorities.
I also accept your point about GitHub being a technical platform rather than a customer service desk. Point taken.
I will look into the Zygisk route for my specific needs. Good luck with the UI refactoring, and I genuinely wish you the best of luck with your startup!
bartasc4 commentedon Oct 17, 2026
Following #921, I opened #1013 with a central application list as an alternative. I understand the earlier preference for the application's drawer on a module's scope page. Since the underlying setting is already shared across modules, that placement may suggest independent per-module choices. If the behavior were actually module-specific, I would keep the control there and would not propose a central list.
The PR retains the existing cleanup implementation and documents its validation and compatibility limits.