This error has a strangely specific name, but it rarely means your current phone needs a MIPS64 compiler. It usually appears when an older Android build system scans for legacy toolchains that a newer NDK deliberately removed. The lasting repair is to align the Android Gradle Plugin, Gradle, JDK, native scripts, and NDK—not to keep copying missing directories into the SDK.

What the error is telling you

The prefix mips64el-linux-android identifies the old little-endian MIPS64 target toolchain. NDK r17 removed MIPS and MIPS64 support, and NDK r18 removed GCC. Old Android Gradle Plugin releases and GCC-era scripts may still look for directories such as toolchains/mips64el-linux-android-4.9, so a modern NDK cannot satisfy their assumptions.

Choose the repair path from the evidence

  • If the stack trace originates in an old Android Gradle Plugin, upgrade the project’s build stack as a coordinated set.

  • If Gradle/CMake/ndk-build explicitly requests mips or mips64, remove that ABI unless you are maintaining an actual legacy MIPS product.

  • If native scripts select GCC, gnustl, stlport, or standalone toolchains, migrate them to supported Clang and libc++ behavior.

  • If the project already builds elsewhere, pin the exact working NDK revision instead of relying on whichever SDK-wide NDK happens to be installed.

  • If a frozen product truly requires MIPS, isolate an old supported-at-the-time environment; do not treat it as a modern release toolchain.

Protect a known state first

  • Commit or otherwise snapshot source and build declarations before migration.

  • Record the last known working artifact checksum and environment when one exists.

  • Make one compatibility change at a time so a new failure has a small causal surface.

  • Keep local SDK paths and credentials out of the commit.

1. Capture the versions before editing

Android project rootbash
./gradlew --version
printf "SDK root: %s\n" "${ANDROID_SDK_ROOT:-${ANDROID_HOME:-not-set}}"
rg -n "com.android.tools.build:gradle|com.android.application|ndkVersion|abiFilters|mips|gcc|gnustl|stlport" . \
  -g "*.gradle" -g "*.gradle.kts" -g "gradle-wrapper.properties" \
  -g "CMakeLists.txt" -g "Android.mk" -g "Application.mk"
Review the Gradle, JVM, AGP declaration, NDK pin, ABI filters, and native-toolchain references together.

This snapshot prevents version roulette

  • Use the committed Gradle Wrapper (./gradlew), not an unrelated system Gradle installation.

  • ANDROID_SDK_ROOT identifies the SDK used by command-line tools; Android Studio can still have a separately configured SDK path.

  • The search is read-only and targets files that commonly encode build compatibility.

  • In newer projects the AGP version may live in settings.gradle(.kts), libs.versions.toml, or a convention plugin, so inspect the full version catalog too.

  • Keep the first complete stack trace; the failing plugin class is often more useful than the final missing-directory message.

2. Confirm installed side-by-side NDKs

Android project rootbash
SDK_ROOT="${ANDROID_SDK_ROOT:-${ANDROID_HOME:-}}"
if [ -n "$SDK_ROOT" ]; then
  find "$SDK_ROOT/ndk" -mindepth 1 -maxdepth 1 -type d -printf "%f\n" 2>/dev/null | sort -V
fi

find local.properties -maxdepth 0 -type f -exec sed -n '/^[[:space:]]*ndk.dir[[:space:]]*=/p' {} ;
Modern SDK layouts show revisions below SDK_ROOT/ndk/. Older projects may contain an ndk.dir override.

Know which NDK the project really selects

  • Current Android tooling installs NDK releases side by side under the SDK ndk/ directory.

  • A module-level android.ndkVersion pin is reproducible and should match the revision installed locally and in CI.

  • Legacy ndk.dir overrides can silently point Android Studio at a different installation; remove them only after migrating the project.

  • Do not infer compatibility from directory existence. AGP, Gradle, JDK, CMake, NDK, and source assumptions must agree.

3. Check whether the app actually requests MIPS

app/build.gradle.kts (modern ABI filter)kotlin
android {
    defaultConfig {
        ndk {
            abiFilters += listOf("arm64-v8a", "armeabi-v7a", "x86_64")
        }
    }
}

