Xposed modules are compiled to Dalvik cache *and* /data/app/$package/oat/$platform

[xuefer]

IIRC in 5.0 5.1 both user and system apps is saved into /data/dalvik-cache

but with 6.0 user app is saved to /data/app/$appid/oat/arm/ instead. except when xposed comes into play, all xposed modules is saved to /data/dalvik-cache/arm. e.g.: /data/dalvik-cache/arm/data@[email protected]@[email protected]. non-xposed apps should never be in /data/dalvik-cache/arm/

problem: When upgrading apps, it install to /data/app, then run dex2oat trying to save as /data/dalvik-cache/arm/data@[email protected] but failed due to lack of permission for uid/gid. next time system boot up it says optimizing app, which do the right thing saving odex as /data/app/$appid/oat/arm/base.odex this is confusing. i'm not sure which is right. system (or xposed) try to save odex to 2 different places between upgrading and boot time optimizing

[rovo89]

I have adjusted the title as the error message could be written to the logs for other reasons as well.

There's a simple reason why Xposed modules are compiled into the Dalvik cache: They're used (as modules) very early in the boot process, and they're loaded again if you start them as a normal app (with e.g. UI). There might even be two versions of the APK active until the next reboot, one for the module and one for the UI.

You probably noticed that system and framework files are still written to the Dalvik cache, and I think this is still the default for ART. However, it seems that the PackageManagerService overrides this location with the one you mentioned. But that service isn't even running yet when Xposed modules are loaded.

So the difference probably comes from the use as module (Dalvik cache) vs. as app (app directory). Apart from the messages in the log and a bit waste of space, are there any noticable issues with that?

[rovo89]

Related AOSP commits: https://github.com/android/platform_frameworks_base/commit/b94c1657eb0140f7b91f5372a9f76de5a3d87e36 https://github.com/android/platform_frameworks_base/commit/ebcac16cb1405bf7d0b570e11a287df078edfc1c

They also show the logic that is used to determine whether an app should be compiled into the Dalvik cache or the app directory:

public boolean canHaveOatDir() {
    // The following app types CANNOT have oat directory
    // - non-updated system apps
    // - forward-locked apps or apps installed in ASEC containers
    return (!isSystemApp() || isUpdatedSystemApp())
            && !isForwardLocked() && !applicationInfo.isExternalAsec();
}

Plus the app must actually be stored in it its own directory. Framework files are always sent to the Dalvik cache as they don't have a package associated with them.

Apart from the effort to recreate that behavior directly in the ART libraries, I have to check if Zygote would even be allowed to write to /data/app. I think SELinux might block this. Alternatively, maybe installd could be called like the PackageManagerService does, but I think that again this is blocked by SELinux.

So it's not that easy... But yes, ideally having two copies should be avoided, and also I have to check whether all outdated files are correctly removed on upgrading.

[xuefer]

Thanks for the update to this issue.

You're right about the two copies issue happens for xposed module apps, and I totally understand why xposed module is using /data/dalvik-cache because it is used like /system/framework/*.jar files (correct me if i'm wrong). having two copies is not a big issue because most modules is small and we mostly install limited number of modules.

But for other apps that is not xposed module, I don't understand why it failed to create oat file in /data/dalvik-cache when _upgrading the app, no oat file until reboot. i suppose in this case it run in interpret mode, so no JIT no speed grain from art for those users keep device on (not-rebooted) during sleep there isn't much chance for oat file to be created correctly

[rovo89]

I don't understand why it failed to create oat file in /data/dalvik-cache when _upgrading the app, no oat file until reboot

Can you please show me a logcat of that? I tried to reproduce it, but the base.odex file was properly created during the update.

so no JIT no speed grain from art

Not sure if JIT is enabled at all on Marshmallow, I don't think so. But you probably mean AOT.

[xuefer]

it was a problem for some previous cm 13.0 i installed. can't reproduce for my current version, maybe a CyanogenMod 13.0 issue

[rovo89]

Was the original bug report for Xposed v82? https://github.com/rovo89/android_art/commit/9f1c158962c935b3d106eb9f67b50408e45b2227 might hide the lacking permissions.

[xuefer]

nope, i'm still on v80. oat is created correctly. i guess permission was CM-13 issue