[BUG] All processes are loading modules

[elesbb]

Normally, only Zygote loads the modules. This version (93-v0.5.1.3_4646-master (SandHook)) is having every single process load modules from the apks. Just look at the log, and you will see what I mean.

all_loaded.txt

[Mikanoshi]

Ha, welcome to the nightmare. That's how EdXposed works now to keep zygote process "clean".
initZygote is being executed for every process separately. This introduces an unavoidable launch delay and litters logs with useless entries, basically a permanent app list mode. Have fun scrolling through all these module loading messages to find an actual error.

[elesbb]

Ha, welcome to the nightmare. That's how EdXposed works now to keep zygote process "clean".
initZygote is being executed for every process separately. This introduces an unavoidable launch delay and litters logs with useless entries, basically a permanent app list mode. Have fun scrolling through all these module loading messages to find an actual error.

The error isn't too hard to find in logcat with filters.

This method of hooking now breaks my module though. I have variables that are popping up as "null" when they never did before. My guess is for every process now loading the module, a new instance of that xposed class is created and some instances variables are not set, thus resulting in them being null.

I don't understand, what are the "benefits" of a "clean" zygote process? SafetyNet?

I could potentially set my variables to static but that would open up the possibility for memory leaks, speaking of, having every single process load every single module, is that not more taxing on the system? I definitely noticed the launch delay and thought something was janked in my phone. I do not like this new way of hooking. What was wrong with toggling app list mode for certain apps?

[Mikanoshi]

The error isn't too hard to find in logcat with filters.

I have an option in my module to send report to developer, it asks hooked system process to collect Xposed log, then compresses it and uploads to my server. Now logs are filled with megabytes of strings about modules being loaded :)

I don't understand, what are the "benefits" of a "clean" zygote process? SafetyNet?

Yes, and avoiding some apps like GCam crashing. They might detect that classes in a process were tampered with.
Totally useless for me as my GCam works perfectly fine and I don't use Google Pay or anything else that requires Safety Net.

I could potentially set my variables to static

If they are set in one method and then used in another you probably should.
And use new XSharedPreferences, because EdXposed now also lacks SELinux rule that allows system processes to read app data.

What was wrong with toggling app list mode for certain apps?

Idunno :)

[yujincheng08]

This is expected. Won't fix.

[elesbb]

This is expected. Won't fix.

Well why are variables becoming null all of a sudden? There is really no "easy" fix for it either as to completely control everything, one would need to write if (myVariable == null) return;, or I guess the easier thing would be to surround the main hook with a try catch block.

I really don't think this method is good on the device. Every single process is going to be loading another process (the xposed module) which is going to fill up the RAM and consume resources faster. Why was this the default instead of having the user select which apps to do this with?

[Mikanoshi]

Show your code, it's unclear what variables you are talking about. If you assign them in one process and then use in another then they will be null, you have to assign them again for each process.

[elesbb]

Show your code, it's unclear what variables you are talking about. If you assign them in one process and then use in another then they will be null, you have to assign them again for each process.

Error:

12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: java.lang.NullPointerException: Attempt to invoke virtual method 'void android.widget.RelativeLayout.setLayoutParams(android.view.ViewGroup$LayoutParams)' on a null object reference
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at com.elesbb.keyboardcustomizer.XposedInit$11.afterHookedMethod(XposedInit.java:455)
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at de.robv.android.xposed.XC_MethodHook.callAfterHookedMethod(XC_MethodHook.java:68)
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at com.swift.sandhook.xposedcompat.hookstub.HookStubManager.hookBridge(HookStubManager.java:394)
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at SandHookerNew_4mcon2opqkutkjmvgo9idi9hkl.hook(Unknown Source:63)
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at com.dexilog.smartkeyboard.ui.MainKeyboardView.a(MainKeyboardView.java:1435)
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at com.dexilog.smartkeyboard.ui.MainKeyboardView.c(MainKeyboardView.java:1400)
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at java.lang.reflect.Method.invoke(Native Method)
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at com.swift.sandhook.SandHook.callOriginMethod(SandHook.java:183)
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at com.swift.sandhook.xposedcompat.hookstub.HookStubManager.hookBridge(HookStubManager.java:380)
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at SandHookerNew_4f7qtfq5r09r656kguaf1ei6s4.hook(Unknown Source:51)
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at com.dexilog.smartkeyboard.ui.MainKeyboardView.a(MainKeyboardView.java:60)
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at com.dexilog.smartkeyboard.ui.MainKeyboardView$1.handleMessage(MainKeyboardView.java:275)
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at android.os.Handler.dispatchMessage(Handler.java:107)
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at android.os.Looper.loop(Looper.java:237)
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at android.app.ActivityThread.main(ActivityThread.java:8167)
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at java.lang.reflect.Method.invoke(Native Method)
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:496)
12-26 14:47:25.272  4888  4888 E EdXposed-Bridge: 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1100)

