Select the hook, click on "lua script" and then edit fake result.
I understand that I will probably be able to fake that the location is on.Probably, yes.
First, you need to know which methods for hooking on Android's source.
Here are source codes for android.location.*
That is the point.
I think we are not on the same page, so let me try to just confirm something first...
MediaDrm.getPropertyByteArray returns byte, as you can see here:
arrayClass:set(fake, index_element_here, content_element_here)
Thank you very much brother, I did it. ThanksMediaDrm.getPropertyByteArray returns byte, as you can see here:
https://developer.android.com/reference/android/media/MediaDrm#getPropertyByteArray(java.lang.String)So, you just need to create a new array containing the bytes you want to return in setResult, as you can see here:
Just set a new content inside the array, like this:Really simple to use privacy manager for Android 6.0 Marshmallow and later - XPrivacyLua/mediadrm_unique_id.lua at master · M66B/XPrivacyLuagithub.com
arrayClass:set(fake, index_element_here, 'content here')
Yes, but your last position keeps "cached".I think we are not on the same page, so let me try to just confirm something first...
Do you agree with my theory that the device needs to first lock in via satellites (which can take a few minutes if wifi/bluetooth assistance is turned off) before it will provide location data to apps?
Meaning an app can request location data, but it has to wait for the device to first lock in it's position via sattellites (which can take a few minutes) before android will provide any location data to an app - do you agree with my theory?
Ok, now I know where you are coming from.Yes, but your last position keeps "cached".
So, app knows your last postion before to know your current position.
But, if Location is disabled, probably the system blocks it at kernel level, so there is nothing to do.
Certainly, it would be easier to keep Location enabled and let an app think the Location is turned off (or the device is located at another fake position).
I am using Pixel 6 Android 13, xprivacylua 1.32 with zgisk lsposed 1.83 6597.
@M66B was asking *you* what are the issues you are running into (besides you just saying that "it doesn't work on A13")
Restrictions don't work as expected. Before upgrading to Android 13, there are many restrictions logs available on xprivacylua pro app.
XprivacyLUA depends on Xposed (edXposed, Lsposed) working, so if your Xposed is not working, XprivacyLUA won't work.
Thank you mate, Lsposed works well for other modules on Android 13.
Gentlemen, I think I owe you a response. I approach our Forum Administrator @MikeChannon with this question and the information I've received is that it is no longer available and is no longer being developed. I'm convinced you're also aware that SRD @rovo89 who owned the repo hasn't been posted for more than 4 1/2 years. I suggest not to rely at all that any file, which was made available for download in that repo in the past, might be available in the future there.
Can you please check if this works too?I believe this is because `android.app.LoadedApk.makeApplication` works differently on Android 13, which is introduced by this commit.
Edit: Let me provide more details. I tried to hook `makeApplicationInner(bool, Instrumentation)`, but it didn't work somehow. Therefore, I looked into the function body and found that the returned `app` is actually created by `android.app.Instrumentation.newApplication`, which is why I made this modification.
XPrivacyLua is not a permission manager, but a privacy manager. XPrivacyLua doesn't block things and doesn't revoke permissions, but does replace real data by fake data. This means you can grant Android permissions to an app and still let XPrivacyLua prevent the app from seeing privacy sensitive data. Revoking permissions can result in an app refusing to work and/or to crash. However, replacing real by fake data generally doesn't let an app crash.
Currently restrictions are quite crude because they mostly replace real data by no data. For example restricting the contacts app from getting contacts will result in an empty contact list. In the near future it might be made possible to select the data an app may see, for example just one group of contacts.
The goal is to have a tool that can properly protect the privacy of many in the near future. However, it isn't paid work, so I do whatever I like whenever I like it.
You can request features in this XDA forum. I will read them, but I will not respond to them and they might or might not be implemented. If I know for sure something will not be implemented, I will let you know.
You can report any problem you have here. There will be no issue tracker on GitHub.
For now I have decided to not implement restrictions that are useful to prevent tracking only. There are simply too many data items that can be used for tracking and it would take too much time to develop restrictions for all these data items.
The basic idea is to restrict only things that 'define' you, so which contacts you have, where you are, which apps you use, etc.
XPrivacyLua is pretty feature complete and will be maintained and supported and when there is a need new hook definitions will be added to better protect your privacy. For the rest this FAQ applies:
As said before, development will also depend on Xposed development, which is just minimal unfortunately.