DEX_PREOPT and BUILD_PREBUILT on lollipop-x86 (ART oat files are not built)

[Ron M]

I noticed that the "old" BUILD_PREBUILT inclusion make files no longer do the job in Lollipop, 

as the art files are never being generated, and non of the *PREOPT* flags listed in 

http://source.android.com/devices/tech/dalvik/configure.html  seems to do the work.

Has anyone been able to include a PREBUILT APK in the build, so that it would run well?

I suspect modifing "WITH_DEXPREOPT" to false at BoardConfig.mk may do the trick, but I would hate to wait hours until I see anything out of it , and I don't understand how come the runtime does not build the oat file in data/dalvik-cache as it should have - for the prebuilts.

Any idea?

[Chih-Wei Huang]

2015-03-03 18:00 GMT+08:00 Ron M <ron...@gmail.com>:
> I noticed that the "old" BUILD_PREBUILT inclusion make files no longer do
> the job in Lollipop,

Why?

> as the art files are never being generated, and non of the *PREOPT* flags
> listed in
> http://source.android.com/devices/tech/dalvik/configure.html seems to do
> the work.

LOCAL_DEX_PREOPT := true
works for me.

Remember to add the package name to
PRODUCT_PACKAGES.

[Ron M]

Please see below - I am sorry I don't have logs now - I just wanted to explain what I have encountered.

On Wednesday, March 4, 2015 at 4:42:45 PM UTC+2, Chih-Wei Huang wrote:

2015-03-03 18:00 GMT+08:00 Ron M <ron...@gmail.com>:
> I noticed that the "old" BUILD_PREBUILT inclusion make files no longer do
> the job in Lollipop,

Why?

As I said, the oat files (that is what otherwise in Dalvik would be the JIT cache) are just not generated upon boot. The flow is supposed to be as follows:

1. When an APK is installed (for the sake of discussion, first boot is like "APK is installed") - 

1.1 if the OAT files (which are not really OAT, not mentioning the details anymore as I assume they are known) do not persist - there will be a Logcat error mentioning that. 
1.2 Otherwise proceed... 

2. That means that if nothing is DEX_PREOPT-ed (WITH_DEXPREOPT := false) - we'll have a longer boot - This works 
(but for a reason I really don't understand - it makes the Browser crash on some stack overflow - I suspect memory leaks, but I really don't know at the moment.
I am pretty sure it's something with memory as what crashes are some checkjni stuff - but this combination only happened when I did both Browser, VESA (qemu=1), and DEXPREOPT := false. Maybe it would work on "real device" with GPU. It happened when I tried to use google apps, so maybe GmsCore gave its issues, but I don't think so really.)

3. And that's pretty much what happens when you kill zygote/system_server and see an "App 1/<something> is updated". 

3.1 So what we see when we do LOCAL_DEX_PREOPT, which for some reason was the exact same as leaving WITH_DEXPREOPT := y,  which didn't build the OAT files for the BUILD_PREBUILT apk - is nothing at the first boot.
3.2 "App X/Y updating" - but that does not fix the issues so something with the update is wrong.

4. Installing an app (adb install whatever.apk) - does the job so I think something is only wrong with the initial detections.

I would have to look at it more seriously, and I am aware this is not the best of reports.

> as the art files are never being generated, and non of the *PREOPT* flags
> listed in
> http://source.android.com/devices/tech/dalvik/configure.html  seems to do
> the work.

LOCAL_DEX_PREOPT := true
works for me.

Remember to add the package name to
PRODUCT_PACKAGES.

Of course I did. Otherwise it wouldn't be included at all. 

[fgdn17]

Ron - Chih-Wei

simple question.....

I assume that all the work your doing and issues your finding are not repetitive...as I noticed a week or two ago

when doing some stuff with Cyanogenmod that what most of us when working with lollipop, are using 5.0.2_r1.......

When tracking a problem I found that looking in master branch and checking the log, the issue had already been addressed...

do you use a different manifest using revision="master" when pulling 5.0.2_r1 to do your debugging / testing????

[Ron M]

That's a good point.

Are you saying you have encountered those issues in the AOSP / Cyanogenmod and think they have been resolved on their respective master branches? If so, would you care to elaborate?

The default revision is android-5.0.2-r1, but each project uses the  lollipop-x86 revision.

I'm not really sure what it is and can't figure out at the moment what the status is in other upstream projects, due to limited connectivity.

-Ron Munitz

[fgdn17]

> those issues in the AOSP / Cyanogenmod

not your specific issues...as I recall the issue I was looking at was with dalvik and

found out that the dalvik being pulled / used from an aosp 5.0.2_r1 pull appeared to be

from oct 2014 / dec 2014 time frame yet the master branch had updates logs from feb 2015

time frame....

In looking at the log from feb 2015 I identified the issue I was looking at and went to the 

bug fix from the log.....

I think the art path your looking at for android-x86 is "revision=lollipop-x86" so you'd

need to verify that against android/platform/art/master, that's what I was asking about...

references:

  https://android.googlesource.com/platform/art/+/master%5E1..master/

  https://android.googlesource.com/platform/art/+log/master