Filter only ABIs you intentionally ship

  • Remove mips and mips64; modern Android NDKs cannot build those retired ABIs.

  • arm64-v8a targets 64-bit Arm, armeabi-v7a targets 32-bit Arm, and x86_64 is commonly useful for emulators and some devices.

  • Do not copy this list blindly: Play requirements, minimum SDK, device fleet, native dependencies, APK size, and testing capacity determine the correct set.

  • Every prebuilt .so dependency must exist for each packaged ABI, or packaging/runtime failures can replace the original build error.

  • If no native library needs filtering, omit abiFilters and let the build’s actual native outputs drive packaging.

Search native build files too

Application.mk (legacy lines to remove or migrate)makefile
# Obsolete examples—do not retain these in a modern build
APP_ABI := mips mips64
NDK_TOOLCHAIN_VERSION := 4.9
APP_STL := gnustl_static
 
# A modern ndk-build project normally uses supported ABIs selected by Gradle
# and libc++ where an explicit STL choice is still required.
APP_STL := c++_static

The removed features often arrive as a bundle

  • NDK_TOOLCHAIN_VERSION := 4.9 requests the retired GCC toolchain; modern NDK builds use Clang.

  • gnustl_static, gnustl_shared, and STLport were removed; migrate code and dependencies to libc++.

  • c++_static places a C++ runtime copy in a library; if an application loads multiple native libraries, coordinate STL/runtime linkage carefully to avoid duplicate runtime state.

  • Audit third-party prebuilt libraries before upgrading. A binary built only for MIPS or against an incompatible C++ ABI cannot be repaired by a Gradle setting.

4. Upgrade the build stack as a matrix

Do not paste the historical AGP 3.5.0 and Gradle 5.4.1 pair from the old workaround into a current project. Use Android Studio’s AGP Upgrade Assistant and the official AGP compatibility tables to choose an AGP, Gradle, JDK, SDK Build Tools, and NDK combination appropriate for the project. Upgrade in reviewable steps, commit each working boundary, and run native tests on every supported ABI.

A safer migration order

  1. Identify the project’s current AGP and the newest supported stepping-stone documented for that generation.

  2. Align the Gradle Wrapper and Gradle JDK with that AGP release.

  3. Resolve deprecated Android DSL and manifest behavior reported by the build.

  4. Migrate native GCC/STL/ABI assumptions and select a compatible NDK.

  5. Build and test debug and release variants before advancing to another major plugin boundary.

Where the two key versions are declared

gradle/libs.versions.toml (example placeholders)toml
[versions]
agp = "<version-compatible-with-your-Gradle-and-JDK>"
kotlin = "<compatible-kotlin-version>"
 
[plugins]
android-application = { id = "com.android.application", version.ref = "agp" }

Treat placeholders as decisions, not commands

  • Replace angle-bracket placeholders only after checking the official compatibility table and project constraints.

  • The Gradle Wrapper version lives in gradle/wrapper/gradle-wrapper.properties; AGP and Gradle versions are related but not interchangeable.

  • The JDK running Gradle must satisfy the selected AGP requirement; Android Studio’s embedded JDK and shell JAVA_HOME may differ.

  • Version catalogs are one modern declaration style. Existing buildscript/plugin DSL layouts can be upgraded without first restructuring the whole project.

5. Pin a tested NDK revision

app/build.gradle.ktskotlin
android {
    ndkVersion = "<installed-and-tested-ndk-revision>"
}

A project pin makes failures reproducible

  • Use a complete revision shown by SDK Manager, such as its major, minor, build, and optional beta/RC suffix—not a guessed value.

  • Install that same revision on developer machines and CI with SDK Manager.

  • Keep the pin in version control so a workstation upgrade does not silently change native compilers.

  • Revalidate warnings, sanitizers, binary size, symbol handling, tests, and device behavior before advancing the NDK revision.

6. Rebuild from a controlled state

Android project rootbash
./gradlew --stop
./gradlew clean
./gradlew :app:assembleDebug --stacktrace
BUILD SUCCESSFUL

Risk level: caution. Review the command before running it.

