Dex2oat failled for some System app on Huawei P9

[wanam]

Running Xposed v86 on a Huawei P9 (Stock Marshmallow), dex2oat fails with a "Permission denied" error 7 times, causing those to be interpreted, re-executing manually the failed dex2oat command with Root access is working fine.

Here is an example (full logs attached)
logs-huawei-p9-xposed-86.zip

07-29 10:26:07.456 4638 4638 E dex2oat : Failed to create oat file: /data/dalvik-cache/arm64/system@priv-app@Telecom@[email protected]: Permission denied
07-29 10:26:07.462 1123 1123 W art : Failed execv(/system/bin/dex2oat --runtime-arg -classpath --runtime-arg /system/framework/XposedBridge.jar --instruction-set=arm64 --instruction-set-features=smp,a53 --runtime-arg -Xnorelocate --boot-image=/system/framework/boot.art --runtime-arg -Xms64m --runtime-arg -Xmx512m --instruction-set-variant=generic --instruction-set-features=default --dex-file=/system/priv-app/Telecom/oat/arm64/Telecom.odex --oat-file=/data/dalvik-cache/arm64/system@priv-app@Telecom@[email protected]) because non-0 exit status
07-29 10:26:07.464 1123 1123 W art : Falling back to interpreting /system/priv-app/Telecom/oat/arm64/Telecom.odex
07-29 10:26:07.464 1123 1123 W System : ClassLoader referenced unknown path: /system/priv-app/Telecom/lib/arm64

Rom files.

[rovo89]

I think that's normal. These apps are probably used very early, before their compilation could be triggered by the PackageManagerService. That's not a problem with dex2oat, the app simply isn't allowed to compile itself. Without Xposed, the .odex file is used, so this isn't necessary. With Xposed, it used to fail opening the app, but now the fallback to interpreting mode is in place.

Does this still occur on the second boot?

[wanam]

Does this still occur on the second boot?

You mean without executing the command manually?

[rovo89]

Yes. Most relevant apps should be compiled automatically at a later time. If not, that's the start point for further investigations. I know that AOSP has some optimizations, e.g. this: aosp-mirror/platform_frameworks_base@71d3260

Which means that some apps might not be compiled immediately, but the system should notice that they're used, add them to /data/system/package-usage.list and compile them after the next reboot. Not sure if some compilation also takes place while the device is idle.

Slightly OT, clearing that file can be helpful during low-level development. Even after clearing the Dalvik cache, it will only compile a few apps and postpone the others.

[wanam]

Ok, i removed the recompiled file that were generated by manual dex2oat, and those system apps were recompiled on the second boot.

Removed /data/system/package-usage.list and cleared dalvik cache, and the logs are now cleaner, thanks for the tip.

The only error i'm still getting is:

07-29 11:55:22.589 6229 6301 E linker : warning: unable to get realpath for the library "/data/data/com.google.android.gms/app_chimera/m/00000000/oat/arm64/DynamiteModulesA_GmsCore_prodmnc_xxhdpi_release.odex". Will use given name.
07-29 11:55:22.616 6312 6312 E dex2oat : Failed to create oat file: /data/dalvik-cache/arm64/data@[email protected]@app_chimera@m@00000000@[email protected]: Permission denied
07-29 11:55:22.616 6312 6312 I dex2oat : dex2oat took 316.667us (threads: 8)
07-29 11:55:22.617 6229 6301 W art : Failed execv(/system/bin/dex2oat --runtime-arg -classpath --runtime-arg /system/framework/XposedBridge.jar --instruction-set=arm64 --instruction-set-features=smp,a53 --runtime-arg -Xnorelocate --boot-image=/system/framework/boot.art --runtime-arg -Xms64m --runtime-arg -Xmx512m --instruction-set-variant=generic --instruction-set-features=default --dex-file=/data/data/com.google.android.gms/app_chimera/m/00000000/oat/arm64/DynamiteModulesA_GmsCore_prodmnc_xxhdpi_release.odex --oat-file=/data/dalvik-cache/arm64/data@[email protected]@app_chimera@m@00000000@[email protected]) because non-0 exit status
07-29 11:55:22.618 6229 6301 W art : Falling back to interpreting /data/data/com.google.android.gms/app_chimera/m/00000000/oat/arm64/DynamiteModulesA_GmsCore_prodmnc_xxhdpi_release.odex

It seems similar to the one fixed here: 4ca2451