Fallback Engine

🛡️ 3-Stage Fallback Architecture

Different Android distributions and manufacturer skins (OneUI, MIUI, OxygenOS, Pixel UI) enforce strict file permissions over the ADB interface. System media directories, private files, or locked directories can cause standard transfers to fail.

To guarantee 100% backup completion without silent skips, Jigar Tools implements a robust 3-Stage Fallback Engine.

---

🛰️ Fallback Protocol Flow

graph TD
    A[File Copy Request] --> B{Stage 1: Direct Pull}
    B -- Success --> C[Success]
    B -- Fail --> D{Stage 2: Local Temp Copy}
    D -- Success --> C
    D -- Fail --> E{Stage 3: Root Global Mount}
    E -- Success --> C
    E -- Fail --> F[Transfer Failed]
    
    style B fill:#1e1e2e,stroke:#3b5998,stroke-width:2px
    style D fill:#1e1e2e,stroke:#f0ad4e,stroke-width:2px
    style E fill:#1e1e2e,stroke:#d9534f,stroke-width:2px
    style C fill:#1e1e2e,stroke:#5cb85c,stroke-width:2px

Loading

---

🔍 Detailed Breakdown of Stages

1️⃣ Stage 1: Direct Pull

The engine attempts to copy the file directly from its Android path (e.g. /sdcard/) to the PC.

• Best for: Standard media files (Photos, Downloads, Documents).
• Performance: Maximum speed, standard ADB daemon privileges.

2️⃣ Stage 2: Device Local Temp Copy (/data/local/tmp)

If direct read access is restricted by Android OS sandboxing:

• The script commands the phone to copy the file locally to /data/local/tmp/jgr_temp_file (an ADB-writable directory).
• The script pulls the file from the temp directory.
• The temp file is immediately cleaned up on the device.

3️⃣ Stage 3: Root Global Mount (su -c)

If Stage 2 is blocked (e.g., in private /data/ folders or root-only paths):

• The script checks if the device is rooted (Magisk, APatch, KernelSU).
• If root is active, it runs an elevated command (su) to copy the file to /data/local/tmp/jgr_temp_file under a global mount namespace (su -mm -c), then pulls and cleans it up.