Moving away from libhoudini

[haziqsembilanlima]

For years we have been reliant on libhoudini to translate ARM instructions to x86. Obviously, in some cases it isn't ideal as there is absolutely zero details on how it functions and some projects refuse to include this library due to its own nature. As years have passed, there are very few new releases of Intel-based android tablets, if not no new releases at all.

As stated above, we have to move or establish a new alternative to overcome these challenges as I fear that android might introduce a new features that could break this functionality. Seeing some projects like Citra that manages to mature up their forked ARM translator makes me think that it is possible to move away from libhoudini (though it could be extremely complex)

Is there anyone attempting on this? Is there any interest on this kind of alternative?

[youling 257]

chrome os stable channel Android 7.1, chrome os canary channel Android 9.0.

chrome os houdini at /opt/google/containers/android/vendor.raw.img.

extract houdini from chrome os, 

https://github.com/me176c-dev/android_vendor_asus_K013/commits/cm-14.1

Borrow newer version of Houdini and Widevine DRM from Chrome OS

Update ChromeOS to 10176.76.0

https://github.com/me176c-dev/android_vendor_asus_K013/commits/lineage-16.0

Update Houdini and Widevine from ChromeOS Canary 11196.0.0 build

[Mauro Rossi]

Hi youling257,

Great contributions, as always

Do you know if there is some repo image with houdini for Android 8.1 or if it is safe to use the versions bundled with Canary?

I am having a problem with Unity crashing vulkan apps and native bridge is involved in the problem

Mauro

[Tareq AL NOUNOU]

If you want my advice, try PrimeOS which is based off android 7.1.2 x86.

I have tried all sorts of x86 images and applied all kinds of Houdini mods to get them to run the complex apps on Google Play Store.

PrimeOS's recent release is the most stable x86 release I have ever seen with the ability to run OpenGL and Vulcan native apps straight out of the box.

Give it a try and see if it'll work for you.

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.

[DDS Central]

Not really discussing forks here.

As for Houdini, qemu-user along with some shim libs could be a good alternative. BlueStacks uses qemu and it seems to work quite well.

[youling 257]

I can't answer your question, that's not my specialty.

chrome os stable version image bin file can use kpartx -av, but chrome os canary image is signed, bin.signed, i haven't extract Android 9 vendor.raw.img.

在 2018年11月5日星期一 UTC+8下午7:57:04，Mauro Rossi写道：

[Jon West]

We grab the canary 9 binaries for Bliss using @lambdadroid's methods here: https://github.com/BlissRoms-x86/vendor_bliss_priv

[Michael Goffioul]

As for Houdini, qemu-user along with some shim libs could be a good alternative. BlueStacks uses qemu and it seems to work quite well.

With the work on Android 10, I've given this idea some more thoughts. I spent some time doing various experiments with unicorn-engine and qemu. You can find some materials here:

https://www.freelists.org/archive/unicorn-engine/10-2019

https://github.com/goffioul/android_nativebridge_x86

https://github.com/goffioul/unicorn/tree/q-x86

https://github.com/AeonLucid/AndroidNativeEmu

I've got some positive results with unicorn/AndroidNativeEmu, but in the end, I found out that the lack of syscall integration in unicorn was a burden, while it's readily available in vanilla qemu-user. I think it should be possible to work out a solution by re-using the qemu-user code base. The main idea at the moment would be to bootstrap the emulator by loading ARM-compiled linker and libdl.so, then call dlopen/dlsym to interface with the native bridge.

It's very unlikely that I will get anywhere on my own (lack of time, lack of expertise in the field). I'm posting this here to see whether there are other people interested to join the effort. It may lead to nothing, but at least it's a learning experience :).

[Michael Goffioul]

Here's the experiment so far (everything running locally on my Intel-based desktop):

- the attached patch attempts to load linker into memory, perform symbol relocation on it, then call __loader_dlopen with a hardcoded path

- pull qemu from git and configure with "--target-list=arm-linux-user --disable-system"

- compile qemu

