Skip to content

Fix early LoadedApk class loader initialization - #115

Open
mumingluan wants to merge 1 commit into
JingMatrix:masterfrom
mumingluan:codex/fix-early-loadedapk-loader
Open

Fix early LoadedApk class loader initialization#115
mumingluan wants to merge 1 commit into
JingMatrix:masterfrom
mumingluan:codex/fix-early-loadedapk-loader

Conversation

@mumingluan

Copy link
Copy Markdown

Summary

  • avoid dereferencing ActivityThread.mBoundApplication.info while the app component factory is still being initialized
  • obtain the native loader parent from the already-defined metaloader factory class
  • recover the in-progress stub LoadedApk from ActivityThread.mPackages during early re-entrant initialization

Validation

  • git diff --check
  • previously validated on Android API 35 / 127.0.0.1:5557 with a 3.0 GB APK:
    • no JNI abort or fatal exception
    • target activity remained foreground
    • embedded module initialized successfully

@mumingluan
mumingluan marked this pull request as ready for review August 25, 2026 13:26
Copilot AI lite review requested due to automatic review settings August 25, 2026 13:26

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Needs a closer look

It changes JNI_OnLoad-time and early app bootstrap class-loader behavior across OEM-specific initialization sequences, which warrants final human review and broader device/API validation.

Pull request overview

This PR hardens LSPatch’s early bootstrap/class-loader initialization path to avoid null dereferences and re-entrant initialization pitfalls on certain Android variants during AppComponentFactory loading.

Changes:

  • Switch native loader-parent discovery to use the defining class loader of LSPAppComponentFactoryStub (via java.lang.Class#getClassLoader) instead of reading ActivityThread.mBoundApplication.info early.
  • In Java bootstrap, derive the base class loader from LSPAppComponentFactoryStub’s defining loader and recover an in-progress stub LoadedApk from ActivityThread.mPackages when AppBindData.info is still unpublished.
File summaries
File Description
patch-loader/src/main/jni/src/patch_loader.cpp Uses the metaloader stub class’s defining class loader as the stable parent for the in-memory framework loader, avoiding early ActivityThread dereferences.
patch-loader/src/main/java/org/lsposed/lspatch/loader/LSPApplication.java Avoids stubLoadedApk.getClassLoader() during early/re-entrant init; recovers the stub LoadedApk from mPackages when mBoundApplication.info is not yet available.
Review details
  • Files reviewed: 2/2 changed files
  • Comments generated: 0
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants