Root My Galaxy 0.3.45

SHA-256: 43851fc7b80019ba0dd6629573d3f1837358bdbe5de3305cd89db50e45c4a411

Changes since v0.3.44.

What's changed

• #35 Fix CZG3 Shizuku provenance and isolate standalone probes

Full changelog

Detailed pull-request notes for all changes included in this release.

#35 — Fix CZG3 Shizuku provenance and isolate standalone probes

Summary

This PR applies the diagnostic/isolation fixes identified from the v0.3.44 CZG3 runs without retuning or weakening the exploit diagnostics.

• preserves the real Manual Online / Manual Offline provenance when CZG3 Shizuku reuses a verified local snapshot;
• binds provenance to the exact resolved TargetProfile, avoiding cross-talk with concurrent/background target discovery;
• records payload provenance separately with RMG_PAYLOAD_V1, distinguishing invocation source from artifact source (remote_download vs verified_local_snapshot);
• keeps the quiet Shizuku reuse optimization in place;
• makes ordinary ShizukuController.isRunning() / isGranted() reads passive so standalone preparation does not call pingBinder() / checkSelfPermission() in the exploit path;
• keeps active Binder/permission probes only in explicit Shizuku health/permission paths;
• initializes passive Shizuku lifecycle tracking from the main app process via sticky binder received/dead/permission listeners;
• keeps binder receive/death callbacks transaction-free and records their uptime timestamps;
• adds passive Shizuku state, Binder arrival/death, and permission-observation timestamps to every RMG_ANDROID_V1 run-context record.

Deliberately unchanged

No changes to:

• CZG3 payload;
• P0 timing/offsets;
• FOPS route or fops_effective_consume_us=70000;
• retry sequence;
• reclaim/supervisor/keeper logic;
• External Observer cadence or diagnostic coverage;
• fail-closed / DoNotRetry behavior.

This removes an avoidable Android-side Shizuku IPC confound while increasing observability. It intentionally does not tune the exploit from the current small sample.

Validation note

The repository currently has no pull-request CI workflow; its only GitHub Actions workflow is the main-only release workflow. The branch was therefore reviewed statically and kept mergeable, but this PR does not claim a completed Gradle build/test run.