Legacy XSharedPreferences redirect stopped after an in-place module reinstall; what state should be refreshed?

[TERRYYYC]

I am asking here before filing a bug because this was a single observation on an older build, and I cannot currently satisfy the bug template's requirement to reproduce on the latest debug build with a manager log archive.

Environment

• Physical device, Android 15
• Magisk 30.7 with Zygisk enabled
• Vector v2.0 (3021) when the behavior was observed
• A legacy Xposed module app targeting API 35, using MODE_WORLD_READABLE plus the xposedsharedprefs manifest metadata to publish configuration for a hooked app

Sequence and observation

1. The module was enabled and its legacy SharedPreferences mirror was updating normally.
2. I reinstalled the same module package in place with the same signing key and preserved its app data.
3. I stopped and relaunched the module app so the next write came from a new process.
4. The module committed a MODE_WORLD_READABLE SharedPreferences update.
5. I compared the app-private preferences file with Vector's mirror used by XSharedPreferences readers.

The commit returned success and did not throw SecurityException, but the changed XML landed in the app-private shared_prefs directory. Vector's mirror did not update, and a reader in another UID continued to see stale/missing data.

The absence of an exception is consistent with the ContextImpl.checkMode suppression being active, but this observation alone does not prove that hook was responsible. What I could establish directly was the successful commit, the actual destination path, and the stale mirror.

Recovery, with an important limitation

I then changed three things together: upgraded to canary 3110, restarted the Vector daemon, and re-enabled the module in the manager. After that sequence, the same kind of write reached the mirror again and the other-UID reader received the new value.

This does not establish that the Vector upgrade fixed the problem. I did not isolate upgrade vs daemon restart vs module re-enable, and I did not test reboot-only recovery.

Why I am asking

Current master documents hookNewXSP as installing the checkMode and getPreferencesDir hooks together:

• legacy architecture documentation
• LegacyDelegateImpl.hookNewXSP

Is there framework or process state that must be refreshed after PACKAGE_REPLACED for a legacy module's own process? Could Android's per-process SharedPreferences path cache explain this apparent split even if both hooks were installed? What specific Vector log lines or state markers would best distinguish these cases in a future clean reproduction?

I can schedule a controlled latest-debug reproduction later on a separate test device and vary one recovery step at a time. For now I mainly want to avoid turning a one-device correlation into an incorrect version-regression claim.

[JingMatrix]

Stop dicussing about old version, I don't understand your motivation and what feature you want to have.

Prepare a clean state, and only report what you have / want against the latest CI build.

[TERRYYYC]

Thanks for the direction. I started over with a fresh isolated environment and reran against the latest successful Core CI build.

The earlier writer-side redirect symptom did not reproduce in this clean run: after each in-place replacement, the newly started writer still published successfully to Vector’s safe-zone. What I reproduced twice was a distinct reader-side failure in an already-running scoped process.

What I have / what I want

I am not asking Vector to hot-reload replacement legacy-module code.

I want to clarify whether an already-running scoped reader should continue resolving the existing XSharedPreferences safe-zone after a same-package, same-signer module replacement, or whether Vector considers a reader-process restart mandatory.

An explicit restart requirement would be understandable. The unexpected part is that the reader silently falls back to the module’s app-private preferences path and continues indefinitely with stale last-known-good data.

Environment

• Fresh isolated Android 15 / API 35 Google APIs arm64-v8a emulator
• Wiped data and no saved snapshot
• Magisk 30.7
• Vector Debug 3110 from commit c4a701aadbf9b4c7a7a65046fe4b9be322a909da
• Official Debug ZIP SHA-256: afc66043dc1316d11fbb8da77c9cb0d3a21ae9c3984af338b1f4ed5f3a60c028
• One isolated legacy test module; no other Xposed modules enabled
• Scope limited to module-owned processes and one isolated reader package; no system scope

Controlled reproduction

1. Install module A, versionCode 8, and start the different-UID reader as PID 10392.
2. Publish a 30-second baseline, then 5 seconds. The same reader accepts the live 30→5 update without restarting.
3. Replace A with module B, versionCode 9, using an in-place install that preserves app data. A and B have the same package, signer, and source; only the intended versionCode/build marker differs.
4. Do not restart the reader, Vector daemon, or device, and do not toggle scope. The reader remains PID 10392.
5. Vector receives the package event and completes its daemon cache update:

VectorConfigCache: Executing Cache Update...
VectorConfigCache: Cache Update Complete. Map Swap successful.

6. Launch the B writer and publish 10 seconds:

published=true readable=true transportAccepted=true
commit=true outcomeDurable=true

A direct filesystem check during the run showed the new value in Vector’s safe-zone XML, while the module’s app-private preferences XML remained absent.

7. PID 10392 nevertheless repeatedly tries A’s removed APK path:

XSharedPreferences: Apk parser fails:
java.nio.file.NoSuchFileException: <old-A-sourceDir>/base.apk

It then resolves the app-private path and retains its 5-second last-known-good value:

no prefs json
(canRead=false path=<module-private-shared-prefs>)
-> keep last-known-good

8. Restart only the reader process. The new reader loads B’s current APK path and immediately accepts the 10-second safe-zone value. The Vector daemon, writer, scope, and device remain untouched.

I repeated the same test with B versionCode 9 → C versionCode 10. The stable reader again retained B’s removed APK path, and reader-only restart again recovered immediately.

Source-supported hypothesis, not asserted root cause

The directly observed boundary is that the running reader retains the removed module APK path after the daemon cache update, then selects the app-private preferences path.

Current source is consistent with a stale process-local legacy-module path:

• XposedInit.loadedModules stores the legacy module APK path in static process state.
• XSharedPreferences reparses that APK and selects the app-private path when the metadata check does not establish a modern module.
• Daemon-side hot-reload target registration appears limited to modern modules.

I did not instrument the loadedModules entry itself, so this remains a source-supported hypothesis rather than a proven root cause.

Is reader-only restart the intended legacy-module update contract, or should the stored APK path be refreshed—or the affected reader explicitly restarted/invalidated—after package replacement?