Related
General information on Xposed has been moved to this thread: http://forum.xda-developers.com/xposed/xposed-installer-versions-changelog-t2714053
The FAQ has been moved to this thread: http://forum.xda-developers.com/xposed/-t2735540
Questions, suggestions, bug reports and so on can be posted in the Xposed General forum (for the installer/framework/development only) and in the Xposed Framework modules forum (for anything module-related).
Sounds interesting.I hope that you make a apk that simplifies things for simple user like rom control in AOKP
Keep up the good work my friend
That's great, decompiling/compiling apks is not really my cup of tea lol thanks rovo89
May be useful for my themes, keep working on it
Very interesting... Will try soon.
This looks like a really great idea and could help reduce the need for dev's being pestered by users for mod's every time a new rom is leaked/released, well done sir, hope to see this take off
I will definitely have a swing at this over the next few days. This looks like fun!
**This message will self-destruct**
Thanks for the "thanks" everyone. I decided to create an installer first before looking into the other things. This way, I hope a few people can test whether it works on their device (see first post for the APK).
Some notes about this:
The installer holds the app_process executable and the XposedBridge.jar as assets and can install it to the correct locations (root permissions required!).
It will automatically create a backup of /system/bin/app_process at /system/bin/app_process.orig, which can be restored either via the app or via shell (e.g. adb, works in recovery as well).
I have only tested it on ICS (LPQ Stock). Honestly, I do not have the time to test it with anything below that. If somebody wants to do this, I can help you to get started with the code. app_process was not changed very often, so chances are rather good that it will work with only few changes.
The installer requires SDK15 (4.0.3) for the same reason.
Improvements for any part of the code are welcome! It should be easy to use for both users and developers.
(Un-)Installing the installer app alone does not change anything (at least not now). Please use the buttons inside the app.
The next step should now really be to load modules dynamically, I hope I can use standard installable APKs for that (although the framework will probably request enabling confirmation for technical and security reasons).
siberian tiger said:
I hope that you make a apk that simplifies things for simple user like rom control in AOKP
Click to expand...
Click to collapse
From what I read, Rom Control seems to be something like the Settings app for ROM-specific stuff? I am not so sure yet whether I want to implement generic settings in the framework.
Having a standard interface for setting loading/saving (like or using Android's Shared Preferences) would probably make sense. But the settings themself can be very different from module to module, so I would rather let those bring their own settings menus.
What I did though was to implement an installer. My idea how it should ideally work for end users:
Install the Xposed Installer
Click the "Install/Update" button in the installer
Install one or more modules
Configure the modules (if necessary)
Have fun!
Where "install" would mean that you can download the app from the Play Store or a website and install it with the usual package manager. At least for steps 1 and 2, this is working already. For the others, I have to see.
Dynamic module loading is implemented now as well. Modules are normal apps with a special metadata tag and an asset describing which classes to load. You can look at my modifications for examples how this works. I think it is quite simple to develop and use.
I feel that Xposed is quite stable right now. It should be very easy to install both the framework and the modules without any knowledge about modding.
Also for developers, creating a new module is not too complicated. If anyone wants to give it a try, I'm happy to help you getting started. I'm convinced that Xposed is great alternative to APK modifying, but it will not work without developers creating modules for it.
Speaking of modules, I have published one for the famous CRT off effect: http://forum.xda-developers.com/showthread.php?t=1583963
The source code is also available at Github. See how it has less than 40 lines (and only about 10 LOC)? I think that this is awesome!
I was not able to install it as normal app hence pushed them to system/app using root explorer.
It works perfectly on XXLPS SENSATION ROM ICS V 3.2
Sent from my GT-I9100 using Tapatalk
OK you got me interested
What is currently holding me back is a lack of "documentation" about how to go about doing things...
Is there any reference info (even source code comments) that I should have a read of?
Or perhaps a little worked-through guide as to how you made the screen-off or red-clock one, complete with the "thinking" behind it all, just to learn the thought process.
This seems potentially hugely useful for me, just need to know what it can do!
Diliban said:
I was not able to install it as normal app hence pushed them to system/app using root explorer.
Click to expand...
Click to collapse
Really? Oh. Did you get any error message? I assume you have allowed installation of non-market apps?
@pulser_g2: Feedback taken! Until now, I focused on bringing Xposed to a level where it is actually doing something useful for end-users.
As there are some steps that can not be documented easily in the source code (e.g. how you mark an app as Xposed module), I will recreate a tutorial how you can create the clock example. I will try to give many details not only what to do, but also how you can know that you need to do this.
TUTORIAL - How to create an Xposed module
The tutorial has been moved to https://github.com/rovo89/XposedBridge/wiki/Development-tutorial
this is one of the most amazing projects made lately.
You are unleashed the best way to handle mods and possible some hacks.
very great work, robo89
Great concepts mate. Very powerful.
Wouldnt this also expose a device to malicious coders?
If a device has this implemented then is it possible that a simple theme could contain something nasty.
Not trying to stop progress of this project just throwing this out there for consideration.
----------------------
GTI9100 KK5
aceofclubs said:
Wouldnt this also expose a device to malicious coders?
If a device has this implemented then is it possible that a simple theme could contain something nasty.
Not trying to stop progress of this project just throwing this out there for consideration.
Click to expand...
Click to collapse
This is an absolutely valid thought.
In a way: Yes, it is easier to do something malicious with this. With great power comes great risk. The thing is: How would you prevent that? I couldn't think of any way once a module has been loaded, because a) how do you identify something malicious and b) how can you block it when it could just circumvent the security measure taken?
So what I did was to require that you enable a newly installed module in the installer. This at least avoids that you install any normal app and it contains a hidden Xposed module.
And not trying to play this question down, but you could insert malicous code in a theme also when you post a new framework.jar or SystemUI.apk. You could just change the smali code, compile it and you have similar power. For example, modifiying the constructor of the Activity class would also get you into any app and you could as well do whatever you want. You wouldn't even find these modifications because of the hundreds of classes in the Android framework. In this point, Xposed modules are easier to check, because they will usually contain just one class with very few and short methods.
Or take Superuser. Yes, it is asking you every time whether you want to execute this command. But the command can as well be a script that could replace files as the root user. Same for the kernel. In any case, when you modify anything in your phone, there is a risk that it is malicous.
As I said, I'm not denying that there could be a misuse of this project. But I do not see a chance to prevent it without blocking even simple real-life modifications. If anybody has ideas, please let me know.
rovo89 said:
This is an absolutely valid thought.
In a way: Yes, it is easier to do something malicious with this. With great power comes great risk. The thing is: How would you prevent that? I couldn't think of any way once a module has been loaded, because a) how do you identify something malicious and b) how can you block it when it could just circumvent the security measure taken?
So what I did was to require that you enable a newly installed module in the installer. This at least avoids that you install any normal app and it contains a hidden Xposed module.
And not trying to play this question down, but you could insert malicous code in a theme also when you post a new framework.jar or SystemUI.apk. You could just change the smali code, compile it and you have similar power. For example, modifiying the constructor of the Activity class would also get you into any app and you could as well do whatever you want. You wouldn't even find these modifications because of the hundreds of classes in the Android framework. In this point, Xposed modules are easier to check, because they will usually contain just one class with very few and short methods.
Or take Superuser. Yes, it is asking you every time whether you want to execute this command. But the command can as well be a script that could replace files as the root user. Same for the kernel. In any case, when you modify anything in your phone, there is a risk that it is malicous.
As I said, I'm not denying that there could be a misuse of this project. But I do not see a chance to prevent it without blocking even simple real-life modifications. If anybody has ideas, please let me know.
Click to expand...
Click to collapse
It is so refreshing to see someone take such a mature approach as this.
I greatly appreciate your time on that tutorial, and I will take a proper read through it while working it out myself later... (on vacation right now, this seems like a good thing to try if it rains )
Regarding security, I guess you could add a way to protect WHAT was being edited... Such that your package needed to declare edit access to package X and Y, and if it doesn't have permission, it can't do it... This way, if I want to interfere in Gmail, the user must agree, and he/she will say "well... Why is my no battery sound tweak touching gmail?" But this obviously doesn't help for frameworks and services where they are all in the one file... :/
pulser_g2 said:
Regarding security, I guess you could add a way to protect WHAT was being edited... Such that your package needed to declare edit access to package X and Y, and if it doesn't have permission, it can't do it... This way, if I want to interfere in Gmail, the user must agree, and he/she will say "well... Why is my no battery sound tweak touching gmail?" But this obviously doesn't help for frameworks and services where they are all in the one file... :/
Click to expand...
Click to collapse
Maybe.. I could rather easily implement something in hookMethod that checks the method to be hooked against a whitelist defined in an asset in the module (which could of course contain wildcards). Then when you enable a module, I could display this whitelist, with a warning if it includes some very central classes/packages/methods (but how to create such a list?).
However, this cannot control the following:
What you do inside the handling method. If you change anything in SystemUI (and that might be only the battery icon or the clock color), this method will be executed in the context of the SystemUI, which has a large set of Android standard permissions.
Calling any methods of the framework and modifying any available variables, as this can be done via standard reflection.
Basically anything that is not handled through XposedBridge, but using standard techniques.
Wanted to install the framework, but i am getting:
sh: /data/data/de.robv.android.xposed.installer/cache/install.sh: no such file or directory
What am i doing wrong ?
(I am new and cannot post in dev forum, that's why I posted this here. Still hope someone will be able to help.)
Is there a way to get crash-dumps out of Windows Phone 8 during development time? I am after a file that is dumped similarly to when a normal Win32 app crashes. Or similar to what is saved on iOS devices at crash to be investigated at a later point.
My question is specifically about somehow retrieving this (or similar) file/info from the phone after a crash without me having to do anything in my code e.g. manually writing the stack trace to a file from an unhandled exception.
I am aware the option of getting "live" crash reports from a beta-submitted app but that is not what I am after.
Thanks!
Can Visual Studio's debugger generate crash dumps? I'd expect so (I know windbg can, but I haven't managed to attach windbg to a phone app) and that would be the obvious approach.
Not sure why you want a dump when you can do live debugging, though...
GoodDayToDie said:
Can Visual Studio's debugger generate crash dumps? I'd expect so (I know windbg can, but I haven't managed to attach windbg to a phone app) and that would be the obvious approach.
Not sure why you want a dump when you can do live debugging, though...
Click to expand...
Click to collapse
Hmmm, I never thought of using windbg because that never came up as a tool that is used with WP8.. Will give it a try and see if I get anywhere.
I need a crash dump because the crash does not happen when a debugger is attached.
I am trying other options to catch the issue: isolating the code the crash might happen, dump the stack trace into a log file, but a crash log would be the most obvious place to look at and I am shocked that it is not possible or at least this hard.
There's a way on the ATIV S to get crash dumps (without even crazy hacks, I mean; it's a hidden option in the Diagnosis application) but I think they're only for the OS, not for individual apps.
A crash that only happens without the debugger attached is a very irritating sort of crash!
GoodDayToDie said:
There's a way on the ATIV S to get crash dumps (without even crazy hacks, I mean; it's a hidden option in the Diagnosis application) but I think they're only for the OS, not for individual apps.
A crash that only happens without the debugger attached is a very irritating sort of crash!
Click to expand...
Click to collapse
Amazing, I have access to an Ativ S device so will give a try! Thanks!
I have got a confirmation directly from Windows Phone team: what I am asking for is not possible at the moment.
I have provided them feedback on what kind of situation this can put some developers, I hope they will consider it and look into doing something about it.
In the meantime your options are to manually dump the stack trace (along with any info you want) from an unhandled exception or to upload your app for beta testing and check the crashlogs on the dashboard of your developer account.
Yeah, sorry. I should have mentioned that my approach is to always implement a custom unhandled exception function (there's a stub for it in App.xaml.cs) and either present an error message or write an error file. It's not a true crash dump, but it's often enough to help you find the spot where the problem occurred.
Hmm... I wonder how hard it would be to write a native component that would generate a crash dump on demand. I mean, it *should* be possible to do it, since you have raw pointer access and file I/O. I've just never tried.
I'd like to hook the query() method in ContentProvider in order to get to know which applications are accessing the personal information(e.g: contacts, sms) stored in the device. By reading the tutorial, we know that we can hook methods in app packages. However, what can we do when the methods we want to hook are in those system components? Any suggestion is appreciated.
x11911778 said:
I'd like to hook the query() method in ContentProvider in order to get to know which applications are accessing the personal information(e.g: contacts, sms) stored in the device. By reading the tutorial, we know that we can hook methods in app packages. However, what can we do when the methods we want to hook are in those system components? Any suggestion is appreciated.
Click to expand...
Click to collapse
Well first off, you can't hook ContentProvider.query() because it's an abstract method (at least one of the two variants). So you would have to hook the subclasses that provide an implementation for this method.
You would also need to clarify what you mean with "system components". I think some of these providers are implemented in system apps, so you would hook them like any other app. Others might be part of the system process (system_server), which also hosts all the system services like package manager etc. Simply use the special package name "android" for these, otherwise handle it like a normal app. And then there might be cases where you want to hook a Android framework method on the whole system. You would do that in initZygote().
In all cases, you would first have do identify a good place to hook into, then find out when to place the hook (as described above) and then use findAndHookMethod().
rovo89 said:
Well first off, you can't hook ContentProvider.query() because it's an abstract method (at least one of the two variants). So you would have to hook the subclasses that provide an implementation for this method.
You would also need to clarify what you mean with "system components". I think some of these providers are implemented in system apps, so you would hook them like any other app. Others might be part of the system process (system_server), which also hosts all the system services like package manager etc. Simply use the special package name "android" for these, otherwise handle it like a normal app. And then there might be cases where you want to hook a Android framework method on the whole system. You would do that in initZygote().
In all cases, you would first have do identify a good place to hook into, then find out when to place the hook (as described above) and then use findAndHookMethod().
Click to expand...
Click to collapse
Thanks a lot, that really helps~
Problem
would you mind give me a example (like a code) about how to hook the query() method? I really confused about that. Thanks a lot!!!!
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
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