An ARM64 app running in Android Studio’s Android Emulator can crash inside libndk_translation.so, with Arm64AesEncode appearing in the stack. This signature does not necessarily point to a defect in the app’s AES implementation. It is a known Android Emulator instruction-translation bug tracked by Google as Issue #388718417. The fix first appeared in Android Emulator 35.6.7 Canary and is included in stable version 35.6.11, released on June 24, 2025.
Representative error
Fatal signal 6 (SIGABRT)
...
libndk_translation.so
...
Arm64AesEncode
Aborted
The surrounding frames, signal number, and addresses can vary by app and host configuration. The important identifiers are libndk_translation.so and Arm64AesEncode in a crash produced inside the emulator.
Cause
According to the Google Issue Tracker report, an inconsistency existed in the NDK translation layer used to execute ARM64 code on a different host architecture. The translation layer exposed the AES capability flag, but its actual instruction handling did not match that advertised capability. Native code using AES instructions could consequently reach Arm64AesEncode and abort inside libndk_translation.so.
When the stack contains this exact signature, changing Kotlin or Java code, clearing Gradle caches, or modifying signing settings is unlikely to address the root cause. Check the installed Android Emulator version first.
Affected conditions and versions
- An Android Emulator build older than the fixed releases is installed.
- Native code for a different CPU architecture is being executed through NDK translation.
- The ARM64 native library or code path uses AES instructions.
- The crash stack includes both
libndk_translation.soandArm64AesEncode.
Google lists Android Emulator 35.6.7 Canary as the initial fixed build. The same issue is listed as fixed in stable Android Emulator 35.6.11, dated June 24, 2025.
Recommended fix
- In Android Studio, open “Tools” → “SDK Manager.”
- Select the “SDK Tools” tab and check the installed “Android Emulator” version.
- Update Android Emulator to at least 35.6.11. If a newer stable release is available, use the current stable version unless your project has a specific compatibility constraint.
- Close Android Studio and any running emulator instances, then restart the AVD.
- Repeat the failing workflow and confirm that the signature no longer appears in Logcat or the crash dump.
# When using the SDK command-line tools
sdkmanager --update
# Check the installed emulator version
emulator -version
Alternatives when an update is not immediately possible
- Run the same build on a physical ARM64 device to distinguish an app defect from a translation-layer defect.
- If the app can ship an x86_64 ABI, use a native library matching the AVD architecture and avoid NDK translation.
- Temporarily move affected CI or team tests to an environment that already uses a fixed Emulator version.
Cold Boot and Wipe Data can help rule out snapshot corruption, but Google does not identify either action as the root fix for this issue. Disabling AES code may also change security or compatibility behavior, so it should not be treated as a general permanent fix.
How to verify the fix
- Confirm version 35.6.11 or later with
emulator -versionor SDK Manager. - Retest with the same AVD, API level, app build, and reproduction steps.
- Search Logcat for
libndk_translation.so,Arm64AesEncode, andSIGABRT. - If the same code also crashes on a physical ARM64 device, investigate the app’s native code and dependencies separately.
Important notes
Android Studio and Android Emulator are independently updated SDK components. Updating the IDE alone can leave an older Emulator package installed, so verify the “Android Emulator” entry in SDK Manager. A generic SIGABRT without the two identifiers discussed here may have a different cause.
Summary
A crash in which libndk_translation.so aborts at Arm64AesEncode is a known Android Emulator bug involving AES capability handling in the ARM64 translation layer. The primary fix is to update Android Emulator to 35.6.11 or later. If the crash remains, compare the result with a matching-ABI AVD or a physical ARM64 device to separate translation behavior from an application-level native crash.