Cleaning confirms the fix; it does not create one

  • --stop ends project Gradle daemons; the next invocation starts a compatible daemon.

  • clean removes generated module build outputs, so the next build takes longer but source files remain intact.

  • --stacktrace preserves the plugin or native task that still fails.

  • If the same missing MIPS toolchain remains, return to version declarations and native scripts rather than repeatedly deleting caches.

  • A successful debug build is only one signal; test every release ABI and build type that ships.

Verify the native outputs

Android project rootbash
find app/build -type f -name "*.so" -print | sort
find app/build/outputs -type f ( -name "*.apk" -o -name "*.aab" ) -print | sort
Expected paths vary by AGP and module configuration; inspect the generated variant rather than relying on one hard-coded directory.

Look beyond BUILD SUCCESSFUL

  • Confirm each intended ABI has the project’s native libraries and no retired MIPS directory.

  • Run the APK on representative Arm devices and x86_64 emulators when those ABIs are shipped.

  • Exercise JNI entry points; packaging a .so does not prove symbols, C++ runtime linkage, or behavior is correct.

  • Produce and test a release variant under the real shrinking, signing, and packaging configuration before publication.

  • Archive native debug symbols and mapping information required to diagnose production crashes.

Make CI prove the environment is repeatable

  • Print the selected Java, Gradle, AGP, CMake, and NDK versions in diagnostic build output.

  • Provision SDK packages from reviewed version declarations rather than mutable workstation state.

  • Build every supported ABI from a clean worker and retain the task log.

  • Run native smoke tests on representative devices or emulators and retain release symbols with the artifact.

Legacy fallback for an irreplaceable MIPS build

An archival product that genuinely targets MIPS may require NDK r16b or another historically validated toolchain from before r17 removed MIPS. Freeze the entire environment—OS image, JDK, Android Studio/command-line tools, Gradle Wrapper, AGP, SDK packages, NDK, CMake, dependencies, checksums, and artifact provenance—inside an isolated, access-controlled build system.

  • Do not use an unsupported legacy environment for a new Android release or general web access.

  • Obtain old packages only from official archives and verify published checksums where available.

  • Document known CVEs, expired signing assumptions, unsupported SDK targets, and reproducibility limitations.

  • Keep modern and archival SDK/NDK installations side by side; never overwrite a working current toolchain globally.

  • Plan source migration or product retirement because pinning old compilers transfers risk—it does not remove it.

Symptom-to-cause map

  • Error names `mips64el-linux-android`: old AGP/tooling scanned a toolchain removed in NDK r17, or the project explicitly requests MIPS64.

  • Error names `gcc` or version `4.9`: a script or dependency still assumes GCC, removed in NDK r18.

  • Build works in Android Studio but not the shell: compare SDK path, JDK, environment variables, and the committed Wrapper.

  • Build works on one workstation only: pin the NDK and other build versions; compare installed SDK packages and local overrides.

  • Linker says a library is incompatible: inspect the prebuilt library’s ABI and C++ runtime; Gradle cannot translate an existing binary.

  • App installs but native code fails to load: confirm packaged ABI, device ABI, dependency .so files, min SDK, and Logcat linker diagnostics.

  • Upgrading AGP creates new DSL errors: follow the Upgrade Assistant/migration notes sequentially rather than combining years of breaking changes in one blind edit.

What not to do

  • Do not rename an ARM toolchain folder to mips64el-linux-android.

  • Do not copy random NDK directories from a forum attachment.

  • Do not update only distributionUrl and assume AGP/JDK compatibility follows automatically.

  • Do not hard-code the newest available version into an untested legacy project.

  • Do not remove ABI filters until you understand which native libraries will be packaged.

  • Do not publish an artifact merely because the missing-folder message disappeared.

A durable completion checklist

  • The original stack trace and working/failing environment versions are recorded.

  • No active build file requests MIPS, MIPS64, GCC, gnustl, STLport, or an obsolete standalone toolchain unless explicitly archival.

  • AGP, Wrapper, JDK, SDK, CMake, NDK, and Kotlin versions are mutually supported.

  • The project pins an installed, tested NDK revision.

  • CI and local builds use the same committed configuration.

  • Every shipped ABI builds, packages, installs, loads native code, and passes relevant tests.

  • Release artifacts and native symbols are produced reproducibly.

  • Any legacy MIPS environment is isolated, documented, checksum-verified, and scheduled for migration or retirement.

Official Android references