Xposed | native part of the Xposed framework | iOS library

Have you tried to simply adapt the available examples to your class and method?

aspect-ratio is not supported in your version of Safari for iOS. It will be available in Version 15.

You can use this padding trick in the interim.

Both code versions have one major problem:

Your hook can not work because you are trying to hook a method that does not exist: You are trying to hook the method getInstalledApplications() but that method does not exist, only the method [getInstalledApplications(int)][1] does exist and can be hooked.

You alerady notived that android.content.pm.PackageManager is an abstract class and the method getInstalledApplications(int) is abstract, too. As Xposed can not hook abstract Methods and Interfaces you have to specify the class that that actually implements the method getInstalledApplications(int).

The actual implementation of PackageManager is located in class android.app.ApplicationPackageManager as you already found out.

Therefore the correct hooking code is:

What you want to do is theoretically possible:

You can for example load the dex files of an app at run-time and examine every class and method and hook them. However this will have several significant drawbacks:

1. When hooking many functions in an app the execution is significantly slowed-down. Even on high-end device the users will not accept this. This will also increase the Android error messages about apps that are non-responsive because your Xposed module slows them down.

2. From my perspective the even worse problem is that the slow-down means of course that the CPU has much more work to do so that in the end you will drastically decrease the battery life by your Xposed module. So in the end your battery usage monitor app which uses the data governed by the Xposed module would have to show that more than 50% of the battery is consumed by Xposed and your module (just a raw estimation, can be up to 80%) because of the large number of hooked methods.

Method hooking is a technology that only works good if you just a few methods that are executed not very frequently.

Alternatively you can use it on special test devices for evaluating something (so it is not used on a regular device used every day). In this environment increased battery usage and slowed down apps are not very problematic.

We should use Context.MODE_PRIVATE and it will work!

When developing hooks it is not a good idea to use the application source code as base. It is recommended to use the compiled APK file and decompile it using a tool like apktool. The reason for this is that the compiled code sometimes looks a bit different to what you expect:

The method parameter definition ArrayList comprises of two sections:

1. The object type ArrayList
2. A (generics) type parameter MyObject

Generics were not part of the original Java definition and when this concept was later added it was restricted to the compiler. Therefore the generics type parameter only exists at compiler time in the method signature. In the app dex byte code and at rune-time you will only see the method test this way:

There a various methods for identifying the relevant methods.

The first and most important one is knowledge of the official Android API. All Java/Kotlin based apps at some point use the classes and methods defined i the API. And the most important fact is that because the Android API belongs to Android and not to the app it can not be obfuscated.

Second you can reverse engineer the app itself using tools like Jadx, apktool, Ghidra, JEB... Just make sure that the tool you use does not rename the class names (e.g. to avoid name collisions or make obfuscated class and method names better readable) or at least allows you always show you the original class and method name. Because trying to hook a method by it's name will fail if you use a name generated by the APK reversing tool.

Also a very helpful tool that allows to identify a lot o the internal on a running program is frida-trace. As long the the executed app has no anti-debugging or anti-frida measures in place you can attach frida-trace at any time to an app on a rooted device and create execution traces you can later use to hook the methods using xposed or directly using frida.