Database Develop

Xposed API changelog / developer news

This thread is intended for module developers. Make sure you follow it (i.e. subscribe) to be informed about any API changes and additions.
I will announce changes before the release if they might make existing modules incompatible.
If you're interested in more details, you can follow the GitHub repositories:
https://github.com/rovo89/XposedBridge/commits/master
https://github.com/rovo89/Xposed/commits/master
https://github.com/rovo89/XposedInstaller/commits/master
Here you can also download the API jar file that you need to reference from your project. Make sure you read the development tutorial to understand how it works. Especially make sure that the classes are not included in your APK, but only referenced.
Note that I will only post the latest API version here to drive the adoption of updates.

This is on pretty short notice, but I have removed the method AndroidAppHelper.getActivityThread_mPackages(): https://github.com/rovo89/XposedBridge/commit/892ba9195da5516dd79f175ac95be2b313c8f8ca
It had been used internally some time ago. I scanned the modules which have been uploaded to the repository and didn't find any which uses this method.
Apart from that, I'm planning to make Xposed for command line tools (e.g. am and pm), implemented via IXposedHookCmdInit/initCmdApp(), optional and disabled by default. It is currently used only by App Settings (but unnecessary and therefore removed in the next version) and NFC LockScreenOff Enabler (I will contact the authors).
As the low usage shows, this feature is hardly needed, so there is no need to load Xposed every time such an app is started. It also avoids the additional log entries, which could be confusing for some users. Actually it is so rarely used that I might not even offer a setting in the UI for it, just a command file for experts. I will not remove it completely as it's useful for low-level framework development (I can quickly test whether my native code changes work without having to reboot).

Xposed 2.6 will bring support for replacing dimensions defined in code (instead of merely forwarding to your own resources): https://github.com/rovo89/XposedBridge/commit/48227c5b0a7ae3e3f81d76ad3bbaf017dc95614c
The new API will be published once that version is out. Until then, it would still be possible to make adjustments of the API. If you think anything should be changed, please let me know as soon as possible.

