Android reported non-absolute loaded-image path

Error message

Android {authority} reported non-absolute loaded-image path `{}`

What it means

Each Android path authority (dladdr and /proc/self/maps) must report an absolute path for the loaded image; the updater canonicalizes it later and can only reason about absolute locations. If dladdr or a maps row yields a relative path (which well-formed authorities never should), the updater rejects it rather than resolving against an unknown working directory.

Solutions

Run the updater as a normally loaded executable so dladdr/maps report real absolute paths.
Check that the binary is file-backed on disk (not an anonymous/memfd mapping); copy it to storage and exec from there.
If this appears in tests, fix the fixture: maps/dladdr fixtures must use absolute paths.
Report the environment upstream if a legitimate loader produces relative dladdr paths — the check may need relaxing for that loader.

Defensive patterns

Strategy: validation

Validate before calling

fn ensure_absolute(p: &std::path::Path) -> anyhow::Result<()> {
    anyhow::ensure!(p.is_absolute(), "reported path {:?} is not absolute", p);
    Ok(())
}

Prevention

Run the binary as a normally loaded, file-backed executable.
Do not use memfd or anonymous mappings for the updater binary.
Validate fixtures in tests use absolute paths.
Treat non-authoritative loader environments as unsupported for self-update.

When it happens

Trigger: validate_android_reported_path, called from android_loaded_executable_proof_report, when the dladdr-reported path or the path column of the matching /proc/self/maps row is not absolute.

Common situations: dladdr returning an unexpected value because the marker is not actually in a loaded file-backed image; a hand-edited or synthetic maps text in tests; embedding the binary in a nonstandard loader that reports relative paths.

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Related errors

AI-assisted analysis of Hmbown/CodeWhale@73e0f67d83 (2026-09-22). Data as JSON: /api/errors/7bcafa7dbf386f64. Report an issue: GitHub.

Appendix: source

Thrown at crates/cli/src/update.rs:481

            "Android loaded image `{}` is not an executable regular file; refusing to select an update target",
            resolved_mapping.display()
        );
    }

    validate_android_mapping_identity(&mapping, &resolved_mapping)?;
    Ok(AndroidExecutableProof {
        path: resolved_mapping,
        device_major: mapping.device_major,
        device_minor: mapping.device_minor,
        inode: mapping.inode,
        proof_kind: AndroidExecutableProofKind::DladdrAndProcMaps,
    })
}

#[cfg(any(target_os = "android", all(test, unix)))]
fn validate_android_reported_path(authority: &str, path: &Path) -> Result<()> {
    if !path.is_absolute() {
        bail!(
            "Android {authority} reported non-absolute loaded-image path `{}`",
            path.display()
        );
    }
    if path.to_string_lossy().ends_with(" (deleted)") {
        bail!(
            "Android {authority} reported deleted loaded image `{}`",
            path.display()
        );
    }
    if is_android_linker_name(path) {
        bail!(
            "Android {authority} identifies runtime linker `{}`; refusing to use the linker as an update target",
            path.display()
        );
    }
    Ok(())
}

View on GitHub (pinned to 73e0f67d83)