dex2oatd aborts inside ART (class_linker.cc:6620) with:
“vtable entries 1047 and 1052 are identical for java.lang.Class<androidx.appcompat.widget.MenuPopupWindow$MenuDropDownListView> … lookForSelectablePosition(int, boolean)”
The “lock level violation” messages and the SIGABRT are consequences of the abort, not the root cause.
Most likely cause
This failure pattern is commonly triggered when integrating a prebuilt APK produced with a newer Android SDK/toolchain into an older Android platform build: dex2oat (the platform’s ART) hits a vtable sanity check during preopt and aborts. A write-up describing the same signature and recommending the same classes of workarounds exists for Android 7.1 builds. (huaweicloud.csdn.net)
Practical fixes (in priority order)
Rebuild the offending APK(s) with a toolchain aligned to the platform version
If you control the source of Apps and BlissIconPack, rebuild them targeting the same (or older) API level expected by the ROM branch. The commonly reported workaround is lowering compileSdkVersion/targetSdkVersion to an older level so the produced DEX is accepted by the older dex2oat preopt path. (huaweicloud.csdn.net)
After rebuilding, rerun the build and confirm dexpreopt succeeds for those modules.
Disable dexpreopt (odex generation) only for the failing prebuilts
This is the fastest “get the build unblocked” approach, and is explicitly suggested for this class of error. (huaweicloud.csdn.net)
If they are defined in Android.mk (prebuilt apps), add:
LOCAL_DEX_PREOPT := false
For Soong (Android.bp), use:
dex_preopt { enabled: false, }
Notes:
This typically allows the system image build to finish.
The app may be compiled later at first boot / runtime, or run interpreted, depending on your ROM’s dexopt settings. Performance may be lower.
Disable dexpreopt globally (temporary, broad impact)
If you just need a quick confirmation that dexpreopt is the only blocker, disable it for the whole build (e.g., product-level flags such as WITH_DEXPREOPT/PRODUCT_DEX_PREOPT_DEFAULT depending on your tree). This reduces risk of further preopt crashes but impacts boot/runtime performance across the image.
Replace / downgrade the prebuilt APKs
If you do not have the sources, replace Apps.apk and BlissIconPack.apk with versions built for Nougat (or known-good on Android 7.x). The error is tied to code inside androidx.appcompat.* for MenuPopupWindow$MenuDropDownListView, so APK variants built with older support libraries / older appcompat packaging may avoid the crash.
Patch/backport ART changes (longer-term, ROM-maintainer path)
There are upstream ART changes around vtable assignment/linking; if you maintain the platform runtime, consider backporting relevant fixes from newer ART branches and retesting the failing APKs. (android.googlesource.com)
This is higher effort but can reduce incompatibilities when prebuilts are built with newer toolchains.
Side note about the DWARF/addr2line messages
“addr2line: DWARF error: section .debug_info is larger than its filesize!” appears while printing the abort stack trace and is not the root cause of the dex2oat abort.
If you need better native backtraces, use llvm-addr2line/llvm-symbolizer matching your clang/LLVM toolchain, but it will not fix the underlying vtable check failure.
If you want to confirm exactly which library version triggers it, the next step is to unzip the failing APK(s), identify the included androidx.appcompat classes/version, and compare against a known-good build for Android 7.x; but the two fixes above (rebuild with older target, or disable preopt per-module) are usually sufficient.
