Conversation
7f68302 to
2301137
Compare
2301137 to
b06aa86
Compare
There was a problem hiding this comment.
Pull request overview
Updates the API Javadoc on XposedModuleInterface to better clarify lifecycle callback semantics and the stability of parameter objects during module/package loading.
Changes:
- Clarify that
*Paramobjects represent a snapshot at load time and are not updated afterward. - Refine callback Javadocs for package loading/ready phases (including
AppComponentFactoryreferences). - Document that exceptions thrown by callbacks are caught and logged.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
3d7b01f to
532fa3b
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| * Gets notified when a {@link android.R.attr#hasCode} package is loaded into the process. | ||
| * This is the time when the default classloader is ready but before the instantiation of | ||
| * {@link AppComponentFactory}. | ||
| * <p> | ||
| * This callback is invoked only once for each package name loaded into the process, |
There was a problem hiding this comment.
This Javadoc states the callback is invoked when a hasCode package is loaded, but package-info.java now mentions receiving an android package loading event even though android has no code. Please clarify whether packages without code can trigger onPackageLoaded/onPackageReady (and adjust the hasCode wording or the android example accordingly) so the API docs are consistent.
| -adaptresourcefilecontents META-INF/xposed/java_init.list | ||
| -keep,allowoptimization,allowobfuscation public class * extends io.github.libxposed.api.XposedModule { | ||
| public <init>(); | ||
| } |
There was a problem hiding this comment.
This change updates consumer ProGuard/R8 rules (resource adaptation and keep rules for XposedModule subclasses), which can affect shrinking/obfuscation behavior for downstream consumers. The PR title/description indicates a Javadoc-only update; please update the PR metadata to reflect the build/tooling behavior change as well.
| import android.app.AppComponentFactory; | ||
| import android.content.Context; | ||
| import android.content.pm.ApplicationInfo; |
There was a problem hiding this comment.
android.content.Context is only referenced in Javadoc {@link ...} tags, so this import is unused from the compiler’s perspective and may trigger unused-import checks in stricter builds. Consider using the fully-qualified android.content.Context in the Javadoc and removing the import, or otherwise referencing Context from code.
| * Modules scoped to {@code android} can still receive events for {@code android} package loading | ||
| * even though {@code android} package has no code. By contrast, {@code com.android.providers.settings} | ||
| * is not a valid scope target, modules should use the {@code system} scope and then wait | ||
| * for the {@code com.android.providers.settings} package loading event.</p> |
There was a problem hiding this comment.
This new section says modules can receive an "android package loading" event even though the android package has no code, but XposedModuleInterface#onPackageLoaded is documented as firing only for hasCode packages. Please clarify which lifecycle callback(s) (if any) are expected to run for packages without code, and align the wording here accordingly to avoid conflicting guidance.
| * Modules scoped to {@code android} can still receive events for {@code android} package loading | |
| * even though {@code android} package has no code. By contrast, {@code com.android.providers.settings} | |
| * is not a valid scope target, modules should use the {@code system} scope and then wait | |
| * for the {@code com.android.providers.settings} package loading event.</p> | |
| * Modules scoped to {@code android} can still receive callbacks that run in those processes, | |
| * even though the base {@code android} package itself has no code and therefore never triggers | |
| * {@link io.github.libxposed.api.XposedModuleInterface#onPackageLoaded onPackageLoaded()}. | |
| * By contrast, {@code com.android.providers.settings} is not a valid scope target; modules | |
| * should use the {@code system} scope and then wait for the | |
| * {@code com.android.providers.settings} package loading event.</p> |
No description provided.