Code:

# This happens inside "onCreate" of the KeyboardView
myNewCustomEmoji = getMainLayout(context, horizontal, pager);

Where the crash happens:

# Happens inside another method of the same hooked process.
myNewCustomEmoji.setLayoutParams(params);

This code was not a problem until recently. I can guarantee you what is happening is the process crashing did not initialize in the same manner as the main one which actually hooks the keyboard. And this causes the variable to be null

[Mikanoshi]

Where is myNewCustomEmoji declared? It should be either static or handled by XposedHelpers.setAdditionalInstanceField()/getAdditionalInstanceField().

[elesbb]

Where is myNewCustomEmoji declared? It should be either static or handled by XposedHelpers.setAdditionalInstanceField()/getAdditionalInstanceField().

It is declared at the very top of the class right after the implements, so it is class wide accessible. Even if I used XposedHelpers.set(get)AdditionalInstanceField it would still be null for some processes.

public class XposedInit implements IXposedHookLoadPackage, IXposedHookZygoteInit, IXposedHookInitPackageResources {
...
    private RelativeLayout myNewCustomEmoji;

What is happening is the "onCreate" method is hooked, fills myNewCustomEmoji variable for all instances that have loaded my module, "onCreate" method occurs only once, so any processes loading my module AFTER "onCreate" runs, will always return myNewCustomEmoji as null, which is exactly what is happening.

Where it initializes the myNewCustomEmoji variable, and where it accesses it are two different classes, which would be perfectly fine if I were modding the apk directly.

My point is still - I do not think having every single process load every single module is a smart thing to do, it will be loading things not even relevant to the process. Only processes which have hooks related to that process should be loaded for that process. If you keep creating instances of classes, you will have memory leaks and other issues like the one I am having. I'm not saying we should "go back" to loading zygote, but filter the modules loaded by a specific process to only load modules that hook that process.

[Mikanoshi]

I'm not sure I understand, need a full code. What instances? EdXposed 0.5 no longer injects classes into zygote before fork, so you cannot load something in initZygote and then use it in another processes. Each process calls its own initZygote.
Just make variable static and it should work, setAdditionalInstanceField should already work. If you hook onCreate of some package in handleLoadPackage then variable assigned there will be available in this entire package.

[elesbb]

I'm not sure I understand, need a full code. What instances? EdXposed 0.5 no longer injects classes into zygote before fork, so you cannot load something in initZygote and then use it in another processes. Each process calls its own initZygote.
Just make variable static and it should work, setAdditionalInstanceField should already work. If you hook onCreate of some package in handleLoadPackage then variable assigned there will be available in this entire package.

Exactly, but this isn't the case anymore because every process loads an instance of your module. I cannot make the variable static because it holds a "context" object that can become a memory leak.

Each process is loading an instance of the module. And as you said, you cannot access fields across processes (which Is NOT what I am trying to do.)

I'll give an example with 3 processes that load xposed modules. Process A, Process HOOKED, and Process B. HOOKED is clearly the one I want to hook.

Process A loads my module. Nothing happens, not the process I want, however, there is STILL an instance of my module created (the xposed class, this includes all variables declared at the top of the class).
Process HOOKED now loads my module, a new instance of the xposed class is created, the "onCreate" method runs, my variable is filled. All is good.
Process B now loads my module, yet another instance of my xposed.class is created.

Process HOOKED runs the second method I am hooking, in this method, I access the variable that was filled in the onCreate method. Process HOOKED and A have no problem, but Process B crashes with a null pointer exception because it was not loaded in time.

Basically, as you said, every process now becomes its own zygote, which is causing the modules to constantly be loaded by every single process. What needs to happen is a filter to only allow a process to load a module if it has any hooks for that process.

[Mikanoshi]

Process HOOKED runs the second method I am hooking, in this method, I access the variable that was filled in the onCreate method.
Process HOOKED and A have no problem, but Process B crashes with a null pointer exception because it was not loaded in time.

Why process A and B are even mentioned here? You don't want to hook them, variables there are null, it was like that in EdXposed 0.4 too. Don't use variable in processes A/B and there won't be any crashes.

What needs to happen is a filter to only allow a process to load a module if it has any hooks for that process.

0.4 loaded modules in zygote and then they were forked to other processes, your class was in all of them too.
initZygote has no package differentiation, and a lot of my mods require hooks there to be available in every process, because they hook Android framework classes.

[elesbb]

Process HOOKED runs the second method I am hooking, in this method, I access the variable that was filled in the onCreate method.
Process HOOKED and A have no problem, but Process B crashes with a null pointer exception because it was not loaded in time.

Why process A and B are even mentioned here? You don't want to hook them, variables there are null, it was like that in EdXposed 0.4 too. Don't use variable in processes A/B and there won't be any crashes.

What needs to happen is a filter to only allow a process to load a module if it has any hooks for that process.

0.4 loaded modules in zygote and then they were forked to other processes, your class was in all of them too.
initZygote has no package differentiation, and a lot of my mods require hooks there to be available in every process, because they hook Android framework classes.

Man I really don't know how to explain this. Process A and B are mentioned because they load my module now. Zygote itself would create an instance of the Xposed.class (whatever is set in the xposed_init file inside your apk assets dir), this class is now initialized multiple times, not just once. The difference between 0.4 and 0.5 is WHEN the xposed class is loaded. The fact that making the variable static would fix it is proof multiple instances of my class are loaded, where before, it was only one.

[Mikanoshi]

That's how it works now. Why do you have crashes is still unclear, you assign and use variable in a HOOKED process, it's not involved with A and B.

[elesbb]

That's how it works now. Why do you have crashes is still unclear, you assign and use variable in a HOOKED process, it's not involved with A and B.

The reason for the crashes is because of the multiple instances of my xposed.class being created. With just one created, it is fine.

When my module accesses the variable, it is null, because that module got loaded AFTER the variable was filled, so everything is null again.

It's basically doing this:

MyXposedClass myClass = new MyXposedClass(); <-- First instance by process A
MyXposedClass myClass = new MyXposedClass(); <-- Second instance by process HOOKED
MyXposedClass myClass = new MyXposedClass(); <-- Third instance by process B

Anything that creates a new instance of the XposedClass AFTER HOOKED process does, will never have the variables assigned to them. I also don't think its healthy on the resources for every single process to be creating a new xposed class instance.

Before, only zygote created an instance of the MyXPosedClass();, and then forked that to the processes.
@kotori2, Am I understanding this correctly?

[Mikanoshi]

Anything that creates a new instance of the XposedClass AFTER HOOKED process does, will never have the variables assigned to them.

Those instances are separated into different processes, both A and B will have variable as null because you are not assigning anything there. This cannot cause any crashes unless you deliberately trying to use such variables without assigning something to them first.
Are you saying that in EdXposed 0.4 in regular mode you could assign variable in one process and it became available in another? I thought that forking is copy-on-write, so the moment you change something it will just create a local copy of that change.