Modify and install dex2oat in android10 (apex issues)

[Paschalis Mpeis]

Hello,

In part of my development cycle I want to be able to compile and test the dex2oat utility relatively easy.

I am using android10-release on sailfish, and I am having some issues since the apex introduction.

Previously just building and pushing dex2oat to /system/bin/ was enough.

dex2oat utility belongs to the runtime apex, which comes in two variants:

    - com.android.runtime.release, and 

    - com.android.runtime.debug

For example, libart.so and libart-compiler.so on a user-debug build are put on this directory:

/system/apex/com.android.runtime.debug/

So I can mount /system, push the above libraries, and on reboot my changes are on effect.

I know it is not supposed to be done like that, but for development purposes is fine and fast.

dex2oat however, for some reason on the user-debug build is put on: /apex/com.android.runtime/

Since it is not under /system, it cannot be mounted as r/w using instructions found here.

I know /apex it is already a mountpoint from an installed apex, but I wasn't able to generate just the runtime .apex file from aosp.

Attempt1: Put dex2oat out of runtime.release apex:

I've tried to remove it from release and put it in the debug by modifying art/build/apex/Android.bp.

The idea was to use the same workflow that I've used for libart.so, but the phone won't boot.

Specifically, I moved it from art_runtime_base_binaries_prefer32 to art_runtime_debug_binaries_prefer32_device. f 

I've also exported this DISABLE_APEX_LIBS_ABSENCE_CHECK to true, so build/make wont complain.

But I am sure that I am missing something somewhere..

Attempt2: Generate a new apex

The proper way would be to generate a new apex, with some instructions here, and then install it to the device.

The instructions mention however that apex is under development, and it does not mention how to create the apex_payload.img for example.

Also here it says that the runtime apex is not update-able on android10. I assume on release builds with an OTA mechanism,

but still it is not clear whether it is possible without building each time the whole system.img and then flash it (which is quite inconvenient).

I've tried the following:

1. m com.android.runtime.release.dex2oat_32

This builds and puts dex2oat at:

<out/sailfish>/system/apex/com.android.runtime.release/bin/

I guess this is a quick way of updating the apex with the new version of dex2oat.

2. m com.android.runtime.release

This does take a lot of time, and it builds everything from the apex.

I should run this once, and then proceed update with step 1.

Questions:

1. What is the best way to modify and push dex2oat for quick develop/test cycle.

Is the attempt1 a viable approach? Or any other approach that does not require reflashing the

whole system.img?

2. If I have to generate a new runtime release apex: is there any make target that generates and signs it in the soong build system?

For my attempt2, what is the instruction to generate the apex_payload.img on a user-debug build? 

Thanks for your time,

Paschalis

[Paschalis Mpeis]

It turns out attempt#1 works. However, the out/target/product/<device>/ has to be deleted first.

I thought by changing the apex/Android.bp it would have cleaned any outputs that are related with the runtime apex.

So the steps are:

1. do the changes in attempt#1
2. delete the out/target/product/<device> folder
3. build the system.img and the other images
4. flash everything (and wipe previous installation)
5. now with adb remount -R and adb push I can modify the dex2oat utility

[Orion Hodson]

Hi Paschalis

Great to see you've found a solution. We're in the midst refactoring ART for Mainline and it's not as easy to work with as we'd like.

Internally, we use the instructions from art/test/README.chroot.txt to run tests locally and in our build&test infra. The doc also has instructions for using a smaller master-art manifest that is still based on AOSP, but restricted to projects that ART and it's tests depend on. You can also run tests on a host rather than a target device. This is much faster, but limits you to x86/x86_64.

Happy hacking

Orion

--
--
You received this message because you are subscribed to the "Android Building" mailing list.
To post to this group, send email to android-...@googlegroups.com
To unsubscribe from this group, send email to
android-buildi...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-building?hl=en

---
You received this message because you are subscribed to the Google Groups "Android Building" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-buildi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/4ccec7fe-5b46-4a45-8afd-0690dd20cd67%40googlegroups.com.