Remove All Ads from XDA

Xposed API changelog / developer news

2,559 posts
Thanks Meter: 68,996
 
By rovo89, Senior Recognized Developer on 11th April 2014, 08:12 PM
Thread Closed Email Thread
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/XposedInst...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.
Attached Files
File Type: jar XposedBridgeApi-54.jar - [Click for QR Code] (114.8 KB, 45677 views)
The Following 42 Users Say Thank You to rovo89 For This Useful Post: [ View ]
 
 
12th April 2014, 01:54 PM |#2  
rovo89's Avatar
OP Senior Recognized Developer
Thanks Meter: 68,996
 
Donate to Me
More
This is on pretty short notice, but I have removed the method AndroidAppHelper.getActivityThread_mPackages(): https://github.com/rovo89/XposedBrid...5be2b313c8f8ca
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).
The Following 11 Users Say Thank You to rovo89 For This Useful Post: [ View ]
1st May 2014, 02:49 PM |#3  
rovo89's Avatar
OP Senior Recognized Developer
Thanks Meter: 68,996
 
Donate to Me
More
Xposed 2.6 will bring support for replacing dimensions defined in code (instead of merely forwarding to your own resources): https://github.com/rovo89/XposedBrid...baf017dc95614c
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.
The Following 11 Users Say Thank You to rovo89 For This Useful Post: [ View ]
13th May 2014, 09:43 PM |#4  
rovo89's Avatar
OP Senior Recognized Developer
Thanks Meter: 68,996
 
Donate to Me
More
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/XposedBrid...baf017dc95614c
  • 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/XposedBrid...3d21d7c5ea334d
  • New findConstructorExact() / findAndHookConstructor() methods, similar to the one for methods: https://github.com/rovo89/XposedBrid...fc3f4a46264614
  • 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.
The Following 14 Users Say Thank You to rovo89 For This Useful Post: [ View ]
14th May 2014, 09:44 PM |#5  
rovo89's Avatar
OP Senior Recognized Developer
Thanks Meter: 68,996
 
Donate to Me
More
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/com...769d07bd754a63

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.
The Following 10 Users Say Thank You to rovo89 For This Useful Post: [ View ]
17th May 2014, 05:07 PM |#6  
rovo89's Avatar
OP Senior Recognized Developer
Thanks Meter: 68,996
 
Donate to Me
More
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.
The Following 17 Users Say Thank You to rovo89 For This Useful Post: [ View ]
14th February 2015, 11:38 AM |#7  
rovo89's Avatar
OP Senior Recognized Developer
Thanks Meter: 68,996
 
Donate to Me
More
In Lollipop, there were a few architectural changes in Android. I hinted one of them in the Q&A:
Quote:

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).

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.
The Following 24 Users Say Thank You to rovo89 For This Useful Post: [ View ]
3rd April 2016, 09:10 PM |#8  
rovo89's Avatar
OP Senior Recognized Developer
Thanks Meter: 68,996
 
Donate to Me
More
I'll just repeat here what I wrote in the official announcement thread, as it'll be helpful for all module developers:

Quote:
Originally Posted by rovo89

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/XposedBrid...-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.

The Following 14 Users Say Thank You to rovo89 For This Useful Post: [ View ]
Thread Closed Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes