Hmbown/CodeWhale · error · anyhow::Error

Android loaded-image authorities resolved to runtime linker

Error message

Android loaded-image authorities resolved to runtime linker {}; refusing to use the linker as an update target

What it means

Both Android authorities (dladdr and /proc/self/maps) resolved the updater's loaded image to Bionic's runtime linker (matched by is_android_linker_name, e.g. /system/bin/linker64 or /apex/.../linker64). The whole marker+maps cross-check exists precisely because Android's current_exe can misreport the linker; if the marker itself is attributed to the linker, updating would overwrite a system component, so it is refused by design.

Source

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

            "failed to canonicalize Android dladdr path {}",
            dladdr_path.display()
        )
    })?;
    let resolved_mapping = mapping.path.canonicalize().with_context(|| {
        format!(
            "failed to canonicalize Android loaded-image mapping {}",
            mapping.path.display()
        )
    })?;
    if resolved_dladdr != resolved_mapping {
        bail!(
            "Android loaded-image authorities disagree: dladdr resolved to {}, but /proc/self/maps resolved to {}",
            resolved_dladdr.display(),
            resolved_mapping.display()
        );
    }
    if is_android_linker_name(&resolved_mapping) {
        bail!(
            "Android loaded-image authorities resolved to runtime linker {}; refusing to use the linker as an update target",
            resolved_mapping.display()
        );
    }
    if !is_executable_file(&resolved_mapping) {
        bail!(
            "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,

View on GitHub (pinned to 0c42157ee5)

Solutions

Launch the CLI by exec'ing the binary itself, not through the dynamic linker or dlopen wrappers
Reinstall using the documented Android install method
Report it as a bug with the resolved linker path from the message and how the binary was launched

Defensive patterns

Strategy: try-catch

Try / catch

Catch and hard-stop: any workflow that reaches the linker refusal must never retry or write to the linker path; report a packaging/launch bug instead.

Prevention

Always exec the binary directly, never load it via the linker or dlopen
Use documented install methods
Watch launch wrappers that change which image owns the marker symbol

When it happens

Trigger: Android self-update where the marker symbol's address is attributed to the linker image - typically a packaging or launch-path bug where the CLI is loaded by/in the linker's namespace rather than exec'd normally.

Common situations: Custom launchers that dlopen the binary, mispackaged builds, or tooling that execs the linker directly with the program as an argument.

Related errors

AI-assisted analysis of Hmbown/CodeWhale@0c42157ee5 (2026-08-20). Data as JSON: /api/errors/ca695078ffb6d0f0. Report an issue: GitHub.