Conversation
…tire Stage the new generation - class loader, entry classes, entry constructors - before onHotReloading, and run its constructors and native entrypoint recording only once the reload is accepted, so a refused reload constructs no entries and leaves the dlopen list untouched. Entry classes that fail now log why: a class that cannot be loaded or does not extend XposedModule, one with no no-argument constructor (the declared signatures are listed), and a constructor that calls the framework before attachFramework, which is now named instead of collapsing into "could not be instantiated".
|
Show me raw log of related problem, instead of pure AI constructions. |
https://github.com/JingMatrix/Vector/blob/master/xposed/src/main/kotlin/org/matrix/vector/impl/core/VectorModuleManager.kt#L181 I’ve lost the logs, but I recall the issue lies here: when my module explicitly declares a no-argument constructor (which, while not strictly compliant with the API spec, isn't explicitly forbidden by the documentation) and includes code within it, the module fails to load and throws this error. Testing with LSPosed shows that this issue does not occur, as, logically speaking, the code inside the constructor should not be executed during the loading process. |
|
Strictly speaking, it doesn't look like a fix; it appears to be used solely for log enhancement. However, my AI tells me that |
2 participants
Stage the new generation - class loader, entry classes, entry constructors - before onHotReloading, and run its constructors and native entrypoint recording only once the reload is accepted, so a refused reload constructs no entries and leaves the dlopen list untouched.
Entry classes that fail now log why: a class that cannot be loaded or does not extend XposedModule, one with no no-argument constructor (the declared signatures are listed), and a constructor that calls the framework before attachFramework, which is now named instead of collapsing into "could not be instantiated".