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


On Wed, 4 Mar 2020 at 15:09, Paschalis Mpeis <[email protected]>
wrote:

> 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
>
>
>
> On Monday, March 2, 2020 at 10:50:17 PM UTC+2, Paschalis Mpeis wrote:
>>
>> 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
>> <https://cs.android.com/android/platform/superproject/+/android10-release:art/>
>>  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
>> <https://android.googlesource.com/platform/system/core/+/master/fs_mgr/README.overlayfs.md#introduction>
>> .
>> 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
>> <https://cs.android.com/android/platform/superproject/+/android10-release: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
>> <https://cs.android.com/android/platform/superproject/+/android10-release:art/build/apex/Android.bp;l=10>
>> to art_runtime_debug_binaries_prefer32_device
>> <https://cs.android.com/android/platform/superproject/+/android10-release:art/build/apex/Android.bp;l=67>.
>> 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
>> <https://android.googlesource.com/platform/system/apex/+/refs/heads/master/docs/README.md>,
>> 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
>> <https://source.android.com/devices/architecture/modular-system/runtime#android-runtime-art-changes>
>>  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
>>
>>
>> --
> --
> You received this message because you are subscribed to the "Android
> Building" mailing list.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/android-building/4ccec7fe-5b46-4a45-8afd-0690dd20cd67%40googlegroups.com
> <https://groups.google.com/d/msgid/android-building/4ccec7fe-5b46-4a45-8afd-0690dd20cd67%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
-- 
You received this message because you are subscribed to the "Android Building" 
mailing list.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-building/CAAttue2E1F2acFJmssp3eyvtG4gPCLyBBJDzhAH7-dyh7MQ6ZA%40mail.gmail.com.

Reply via email to