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.
