0bbedCode
commented
4 weeks ago Adding a wizard to all items can be very challenging especially given this is a Dynamic Framework that would be users who define hooks would not have control over that stuff on top of that for every item can be SPAM.
The amount of Hooks would just be pure chaos and Spam It would make people very very upset. XPLEX Is NOT comparable to your typical Android Spoofer or PMP Apps where they have a small set of defined hooked where as XPLEX has Hundreds and more accounting every day. Top of that if a user defines there own how can they have control over that pop up ? Then would have to make a new UI For that (If I can pull that together, then people would not know how to use or why to use that) if they don't use that should it just break the Hook ? Then will have to group them all so it lowers the spam etc
Something like that may or most likely not be implemented as this takes away things from users and or adds things that bombards them with spam and slows down performance. To Keep the Dynamic Aspect and Complete or Almost Complete user Control over Hooks, Behaviour what not I cant do much "simplifying" . Look at it as I provide the GATE you decide what goes through that gate , you are responsible but with that you get alot of control and have a dynamic system.
System like a Wizard can stray further away from being Dynamic and more Static essentially locking users what I give them.
Now its not impossible I can add a API for LUA to Popup with a notification for them to help control the Hook but adding this to all Hooks already in the system then syncing them then storing cache for all options then crossing my fingers as a dev no one renames the hooks (forcing them to be static) then ignoring new hooks as no way to create that wizard (if I'm going to be internally building it) would be Hell for both users and me.
If this was app like PMP or AndroidSpoofer where they statically force you Hooks without you having the ability to modify them then 100% would ! Unfortunately these are are not the same those are Daggers while this is a Sword of Excalibur , but to remain "Excalibur" it has not much room for "Simplifying" else users would have issues of control or lack of options (retaining to dynamic defs and hook behaviour LUA code control).
As time passes I will be making videos what not even trying to group things better but with great power comes great responsibility, I provide the power so now DESTROY!!!!
Here are some tips:
Select ONE Hook group set the settings (this ALL can be done in the new Hooks UI i made took hours and hours on!!!) then open the app, rinse and repeat for every group UNTIL you notice one of the groups selecting it crashed the app. So within that group uncheck it select each individual hook until you hit the bad one.
Now finally I have also spent HOURS putting effort in warning the users (On the main UI I just realized I didn't add the warning prompts in the new Hooks UI) So when you select a Hook that is KNOWN for causing issues such as "Spoof SOC EX" It WILL warn you and if you as a user choose not to read and or ignore that message, well yea ....
That's the issue with this Project (Dynamic Def allowing users to Control Hooks and their Code > Locking Users in but having silly popups and help menus)
Let me know what you think, reply with your though im open to ideas please thank you
If we restrict or deny all privacy permissions for an application, the application may refuse to run or become unresponsive. Sometimes, we need to make a trade-off by granting minimal privacy permissions to an essential but intrusive application for daily convenience.
However, identifying which specific privacy permission block prevents the application from running is not straightforward.
Could you consider designing a step-by-step wizard that activates when the application starts? This would allow us to initially block all requests using XPL-EX after installing an application. Then, upon starting the application, we could have a screen that lets us allow or deny privacy permissions individually for clearer decision-making. This approach would help us easily identify which specific denial causes the application to become unresponsive.
For example:
2024-01-01 16:30:33 chrome requested PrivacyEX.Build.SERIAL access Real value: ABCD23123-real-serial Spoof value: 12345678-spoofed-value
User decision buttons: [Spoof once] [Spoof always] [Block request] [Allow real once] [Allow real always] [Change spoof value]
Note: In the XPrivacyLua Pro version, there are logs that show which privacy queries an application requests, but they are not user-friendly for debugging or setting which permissions block the application's functionality.