- pull houdini (I'm using 9_y) and unpack locally: for simplicity, I've unpacked it into /system/lib/arm/, with the linker executable copied into /system/bin/

- run with: ./arm-linux-user/qemu-arm -d in_asm,cpu,page /system/bin/linker

It starts, but quickly crashes. Not sure I'll be able to continue experimenting, so I'm posting here for reference.

 

[Michael Goffioul]

Just FYI, I made small progress on this. I'm now able to initialize a QEMU engine on Android, in user mode, load an ARM-compiled shared library, locate a function symbol and execute the function in the QEMU engine. The test function is trivial, but does make a ALOGI call, which ends up in the device logcat output. This means that the user-mode glue layer is (at least partially) working.

[Michael Goffioul]

I'm thinking about using ffcall to build the trampoline stubs. If anybody has a better idea, fell free to throw it.

On Tue, Oct 29, 2019 at 11:31 AM DDS Central <wdmo...@gmail.com> wrote:

Now we need some shim-libs for apps to use.

On Tue, 29 Oct 2019, 16:50 Chih-Wei Huang, <cwh...@android-x86.org> wrote:

Michael Goffioul <michael....@gmail.com> 於 2019年10月29日 週二 下午10:17寫道：

>
> Just FYI, I made small progress on this. I'm now able to initialize a QEMU engine on Android, in user mode, load an ARM-compiled shared library, locate a function symbol and execute the function in the QEMU engine. The test function is trivial, but does make a ALOGI call, which ends up in the device logcat output. This means that the user-mode glue layer is (at least partially) working.

Wow! That's a big step!
We are near the open source replacement of libhoudini.
Thank you for the great effort to achieve that.

--
You received this message because you are subscribed to the Google Groups "Android-x86 development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86-devel/CAKc24n0Pcx0CtmPX-hWci0DJj9DVEb6t%3DpKvvqG_66PQzM9-Bw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Android-x86 development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86-devel/CAKy9RdbYD3DSxHJ8geSyEEC42a_PBFyMnfUBfxuZskaMjq1MBA%40mail.gmail.com.

[Michael Goffioul]

A small victory: I can now successfully run this sample app (https://github.com/android/ndk-samples/tree/master/hello-jni) compiled for armeabi-v7 on my x86 build.

[Michael Goffioul]

And another one: I got to a point where I can launch netflix, sign in and get to the home screen (playback is another story, though).

[Hilmy Akatsuki]

How?

On Saturday, November 9, 2019 at 6:40:41 AM UTC+6, Michael Goffioul wrote:

And another one: I got to a point where I can launch netflix, sign in and get to the home screen (playback is another story, though).

On Fri, Nov 1, 2019 at 1:15 PM Michael Goffioul <michael...@gmail.com> wrote:

A small victory: I can now successfully run this sample app (https://github.com/android/ndk-samples/tree/master/hello-jni) compiled for armeabi-v7 on my x86 build.

On Tue, Oct 29, 2019 at 3:10 PM Michael Goffioul <michael...@gmail.com> wrote:

I'm thinking about using ffcall to build the trampoline stubs. If anybody has a better idea, fell free to throw it.

On Tue, Oct 29, 2019 at 11:31 AM DDS Central <wdmo...@gmail.com> wrote:

Now we need some shim-libs for apps to use.

On Tue, 29 Oct 2019, 16:50 Chih-Wei Huang, <cwh...@android-x86.org> wrote:

Michael Goffioul <michael...@gmail.com> 於 2019年10月29日 週二 下午10:17寫道：

>
> Just FYI, I made small progress on this. I'm now able to initialize a QEMU engine on Android, in user mode, load an ARM-compiled shared library, locate a function symbol and execute the function in the QEMU engine. The test function is trivial, but does make a ALOGI call, which ends up in the device logcat output. This means that the user-mode glue layer is (at least partially) working.

Wow! That's a big step!
We are near the open source replacement of libhoudini.
Thank you for the great effort to achieve that.

--
You received this message because you are subscribed to the Google Groups "Android-x86 development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to android-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86-devel/CAKc24n0Pcx0CtmPX-hWci0DJj9DVEb6t%3DpKvvqG_66PQzM9-Bw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Android-x86 development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to android-...@googlegroups.com.

[Michael Goffioul]

[posted on devel mailing list, reposting here for information purpose, this is work in progress to replace houdini with QEMU-based open source implementation]

I started to publish a set of repos containing the current implementation:
https://github.com/goffioul/ax86-nb-qemu

https://github.com/goffioul/ax86-nb-qemu-guest

I also added a required libffi patch to my Google drive.

At the moment, it's still extremely DIY, so if you don't know what you're doing, don't even bother. With all this, using Houdini runtime, and using patched ARM libc.so, I'm able to run Netflix (for the DRM support, I'm still using the widevine blobs from pie-x86).

Apps that interact with Android binder IPC natively do not work, due to an ABI change between P and Q, so the Houdini runtime from P cannot work. I'm now working towards created my own runtime for Q (it's basically compiling vanilla AOSP for generic ARM target).

You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/909d0c74-75d1-4a34-bc16-6d4ed8a8a81d%40googlegroups.com.

[Michael Goffioul]

I've now created my own Android Q runtime for the emulator, which means I've now something completely houdini-free. I'm trying to run candy crush saga as a test case, but it keeps crashing, trying to free an invalid memory pointer. Without access to the original source code, it's very to track down what's going on.

Would anybody have a suggestion for an open source native game-like app that I could use instead?

On Thu, Nov 14, 2019 at 1:00 PM Michael Goffioul <michael....@gmail.com> wrote:

I started to publish a set of repos containing the current implementation:

https://github.com/goffioul/ax86-nb-qemu

https://github.com/goffioul/ax86-nb-qemu-guest

I also added a required libffi patch to my Google drive. 

At the moment, it's still extremely DIY, so if you don't know what you're doing, don't even bother. With all this, using Houdini runtime, and using patched ARM libc.so, I'm able to run Netflix (for the DRM support, I'm still using the widevine blobs from pie-x86).

