Android identifies runtime linker ` `; refusing to use the…

Error message

Android {authority} identifies runtime linker `{}`; refusing to use the linker as an update target

What it means

Independently of the post-canonicalization linker check, validate_android_reported_path rejects paths that are already identifiable as the Android runtime linker (e.g. /system/bin/linker64, /apex/com.android.runtime/bin/linker) as reported by either authority. This is a belt-and-braces guard so the linker is never chosen as an update target even before resolution.

Solutions

Execute the updater binary directly rather than through /system/bin/linker64 or another loader.
Rebuild/reinstall the binary so the marker function lives in the updater's own text segment.
Confirm you are running the real updater executable, not a wrapper that delegates to the linker.
Report upstream with the reported path if a normal launch still resolves into the linker.

Example fix

// before
/system/bin/linker64 ./codewhale update
// after
./codewhale update

Defensive patterns

Strategy: validation

Validate before calling

fn is_android_linker_name(p: &std::path::Path) -> bool {
    p.file_name().and_then(|n| n.to_str())
        .map(|n| n == "linker" || n.starts_with("linker"))
        .unwrap_or(false)
}
if is_android_linker_name(&reported_path) { /* refuse to treat as update target */ }

Prevention

Execute the updater directly, never via /system/bin/linker64.
Verify the marker function lives in the updater's own text.
Guard any destructive swap with a linker-name check first.
Test on stock Android before shipping custom ROM support.

When it happens

Trigger: validate_android_reported_path, called from android_loaded_executable_proof_report, when the dladdr-reported path or the maps row path matches is_android_linker_name().

Common situations: Marker address resolving into the linker's mapping (explicit loader invocation, unusual build layout); running a shell script or stub whose dladdr falls into the linker; pathological /proc/self/maps contents under custom ROMs.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

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

Appendix: source

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

    })
}

#[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(())
}

#[cfg(any(target_os = "android", all(test, unix)))]
fn validate_android_mapping_identity(
    mapping: &AndroidImageMapping,
    candidate: &Path,
) -> Result<()> {
    use std::os::unix::fs::MetadataExt;

    let candidate_metadata = std::fs::metadata(candidate).with_context(|| {
        format!(
            "failed to stat Android update target {}",
            candidate.display()

View on GitHub (pinned to 73e0f67d83)