Android R preview and houdini (arm emulators)

[fguy]

Google published the Android R project https://android.googlesource.com/platform/manifest/+/refs/tags/android-r-preview-1

Images for the emulator in the SDK are also available. The Google Play atom x64_64 image contains support for translating arm and arm64 code. This is the first such publication. I have not tested the functionality of this option yet. I also saw that the integration for android R is different from the previous one - there are no bin/houdini(64) and lib(64)/libhoudini(64).so files and there is no link in the prop to the bridge file (libhoudini.so). If the integration of houdini requires fixing the source code for Android R, which google will not publish, then we will not be able to do it ourselves or it will take a lot of time. I still hope for a better scenario.

Also at the moment it remains unknown whether android 10 will be integrated into ChromeOS and whether it will contain support for arm64.

[Chih-Wei Huang]

fguy <fguy...@gmail.com> 於 2020年2月26日 週三 下午9:24寫道：

>
> Google published the Android R project https://android.googlesource.com/platform/manifest/+/refs/tags/android-r-preview-1
> Images for the emulator in the SDK are also available. The Google Play atom x64_64 image contains support for translating arm and arm64 code. This is the first such publication. I have not tested the functionality of this option yet. I also saw that the integration for android R is different from the previous one - there are no bin/houdini(64) and lib(64)/libhoudini(64).so files and there is no link in the prop to the bridge file (libhoudini.so). If the integration of houdini requires fixing the source code for Android R, which google will not publish, then we will not be able to do it ourselves or it will take a lot of time. I still hope for a better scenario.
> Also at the moment it remains unknown whether android 10 will be integrated into ChromeOS and whether it will contain support for arm64.

Thank you for sharing this.
But I can't find where it said the image contains support
for translating arm and arm64 code?
Is there any formal announcement?


--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[fguy]

Thank you for sharing this.
But I can't find where it said the image contains support
for translating arm and arm64 code?
Is there any formal announcement?

I downloaded the "Google Play Intel x86 Atom_64 System Image" image for the Android SDK emulator and unpacked it. 

Direct link to the file https://dl.google.com/android/repository/sys-img/google_apis_playstore/x86_64-R_r01-windows.zip

The presence of arm support can be seen in build.prop in the archive or by unpacking the img files. 

[fguy]

Another interesting fact is that support for Arm in Android 11 is located in the system-root image, and for Android 9 in ChromeOS in the vendor image and provided by Intel as a prebuild bin. In the system image, only the basic Android components are located - on the basis of this it turns out that the arm emulation for android 11 should be integrated into the source code.

[Mauro Rossi]

Hello,

How did you mounted the second linux partition in system.img ?

I've tried with mount  specifying offset and sizelimit

and with kpartx (the loop devices are mapped)

but I always get this error:

mount: /home/utente/mount3: wrong fs type, bad option, bad superblock on /dev/mapper/loop20p2, missing codepage or helper program, or other error.

Thanks

[fguy]

How did you mounted the second linux partition in system.img ?

I've tried with mount  specifying offset and sizelimit

and with kpartx (the loop devices are mapped)

but I always get this error:

mount: /home/utente/mount3: wrong fs type, bad option, bad superblock on /dev/mapper/loop20p2, missing codepage or helper program, or other error.

I unpacked system.img using 7zip and got super.img. I unpacked the super.imp file using UFS Explorer by finding 3 partitions of system-root, product and vendor in it. 

[Michael Goffioul]

I checked the x86 image, the system.img contains 2 partitions: vbmeta and super. The latter implements the dynamic partitioning, new in Android q. You can use losetup to scan the raw image and create the 2 loop devices. Using lpdump utility, host tool built in Android q, I could then see the list of actual partitions contained in the super partition. There's no tool in Android q to extract the partitions, but master branch of system/extra contains a tool lpunpack that might do the trick.

Michael.

[Mauro Rossi]

I checked the x86 image, the system.img contains 2 partitions: vbmeta and super. The latter implements the dynamic partitioning, new in Android q. You can use losetup to scan the raw image and create the 2 loop devices. Using lpdump utility, host tool built in Android q, I could then see the list of actual partitions contained in the super partition. There's no tool in Android q to extract the partitions, but master branch of system/extra contains a tool lpunpack that might do the trick.

Michael.

Thanks Michael,

lpunpack tool available is also available in system/extra of q-x86 branch,

I built it with:

lunch android_x86_64-userdebug
mm lpunpack

7z e system.img
lpunpack super.img [use a folder if you want to avoid rewriting system.img]

at this point there is an inner system.img file that can be mounted with Ubuntu file manager by right click and selecting "Open With Disk Image Mounter"

After having mounted the inner system.img the lib64/arm64 and lib/arm folders are present.

Looking at AOSP rel. 10 and master branches the libnative{bridge,loader} were moved from system/core to art/ project,

but looking at the commits after the move there are not much changes.

Is there a way we could try to use libnative{bridge,loader} of Q with lib64/arm64 and lib/arm of R?

