Fallback Engine

🛡️ 3-Stage Fallback Architecture

Different Android devices and operating system flavors (OneUI, MIUI, Pixel UI) enforce different permission restrictions over USB ADB interfaces, especially for system directories, app data, or private user files. To ensure that 100% of your files are successfully backed up without silent failures, Jigar Tools executes a 3-Stage Fallback Routine for every file.

---

🛰️ The Fallback Sequence

graph TD
    A[Start File Transfer] --> B{Stage 1: Direct Pull}
    B -- Success --> C[Done]
    B -- Fail --> D{Stage 2: Device Temp Copy}
    D -- Success --> C
    D -- Fail --> E{Stage 3: Root Global Mount}
    E -- Success --> C
    E -- Fail --> F[Report File Transfer Failed]

Loading

1. Stage 1: Direct Pull (Toybox/Toolbox)

The script attempts to copy the file directly from its source path on the device (e.g. /storage/emulated/0/...) to your PC. This uses standard ADB permissions and works for 95% of standard media files.

2. Stage 2: Device Temp Copy (/data/local/tmp)

If the direct pull fails (usually due to file read permission constraints or path quoting limitations), the script instructs the device to copy the file locally to /data/local/tmp/jgr_temp_file (a sandbox directory readable by ADB). The script then pulls the file from the temp directory and deletes the temp copy on the device.

3. Stage 3: Root Global Mount (su -c)

If the file is in a restricted partition (e.g. /data/media/0/ or root paths) and Stage 2 fails, the script checks if the device is rooted (Magisk, APatch, or KernelSU). If root access is active, it runs an elevated shell script to copy the file to the ADB sandbox and pulls it, defeating Android security sandboxing.