Apps that interact with Android binder IPC natively do not work, due to an ABI change between P and Q, so the Houdini runtime from P cannot work. I'm now working towards created my own runtime for Q (it's basically compiling vanilla AOSP for generic ARM target).

On Fri, Nov 8, 2019 at 9:30 PM Michael Goffioul <michael....@gmail.com> wrote:

I didn't really assess it yet. I've been mostly testing with Netflix and the critical parts are not in native code (using widevine from pie-x86, I even got playback). The loading part (with symbol relocation) is apparently slower, but at runtime, Netflix felt ok to use on my test device (5yr old cpu).

On Fri, Nov 8, 2019, 9:18 PM Jon West <electr...@gmail.com> wrote:

That is some amazing progress though. Is there much of a performance hit on the emulation?

On Friday, November 8, 2019 at 7:40:27 PM UTC-5, Michael Goffioul wrote:

And another one: I got to a point where I can launch netflix, sign in and get to the home screen (playback is another story, though).

On Fri, Nov 1, 2019 at 1:15 PM Michael Goffioul <michael...@gmail.com> wrote:

A small victory: I can now successfully run this sample app (https://github.com/android/ndk-samples/tree/master/hello-jni) compiled for armeabi-v7 on my x86 build.

On Tue, Oct 29, 2019 at 3:10 PM Michael Goffioul <michael...@gmail.com> wrote:

I'm thinking about using ffcall to build the trampoline stubs. If anybody has a better idea, fell free to throw it.

On Tue, Oct 29, 2019 at 11:31 AM DDS Central <wdmo...@gmail.com> wrote:

Now we need some shim-libs for apps to use.

On Tue, 29 Oct 2019, 16:50 Chih-Wei Huang, <cwh...@android-x86.org> wrote:

Michael Goffioul <michael...@gmail.com> 於 2019年10月29日 週二 下午10:17寫道：

>
> Just FYI, I made small progress on this. I'm now able to initialize a QEMU engine on Android, in user mode, load an ARM-compiled shared library, locate a function symbol and execute the function in the QEMU engine. The test function is trivial, but does make a ALOGI call, which ends up in the device logcat output. This means that the user-mode glue layer is (at least partially) working.

Wow! That's a big step!
We are near the open source replacement of libhoudini.
Thank you for the great effort to achieve that.

--
You received this message because you are subscribed to the Google Groups "Android-x86 development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to android-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86-devel/CAKc24n0Pcx0CtmPX-hWci0DJj9DVEb6t%3DpKvvqG_66PQzM9-Bw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Android-x86 development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to android-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86-devel/CAKy9RdbYD3DSxHJ8geSyEEC42a_PBFyMnfUBfxuZskaMjq1MBA%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "Android-x86 development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86-devel/460cf5f5-fb66-418a-9b03-7c2084c43e16%40googlegroups.com.

[Michael Goffioul]

I'm sorry to say that I won't publish any more update at the moment. In the light of recent internal events (unscrupulous competitor and IP theft), any result will only be provided to our customers.

On Sun, Nov 17, 2019 at 9:35 PM Michael Goffioul <michael....@gmail.com> wrote:

Do you have a more detailed compilation error message? Obviously I don't get that error :). But note that I only build for x86, not x86_64, this may be the reason why.

On Sun, Nov 17, 2019, 7:46 PM Jon West <electr...@gmail.com> wrote:

I wasn't getting anywhere on Q with libhoudini, so I thought I'd try to add your projects. But there were errors getting it to build. error: Missing field 'access'
Any ideas on what that is about?

> To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86-devel/460cf5f5-fb66-418a-9b03-7c2084c43e16%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Android-x86 development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86-devel/9582f494-1763-416f-90da-a2fb25d4c74e%40googlegroups.com.

[DDS Central]

IP theft ? Customers ? If you're doing this for a commercial entity as part of your job, why are you even posting here then ?

Not really against commercial projects (everyone needs to eat), but I don't think posting about them is in the spirit of this project. This is an FOSS project. Most of us work on it during our free time as a hobby.

If you were working on this as a part of your job, you should have told us so before posting about your progress, so we would know you ain't necessary going to publish your work.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86-devel/CAB-99LvZsvxPXOaiu%2BfFmM4RwopVqsi5LFTg5Drs-6ciZjTKhg%40mail.gmail.com.

[Michael Goffioul]

I must admit I didn't expect such hostility. But ok. point taken.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86-devel/CAKy9Rdb2Tw72an6HkMRh6GNqbSpRXv28SxKaiQMfVpahkCxx8g%40mail.gmail.com.

[Alessandro Pozone]

> To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86-devel/9582f494-1763-416f-90da-a2fb25d4c74e%40googlegroups.com.
>
>
>
>
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups "Android-x86 development" group.
>

> To unsubscribe from this group and stop receiving emails from it, send an email to android-...@googlegroups.com.
>

> To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86-devel/CAB-99LvZsvxPXOaiu%2BfFmM4RwopVqsi5LFTg5Drs-6ciZjTKhg%40mail.gmail.com.
>
>
>
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups "Android-x86 development" group.
>

> To unsubscribe from this group and stop receiving emails from it, send an email to android-...@googlegroups.com.
>

> To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86-devel/CAKy9Rdb2Tw72an6HkMRh6GNqbSpRXv28SxKaiQMfVpahkCxx8g%40mail.gmail.com.

This is a very interesting project! I was thinking to do the same not only to "update" houdini but also to understand if it is possible to introduce the translation of ARM64v8.

Are you still working on this?

[Michael Goffioul]

On Tue, Feb 4, 2020 at 7:33 AM Alessandro Pozone <alessand...@gmail.com> wrote:

This is a very interesting project! I was thinking to do the same not only to "update" houdini but also to understand if it is possible to introduce the translation of ARM64v8.

Are you still working on this?

I had to pause the project due to other priorities. The initial code is available on github. I've some more code that I haven't pushed yet, but I will eventually publish those changes. The current status is more or less as follows:

- the emulator (ARMv7 only) itself works

- JNI is bridged (e.g. can run Netflix)

- OpenGLES is bridged (e.g. can run gles3jni demo app from NDK)

- ARM Android runtime environment built from Android/AOSP Q source tree

- more bridging is required, e.g. OpenSLES or NativeActivity, but this is not straightforward (maybe I'm not having the right approach)

- there's a problem at boot when the native bridge is available, for some reason the zygote process never reaches the point where it forks system_server; I haven't been able to track that down yet, but it's odd; if the native bridge is not available at boot, for enabled later on (e.g. by copying the .so file over to the device), then it works

[Chih-Wei Huang]

Michael Goffioul <michael....@gmail.com> 於 2020年2月6日 週四 上午8:30寫道：

Hi Michael,
I think we can begin to integrate it into q-x86 codebase.
How do you think about that?
Could you explain more about the procedures or details?


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

[Michael Goffioul]

You can of course add it to q-x86 if you wish to, but it's nowhere near usable/stable/integrable. It might generates more complaints than anything else...

This is the master repo: https://github.com/goffioul/ax86-nb-qemu

It contains links to submodules, which makes the entire code base for the android-x86 portion. I have it somewhere under vendor/ and I added libnb-qemu to my PRODUCT_PACKAGES. Then I've hardcoded the loading of libnb-qemu.so in device/generic/common/nativebridge/src/libnb.cpp. However, as I mentioned it, boot doesn't complete.

There's also a runtime part, which is in this repo: https://github.com/goffioul/ax86-nb-qemu-guest

For this, I'm using a second vanilla AOSP (Android Q) source tree. and I have this repo somewhere under vendor/. It contains a Android.mk with rules that allows me to build the runtime environement with 'make libnb-qemu-runtime'. And it contains a utility script to copy the runtime into a device through ADB (this assumes Android-x86 installed in read-write mode, and houdini .sfs must not be mounted). It also contains a bionic patch to support managing threads in the emulated environment.

Not sure you wanted some details about how the bridge is constructed, but here are some basic concepts:

- QEMU is run in user emulation mode, but it is patched to allow the execution of a single function and then exit the emulation loop to give control back to the native side: a STOP address is defined and whenever the instruction pointer reaches that address, it generates a YIELD instruction that stops the emulator

- the libnb-qemu bridge takes care of transferring arguments and return value between the native and the emulated side using the appropriate ABI, it also takes care of generating trampolines for the native side (this requires a patch in external/libffi to add support for closures)

- JNI bridge is implemented using user-defined syscalls, libnb-qemu handles them, translate arguments to native and forward to native JNI

- OpenGLES bridge is implemented using supervisor call instructions (SVC), libnb-qemu handles them and forward to native OpenGLES; there's barely any argument translation needed, as OpenGL ABI is pretty much identical in both emulated and native environment

Michael.

[Michael Goffioul]

FYI, I publish all pending code on github. It doesn't make it more functional, but at least everything is now available.

 

[haziqsembilanlima]

looks neat. since there's a lot of github links you've posted, mind listing it again where you made the changes? Sorry that I've been away for years and didn't really catch up with your progress

[Michael Goffioul]

On Sun, Feb 9, 2020 at 12:08 AM haziqsembilanlima <haziqsem...@gmail.com> wrote:

looks neat. since there's a lot of github links you've posted, mind listing it again where you made the changes? Sorry that I've been away for years and didn't really catch up with your progress

1) Native code: https://github.com/goffioul/ax86-nb-qemu

This repo uses the following submodules:

- qemu: https://github.com/goffioul/ax86-nb-qemu-qemu

- capstone: https://github.com/goffioul/ax86-nb-qemu-capstone

- glib: https://github.com/goffioul/ax86-nb-qemu-glib

2) Emulated runtime: https://github.com/goffioul/ax86-nb-qemu-guest