Ok devs, 2.6 beta1 is out, and so is the new API (version 52).
Here are the relevant XposedBridge changes to version 42 (internal changes/optimizations are not listed):
The resources API can be disabled via a debug setting in the UI. If your module implements IXposedHookInitPackageResources, it will not be loaded because it likely depends on this API. You can also check (but don't change) the status via XposedBridge.disableResources if you use the API in other ways.
Hooking abstract methods (including methods declared in interfaces) will throw an IllegalArgumentException now. The callback was never executed for them anyway. This change avoids debugging effort on your side because you will notice it immediately.
It's now possible to create a DimensionReplacement object and use it to replace "dimen" resources with values calculated at runtime. Previously it was only possible to forward such resources to your module. Example in the commit message: https://github.com/rovo89/XposedBridge/commit/48227c5b0a7ae3e3f81d76ad3bbaf017dc95614c
Removed AndroidAppHelper.createResourcesKey() methods and AndroidAppHelper.getActivityThread_mPackages() - weren't used by any module in the repository.
Fix delayed configuration update for forwarded resources. That's only of interest if your replacement resource contains variants for different qualifiers that might change at runtime (e.g. drawable-land/drawable-port). https://github.com/rovo89/XposedBridge/commit/1c81954e295cdda191cf8a1cf33d21d7c5ea334d
New findConstructorExact() / findAndHookConstructor() methods, similar to the one for methods: https://github.com/rovo89/XposedBridge/commit/a233fa0bc9499eadbe2efc0b49fc3f4a46264614
IXposedHookCmdInit is deprecated now, initCmdApps() won't be called anymore unless an undocumented file has been created. Only two modules used it, both got rid of it without any loss of functionality. This also averts situations like this where logging for tools like am/pm masks errors for Zygote.
Due to some internal changes, the constructor of XResources isn't called anymore (a good thing!), which breaks some features in App Settings (a not so good thing). That's because it relied on updateConfiguration() being called twice, so it could retrieve the package name in the second call and do its changes. A fix for that is on the way, using a new method (getPackageNameDuringConstruction()) added in the last minute, which returns the package name for a very specific situation. You will probably not need it.
Apart from that, there is now an official way to open a certain section in the installer:
Code:
Intent intent = new Intent("de.robv.android.xposed.installer.OPEN_SECTION");
intent.setPackage("de.robv.android.xposed.installer");
intent.putExtra("section", "modules");
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
Possible values for "section" are currently: install, modules, download, logs, settings, about.
You can for example use this to send the user to the module section if you find out that your module isn't active yet. The best way to find out is something like that:
Code:
// in your Activity, call it to find out the activation status
private static boolean isModuleActive() {
return false;
}
// in handleLoadPackage()
if (lpparam.packageName.equals("your.package.name")) {
// don't use YourActivity.class here
findAndHookMethod("your.package.name.YourActivity", lpparam.classLoader,
"isModuleActive", XC_MethodReplacement.returnConstant(true));
}
Do NOT try to read - or even change - the internal files of the Xposed Installer to get this information or force your module to be activated. Not only can this break anytime, it will also be bad user experience and a security threat if your module is active without explicit selection in the app. You will probably see your app removed from the repository if you break the rules.
If you have any questions or remarks, please let me know. And if you haven't subscribed to this thread yet, make sure to do so now in order to stay up-to-date with new developments.

IllegalAccessException if you use reflection yourself
One additional change in the new version was the removal of a hack that nuked some access checks in Dalvik by making them return "true" every time. After some of the other internal changes, some of the processing that required this hack was no longer necessary. With some more refactoring, I was finally able get rid of this hack. That's good because it caused crashes on some badly built ROMs (incorrect smali hacks), but also in some rare cases in normal apps: https://github.com/rovo89/XposedInstaller/issues/89
However, some modules relied on the deactivation of these access checks. Now they get IllegalAccessExceptions when trying to access e.g. private fields or methods.
Does this mean that Xposed used to cause security issues on the whole system? After all, it meant that any app could access things that they couldn't access otherwise, right? So it destroyed Java's security system!
The answer is: No, that wasn't a security issue! The Java access check system is actually optional. When you get a field/method/class via reflection, you just need to call setAccessible(true) on it to disable the access check. Example in XPrivacy: https://github.com/M66B/XPrivacy/co...430849f#diff-a350382a0ec1158ad9769d07bd754a63
Note that this is only needed if you use reflection yourself, e.g. with getDeclaredMethod() / getDeclaredField(). The methods in XposedHelpers call setAccessible() on the result before returning it to you.

2.6 final comes with XposedBridge v54.
The only changes relevant for developers are the addition of XSharedPreferences.hasFileChanged() and XSharedPreferences.getFile(), and a fix for replaced animation/xml resources. If you're using the latter and want to avoid that someone with the buggy version 2.6 beta1 runs into issues with your module, consider bumping the minimum required Xposed version to 54.

In Lollipop, there were a few architectural changes in Android. I hinted one of them in the Q&A:
The most significant one is that the code for system services has been moved to a separate file. For most of the affected modules, this can be solved by a little refactoring (moving code to a different place).
Click to expand...
Click to collapse
In detail, this means: If you want to hook a system service like PackageManagerService, you can no longer do that in initZygote(). Instead, move your code to handleLoadPackage() and check for dummy package "android". Make sure you use lpparam.classLoaders when looking for classes and hooking methods. This way has worked in older Android versions as well, so you don't lose backwards-compatiblity.

I'll just repeat here what I wrote in the official announcement thread, as it'll be helpful for all module developers:
rovo89 said:
After a long time with mainly bug fixes, version 81 focuses on improvements for developers:
There is a proper API now. Previously, I basically published the sources of XposedBridge.jar, which included many internal classes/methods that modules shouldn't use. Hiding them makes it easier to find the correct methods to use and also makes it easier for me to change implementation details.
The API is published on Bintray/JCenter, so it's easy to use, especially with Gradle/Android Studio. Full explanations here: https://github.com/rovo89/XposedBridge/wiki/Using-the-Xposed-Framework-API
100% of the API are documented with Javadoc now: http://api.xposed.info/
Apart from that, downloads have moved to http://dl-xda.xposed.info/framework/ and are GPG-signed now. You can verify them against this key (fingerprint: 0DC8 2B3E B1C4 6D48 33B4 C434 E82F 0871 7235 F333). That's actually the master key, the files are signed with subkey 852109AA.
There are no real changes for end-users in this release, nevertheless I would recommend that at least developers test their modules with it.
Click to expand...
Click to collapse

[Q] xposed, VPN, ICS & Auto VPN Dialog Confirm

I read the module FAQ and the code page and tried out module & xposed code and I was not able to get around my problem. I'm not sure that it was supposed to get around my problem though, but I was hoping to get your take on things. I can't find much data, though I can find a few people asking the same questions as I.
I installed an android 4.3 ROM (http://forum.xda-developers.com/showthread.php?t=2121063) on my phone and tried to connect to an OpenVPN based VPN provider. I got an error and contacted their support. Part of that process was to try another app, so we tried the OpenVPN COnnect app, the official OpenVPN app. I got a different error with that app.
One says that "your android firmware does not support the VPNService API("
OpenVPN Connect says "Sorry, due to a known issue in this version of android, it is not possible to gain permission to open a VPN tunnel"
There seems to be a few problems popping up with OpenVPN based VPNs in various Android 4.x OSs, but none complaine about 4.3 specifically. Usually they complain about 4.4 or back when 4.0 and 4.1 were new. I found this article talking about it on OpenVPN, and they're just pointing the finger, but I can't find the actual bug referenced:
https://forums.openvpn.net/topic13772.html
I came across your code on this page:
https://code.google.com/p/ics-openvpn/wiki/FAQ
And decided to try loading xposed and your module after emailing OpenVPN Connect and receiving a response right away. The guy who replied seemed to think the error is related to the fact that the confirmation acknowledgement dialog is not able to be summoned. I figured maybe the ROM wasn't bypassing it properly or missing some part of it, so I tried your way of bypassing it.
After loading xposed and your module, and selecting the 2 VPN apps, I still get the same results.
What are your thoughts? Should I give up and find a new ROM?

What are you talking about? If you're asking about a specific module (looks to me that way,) you should do that in the appropriate thread.

After some more research and experimentation yesterday, it's looking more like those OpenVPN clients that "support" the VPNServiceAPI actually *require* it, and that annoying/nasty little dialog that google enabled to "protect" the user just serves to piss off advanced users like me. This is my hypothesis at this point, though I have not confirmed this. I suspect this because I just tested on Jelly Bomb, a 4.1 based ROM and see the same results so far.
As far as what I was talking about in my OP, I copy/pasted an email to the author of the xposed module here and tried to reformat it to fit the message board, and apparently I missed a few pronouns. By far not the most egregious use of the English language I've seen on these boards, so what's with the attitude? I don't see specific sub forums for each and every module, so I don't get what you're implying. I only saw the one xposed board, so where else was I supposed to post?

No attitude, I honestly didn't understand how your issue was related to the Xposed framework. I just searched the repo for "VPN" and now see what you're talking about.
The Auto VPN Dialog Confirm doesn't have a thread here on XDA. Reading your post again, you're trying to use Xposed to fix a bug with the app if I'm not mistaken? I'd first try checking the logcat and forwarding that to the author of the VPN app if you haven't already.
I can't answer the rest of your questions since that's up to the module's author. That being said, it looks like a module specific question/request, not a framework query.

My understanding of the issue described here is different, probably because I'm trying to solve the same problem On the other hand, I'm not on ICS anymore, but am using Sammy 4.1.2 stock with DorimanX Kernel 8.43 at the moment.
OpenVPN should be usable for establishing a connection on boot. Out of the box, this creates a dialog to trust this application. Even though I trust it and confirm, there is no way of saving that preference permanently. It seems to be kept for a while (disconnect / reconnect doesn't trigger it again at least ) Therefore, it always reappears each time I boot.
The only possible solution I could find was the Xposed Module "Auto VPN Dialog Confirm" - the same module mentioned by the OP.
I used it together with the OpenVPN Client by colucci.web.it (paid version in my case, because I also wanted TAP support and auto connect functionality as well as the option of controlling it via Tasker).
After installing "Auto VPN Dialog Confirm" it recognized the installed OpenVPN client and offered to allow VPN API connections from it without confirmation. The VPN client also has an option to automatically create connections when Wifi is up and allows to be triggered either when seeing a specific SSID or when connecting to a network which does not have a specific SSID. The latter one is the typical condition for untrusted networks.
Therefore, it achieves what I wanted - being able to route my traffic via OpenVPN in case I'm not connected to my home WiFi
Regarding the issue encountered on ICS - maybe getting in touch with the Developer of the Xposed module might be the best option, unless someone else has already found a solution for it. It could also be good to exactly specify the OpenVPN client used as clearing the Xposed logfile and having "AutoVPN Dialog confirm" run as the only Xposed app (and fail). Afterwards, the log hopefully contains useful feedback for the developer to investigate further (Support URL listed for the module)

[Q] Sending information from hooks TO the settings screen?

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

[Q] Sharing data between Xposed module and activity

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

Hooking native code from xposed module?

Hello!
I am sorry if this may be confusing as I am quite sure I don't use the right terms. What I want to do is hook native library calls/syscalls made from native code within an app. I want to use xposed to launch the code that hooks the library/system call - but I do not know how to do and how the android system will complicate things for me.
Also, it seems to me that this has not been done. So my main thought with this thread is to get some input that can help me avoid some obvious pitfalls before I start trial and error.
What would my options be if I want to modify/interact with native code from a xposed module?
If it was a normal program I could simply use ptrace or LD_PRELOAD to get the kind of access I need. But as I want to do this from an xposed module I get worried by the android system.
If I for example hook the startup of the app, and then from the xposed hook use jni to ptrace myself - would that be possible, would I need to give the original app sudo permissions, and would my ptrace survive hiding/opening the app again?
Another thought was to, as previously at the startup of the app launch jni code. But in this case find the local symbol table and modify it to jump to my hook - but I am not sure if different jni code run in the same memory space and have access to mess with each other. [And also, how often would I need to redo this modification, would android reload/restart of the app destroy my changes]
Hopefully I didn't come off as too confusing. Thanks for the help!

I think you asked me this in my thread but Ill answer it here.
Also, it seems to me that this has not been done. So my main thought with this thread is to get some input that can help me avoid some obvious pitfalls before I start trial and error.
I have hooked native code with xposed and LD_PRELOAD, you can manipulate the data via your LD_PRELOAD lib. I do not know if its been linked to public code yet. LD_PRELOAD does not require Xposed to work(just makes it easier to manage imo). Also note that i have not tested this using the newer Android OS'es(>4.4). Not (yet)necessary for my use case. I would recommend getting LD_PRELOAD to work without Xposed first. Then add the Xposed integration
What would my options be if I want to modify/interact with native code from a xposed module?
If it was a normal program I could simply use ptrace or LD_PRELOAD to get the kind of access I need. But as I want to do this from an xposed module I get worried by the android system.
I have not tried via ptrace, also note that some apps will ptrace itself for protection against reversing. LD_PRELOAD works fine for me. Personally I use LD_PRELOAD to modify the arguments and the return values but most of the time just for logging information.
If I for example hook the startup of the app, and then from the xposed hook use jni to ptrace myself - would that be possible, would I need to give the original app sudo permissions, and would my ptrace survive hiding/opening the app again?
Ptrace to me sounds more complex but it does sound cool to attempt. No sudo is needed for the app that you are hooking using LD_PRELOAD.

t436h05t said:
I think you asked me this in my thread but Ill answer it here.
Also, it seems to me that this has not been done. So my main thought with this thread is to get some input that can help me avoid some obvious pitfalls before I start trial and error.
I have hooked native code with xposed and LD_PRELOAD, you can manipulate the data via your LD_PRELOAD lib. I do not know if its been linked to public code yet. LD_PRELOAD does not require Xposed to work(just makes it easier to manage imo). Also note that i have not tested this using the newer Android OS'es(>4.4). Not (yet)necessary for my use case. I would recommend getting LD_PRELOAD to work without Xposed first. Then add the Xposed integration
What would my options be if I want to modify/interact with native code from a xposed module?
If it was a normal program I could simply use ptrace or LD_PRELOAD to get the kind of access I need. But as I want to do this from an xposed module I get worried by the android system.
I have not tried via ptrace, also note that some apps will ptrace itself for protection against reversing. LD_PRELOAD works fine for me. Personally I use LD_PRELOAD to modify the arguments and the return values but most of the time just for logging information.
If I for example hook the startup of the app, and then from the xposed hook use jni to ptrace myself - would that be possible, would I need to give the original app sudo permissions, and would my ptrace survive hiding/opening the app again?
Ptrace to me sounds more complex but it does sound cool to attempt. No sudo is needed for the app that you are hooking using LD_PRELOAD.
Click to expand...
Click to collapse
Thanks! Is there a nice way to set LD_PRELOAD on app startup using Xposed or do you simply run the shell command when configuring which apps to hook?

Wropzter said:
Thanks! Is there a nice way to set LD_PRELOAD on app startup using Xposed or do you simply run the shell command when configuring which apps to hook?
Click to expand...
Click to collapse
Hooking the app and setting your native hooks is easy in Xposed, after you hook your package just load your lib with your hooks.
System.load("/data/data/org.xxx.app/lib/xxx.so");
The application will default use the preloaded lib you injected(same as LD_PRELOAD without the mess of bash).
It took more time to write code that would enable and disable the hooks inside the hook lib.

Now I have got it working with LD_PRELOAD manually, but using Xposed I do not seem to be able to load the library before libc - that is my replacement function is never called as the symbol was already loaded. Are you using the deprecated IXposedHookCmdInit to be able to load the package earlier? [If I remember correctly you were also hooking libc]

This is my code for the Xposed App.
if (lpparam.packageName.equals("app.to.hook")) {
System.load("/data/data/app.to.hook/lib/hook.so");
XposedBridge.log("Loaded native hook");
}