Mauro

[Michael Goffioul]

On Sat, Mar 7, 2020 at 4:55 AM Mauro Rossi <issor...@gmail.com> wrote:

I checked the x86 image, the system.img contains 2 partitions: vbmeta and super. The latter implements the dynamic partitioning, new in Android q. You can use losetup to scan the raw image and create the 2 loop devices. Using lpdump utility, host tool built in Android q, I could then see the list of actual partitions contained in the super partition. There's no tool in Android q to extract the partitions, but master branch of system/extra contains a tool lpunpack that might do the trick.

Michael.

Thanks Michael,

lpunpack tool available is also available in system/extra of q-x86 branch,

Silly me, I was just looking at some commit in system/extra that didn't include lpunpack. I didn't realize it predates q-x86...

 

After having mounted the inner system.img the lib64/arm64 and lib/arm folders are present.

Looking at AOSP rel. 10 and master branches the libnative{bridge,loader} were moved from system/core to art/ project,

but looking at the commits after the move there are not much changes.

Is there a way we could try to use libnative{bridge,loader} of Q with lib64/arm64 and lib/arm of R?

From what I could gather, these images use a different translation layer, called ndk_translation. the ARM directories (e.g. lib/arm) only contains the runtime environment compiled for ARM platform (just stock AOSP libraries compiled for a different CPU). For a full native bridge, you need the glue libraries that will interface between the guest/emulated system and the real platform. In houdini, these were in lib/arm/nb; for ndk_translation, there are a set of /system/lib/libndk_translation_proxy_* libraries that are likely related, but I'm not sure. It seems that this other translation layer is also closed source, I couldn't find any reference to it, except in some bug report or logs (mostly related to ARC for ChromeOS).

[Michael Goffioul]

On Sat, Mar 7, 2020 at 9:47 AM Michael Goffioul <michael....@gmail.com> wrote:

On Sat, Mar 7, 2020 at 4:55 AM Mauro Rossi <issor...@gmail.com> wrote:

I checked the x86 image, the system.img contains 2 partitions: vbmeta and super. The latter implements the dynamic partitioning, new in Android q. You can use losetup to scan the raw image and create the 2 loop devices. Using lpdump utility, host tool built in Android q, I could then see the list of actual partitions contained in the super partition. There's no tool in Android q to extract the partitions, but master branch of system/extra contains a tool lpunpack that might do the trick.

Michael.

Thanks Michael,

lpunpack tool available is also available in system/extra of q-x86 branch,

Silly me, I was just looking at some commit in system/extra that didn't include lpunpack. I didn't realize it predates q-x86...

 

After having mounted the inner system.img the lib64/arm64 and lib/arm folders are present.

Looking at AOSP rel. 10 and master branches the libnative{bridge,loader} were moved from system/core to art/ project,

but looking at the commits after the move there are not much changes.

Is there a way we could try to use libnative{bridge,loader} of Q with lib64/arm64 and lib/arm of R?

From what I could gather, these images use a different translation layer, called ndk_translation. the ARM directories (e.g. lib/arm) only contains the runtime environment compiled for ARM platform (just stock AOSP libraries compiled for a different CPU).

Correction, the files in the ARM directories seem to contain the glue layer. Disassembling them reveals that many functions are just empty shells that perform internal branching.

Also the equivalent of bin/houdini is bin/ndk_translation_program_runner_binfmt_misc (binfmt is enabled from etc/init/ndk_translation.rc).

[fguy]

The following preview version (2) of android R is released. The new image for the SDK emulator still contains support for arm 32 and 64. 

The nativebridge libraries are also located in the file system\apex\com.android.art.release.apex.

ChromeOS R80 images became available - they still use android 9 and houdini only for arm32. Whether Android 10 will be used in ChromeOS is still unknown.

[fguy]

I tested android R on an emulator. Support for code translation arm 32 and 64 really works. The question remains open - can we get this option by building android 11 from the AOSP repository or is it available only for Google. The presence of this code in the system image gives hope that arm code emulation should be available in AOSP.

[Chih-Wei Huang]

fguy <fguy...@gmail.com> 於 2020年3月22日 週日 下午7:36寫道：

>
> I tested android R on an emulator. Support for code translation arm 32 and 64 really works. The question remains open - can we get this option by building android 11 from the AOSP repository or is it available only for Google. The presence of this code in the system image gives hope that arm code emulation should be available in AOSP.

Indeed. That sounds great!
However, I guess nobody knows the answer until
the full Android R source is released.

[Jose Luis s]

Would you mind pointing us good directions to get this running in a emulator? Whatever emulator you use, Qemu? VBox?

Or maybe some guide in the net, I've really search for this but only find some scripts from Celadon project to get binary files to be copied in a USB to have a live system.

Thanks

[fguy]

I tested android R on an emulator from the android SDK.

[Jose Luis s]

Ok. I've never used this emu.

thanks

[Chandler Wu]

hi everyone ,

dose someone got this arm native bridge so lib?