I've read a couple of threads on the "context" that my module runs in, but I'm not clear on how I send data from my module (running in the hooked application context) back to my settings screen (running in the Xposed context?)
XSharedPreferences is obviously read only, so that doesn't work. I'm guessing I need to write to a file and parse it back from settings, but I'm hoping someone can set me in the right direction. Is there a module that already does this so I can look at the source? Or can someone give me a high level of the file permissions/location/settings to use so that it's readable/writable from both contexts?
Thanks!
Ryan
I'd say your best option is to register a broadcast receiver in your app, and send a broadcast from the hooked app (you just need a Context to do that.
If you can't get one from the app, you could use AndroidAppHelper.currentApplication()).
GermainZ said:
I'd say your best option is to register a broadcast receiver in your app, and send a broadcast from the hooked app (you just need a Context to do that.
If you can't get one from the app, you could use AndroidAppHelper.currentApplication()).
Click to expand...
Click to collapse
Thank you! I got it. I guess that was obvious, but it seemed like there might be a "tighter" way to do the cross-process communication using Xposed as a bridge.
Thanks for all of your help in this forum,
Ryan
Hi,
I have an Xposed module that listens for certain events and then notify the main application/Activity that contains this module about the events. I tried to put the events into a static buffer class that's accessible from both the module and Activity. But the buffer is always empty. Right now, I have to use Broadcast to achieve the notification. Is it impossible to share data between the module and Activity via static in-memory objects? Thank you!
AFAIK, you can't do it like that when xposed module runs in a different process than your app.
Xposed module hooking on one package and your app package are isolated processes that cannot share memory.
One way is to use broadcast, as you mentioned.
Another way is to create a service within your app and use ServiceConnection to bind to it and execute actions on it
Example of such service: https://github.com/GravityBox/Gravi...o/kitkat/gravitybox/KeyguardImageService.java
Example how that service is called from system context (different process): https://github.com/GravityBox/Gravi...m/ceco/kitkat/gravitybox/ModDisplay.java#L521
Inside the actual Google ChromeCast for Android, under the devices tab, you can see all of your ChromeCasts, their status, and a Play/Pause and Stop button for each one.
I've been trying to figure out how to trigger any of these Play/Pause or Stop actions through Tasker. Anyone figure it out? I can't seem to pickup an intent from LogCat or from a Secure Settings activity check. I know I can probably use AutoInput and simulate button presses....but that is a super sloppy way of doing this. I would think there should be some way to directly send these commands through Tasker.
Anyone figure something like this out? FYI AutoCast is not able to do this.....That app is junk when it comes to controlling Casts originating from other Apps.
Stupifier said:
Inside the actual Google ChromeCast for Android, under the devices tab, you can see all of your ChromeCasts, their status, and a Play/Pause and Stop button for each one.
I've been trying to figure out how to trigger any of these Play/Pause or Stop actions through Tasker. Anyone figure it out? I can't seem to pickup an intent from LogCat or from a Secure Settings activity check. I know I can probably use AutoInput and simulate button presses....but that is a super sloppy way of doing this. I would think there should be some way to directly send these commands through Tasker.
Anyone figure something like this out? FYI AutoCast is not able to do this.....That app is junk when it comes to controlling Casts originating from other Apps.
Click to expand...
Click to collapse
Xposed and autoshare intercept are your friends. Go go go!
loogielv said:
Xposed and autoshare intercept are your friends. Go go go!
Click to expand...
Click to collapse
I actually have both Xposed and Autoshare......could you give me a little more information? Which Xposed module? I'll be searching around int he meantime. Thanks though
A simple search for "ChromeCast" in xposed downloads doesn't really give much......is BubbleUPnP xposed module the one you are thinking of?
the problem is, i use OP5T, and none of any 8.0/8.1 stock custom rom does support 18:9 scaling feature like in OOS, this feature named as "Full Screen Apps" under app category.
after a few googling, i came up with these method:
1.) add/inject/force this into manifest file of every installed app. or maybe doing some workaround with the packagemanager
<meta-data android:name="android.max_aspect" android:value="2.1" />
Click to expand...
Click to collapse
2.) playing inside AOSP source code, parsePackage method.
frameworks/base/core/java/android/content/pm/PackageParser.java.
Click to expand...
Click to collapse
i know nothing of creating xposed module, but before starting my journey, is it possible to do the first method with xposed?
after seeing module like Xinstaller, App Settings, and XAspect. i thought it may be possible with xposed to approach this.
really appreciate every kind of help, thanks before
I can see at least two solutions there.
The first one, probably the most simple.
1)
Hook parseMetaData method to add
android.max_aspect to returned bundle in after hook (if doesn't already exist)
2)
Hook setMaxAspectRatio
Get mAppMetaData of passed Package (owner.mAppMetaData) in before hook and add android.max_aspect to it (if doesn't already exist)
Edit: Apart from <meta-data> app dev can also specify aspect ratio within <Activity> element in the manifest.
This has higher priority over <meta-data> so the best solution would be to hook setMaxAspectRatio of Activity class and modify maxAspectRatio parameter to desired value in before hook.
We are now working on the new Xposed API, which allows modules to get / set scope, to get framework info, and to store configs across apps without the embarrassing New-XSharedPreferences interface. The API library will be released to GitHub/libxposed and maven central after it is ready.
Now we are considering removal of resources hook in the incoming new API, so we need to know whether it is still needed or unreplaceable for some modules.
About why we want to remove this API: Resources hook is very hard to maintain and is even not fully supported now under some frameworks (e.g. Taichi). So even if we keep it, it will be maintain-only.
Old modules can still use this feature. We are just considering remove it in the new API.
You can vote at the LSPosed Telegram group or write your opinion here. Also we are glad to hear your suggestions about the new API.
@AndroidX @siavash79 @Dark_Eyes_ @firefds @David B. @Quinny899 @wanam
Just mentioning you guys since you're all active here on XDA. Please see the first post.
Regards,
shadowstep
Senior Moderator
Dr-TSNG said:
We are now working on the new Xposed API, which allows modules to get / set scope, to get framework info, and to store configs across apps without the embarrassing New-XSharedPreferences interface. The API library will be released to GitHub/libxposed and maven central after it is ready.
Now we are considering removal of resources hook in the incoming new API, so we need to know whether it is still needed or unreplaceable for some modules.
About why we want to remove this API: Resources hook is very hard to maintain and is even not fully supported now under some frameworks (e.g. Taichi). So even if we keep it, it will be maintain-only.
Old modules can still use this feature. We are just considering remove it in the new API.
You can vote at the LSPosed Telegram group or write your opinion here. Also we are glad to hear your suggestions about the new API.
Click to expand...
Click to collapse
Thanks for getting opinions
1. Xshared preferences interface overhaul is good news since it was always unstable for me. I personally switched to remote preferences API for AOSPMods
2. When going to systemUI and framework, it's sometimes very difficult and complicated to change some variable values through Xposed, specially with R8 code optimizations which dramatically limit the points we can hook into code.
There are two workarounds I know of, being Xposed resource hooking that can be also dynamic in runtime, or overlays, which being static, still limit the way we can change resources dramatically.
So, I'd really suggest keeping it in the API
siavash79 said:
2. When going to systemUI and framework, it's sometimes very difficult and complicated to change some variable values through Xposed, specially with R8 code optimizations which dramatically limit the points we can hook into code.
Click to expand...
Click to collapse
For R8 code optimizations, we introduced a new API to parse dex file, which allows modules to find methods/fields more accurately.
Anyway if we finally decide to keep resources hook API, do you have any suggestions on keeping/adding/removing specific methods of it or refine it to a more modern interface?
Perfect news.
About resource hooking, few things to note are that: it can't differentiate between different resource files, for example normal values vs landscape or dark/light values. It would be great if there's a way to push different values to different resource files.
Also, there are more limitations when talking about special resources such as themes. As an example, in AOSPMods, one of the reasons it's a magisk module instead of being a normal APK is that overlay files have to be used in cases that need modification of theme resources and that can't be done via resource hooking.
I personally love to get a more complete/flexible resource hooking API, but I completely understand if that's too much to ask. So even keeping it as currently is would be good enough
Thank you @shadowstep for bringing this to my attention!
Dr-TSNG said:
We are now working on the new Xposed API, which allows modules to get / set scope, to get framework info, and to store configs across apps without the embarrassing New-XSharedPreferences interface. The API library will be released to GitHub/libxposed and maven central after it is ready.
Click to expand...
Click to collapse
That's wonderful news, although I do not quite understand what you have against the new XSharedPreferences interface. I use it in my modules, and I've never had any issues with it.
Dr-TSNG said:
Now we are considering removal of resources hook in the incoming new API, so we need to know whether it is still needed or unreplaceable for some modules.
About why we want to remove this API: Resources hook is very hard to maintain and is even not fully supported now under some frameworks (e.g. Taichi). So even if we keep it, it will be maintain-only.
Old modules can still use this feature. We are just considering remove it in the new API.
Click to expand...
Click to collapse
I am not currently using the resources hook in any of my modules, so removing it would not impact me, but even so, I'm not a fan of the suggestion to get rid of it completely. I think that at the very least, it should be kept as maintain-only. It is unfortunate that it does not work with Taichi, but given that Taichi isn't a true Xposed implementation, I'm not sure that it's worth worrying about.
This looks great, I've been waiting for it since the initial issue talking about it. Prefs are always a pain to handle, and while the "new" method worked, I always preferred to use a Content Provider, which was nerfed in Android 12.
Really like the idea of setting the scope, it would be beneficial to the Xposed part of DarQ, the only suggestion I have is to make sure it includes some sort of "am I enabled?" check - currently I use self hooks (literally the module hooking itself and changing a method returning false to true) to verify it's enabled, but it doesn't seem to be foolproof as people sometimes still complain it doesn't work.
Quinny899 said:
the only suggestion I have is to make sure it includes some sort of "am I enabled?" check
Click to expand...
Click to collapse
Of course does, and the module app can get more info about the the Xposed state like it's under which framework and which version, and whether it is rootless or not without self-hooking.
You can view the detail here.
@shadowstep Thanks for the head up.
Glad to see a new api to manage configs across apps, shared prefs has been always painful to handle even with the new-xshared prefs.
I would suggest having an api to get the version name of scope's package, I'm aware of some workarounds that help get the version name, but it's not a reliable solution on the latest Android versions, this information is needed for logging/debugging purposes.
@Dr-TSNG thanks and keep up the good work.
@Dr-TSNG Thanks for new api I was wating for this api from more then 1 year coz when I build my first module (Android Faker) its was really pain in ass coz of Xsharedpreference after some research I found better solution which was remote preference but Quinny899 mention in Github issue that its not work in android 11 so after that I move to new Xsharedpreference which was introduce by lsposed team and its working great but its still create issue in some devices so I think it will be a better solution if we get it soon and I am not sure about resources hook coz I don't use it before .
The problem with xshared preferences is that if the apk is a system app it won't work for some reason. Only works on user apps
siavash79 said:
The problem with xshared preferences is that if the apk is a system app it won't work for some reason. Only works on user apps
Click to expand...
Click to collapse
Interesting. I use XSharedPreferences in a System Framework hook and haven't had any issues with it.
David B. said:
Interesting. I use XSharedPreferences in a System Framework hook and haven't had any issues with it.
Click to expand...
Click to collapse
Is your module installed as APK or as magisk module?
Try mounting it to system through magisk and preferences will stop working
siavash79 said:
Is your module installed as APK or as magisk module?
Try mounting it to system through magisk and preferences will stop working
Click to expand...
Click to collapse
It's installed as an APK. I misunderstood what you had said earlier. I thought you meant that the hook doesn't work when you try to use it on system APKs. I didn't realize that you meant that it doesn't work when the module is itself a system APK.
siavash79Yeah I agree with this and in my testing if you set target sdk 23 its doesn't matter if its as system app or user its work without any issues but its not worth coz it have some other issues
Thank you for accepting the API invokeSpecial() !
Add invokeSpecial · libxposed/[email protected]
Fix #2
github.com
Implement invoke special and new instance special · LSPosed/[email protected]
LSPosed Framework. Contribute to LSPosed/LSPosed development by creating an account on GitHub.
github.com
Looking forward to the new API release.
Happy Chinese New Year!
I just want to see @M66B happy again
Somewhat unrelated, but is there any chance of seeing original Xprivacy return or compatibility? I think it's a lot better than Lua
lawrencee said:
Somewhat unrelated, but is there any chance of seeing original Xprivacy return or compatibility? I think it's a lot better than Lua
Click to expand...
Click to collapse
No. Xprivacy will never "return".
XPrivacyLua is the best ever