The latest changes were made in ax86-nb-qemu, ax86-nb-qemu-qemu and ax86-nb-qemu-guest. Note that even though I pushed the changes today, some of the commits date back from November.

Michael.

[haziqsembilanlima]

thanks a lot. looks like anbox developer has a good interest with your idea, would love to see if both of you can collab and put the reliance towards libhoudini to rest

[Michael Goffioul]

I'm open to collaboration, of course, though I haven't been reached out so far.

On Sun, Feb 9, 2020 at 2:59 AM haziqsembilanlima <haziqsem...@gmail.com> wrote:

thanks a lot. looks like anbox developer has a good interest with your idea, would love to see if both of you can collab and put the reliance towards libhoudini to rest

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/5177eaf5-0e8b-425c-b01d-8dcc2c1e6861%40googlegroups.com.

[Alessandro Pozone]

Hey Michael! 
Thank you very much for you availability and code! 

I'd love to look into it but I am currently busy with another project :( 
Will contact you as soon as I start :) 

I believe this is the future as Intel support in apps is being dropped. 
Also, a nice name for the project could be libCopperfield :D

Cheers, 
Alessandro

On Sunday, 9 February 2020 17:57:18 UTC+1, Michael Goffioul wrote:

I'm open to collaboration, of course, though I haven't been reached out so far.

On Sun, Feb 9, 2020 at 2:59 AM haziqsembilanlima <haziqsem...@gmail.com> wrote:

thanks a lot. looks like anbox developer has a good interest with your idea, would love to see if both of you can collab and put the reliance towards libhoudini to rest

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.

To unsubscribe from this group and stop receiving emails from it, send an email to andro...@googlegroups.com.