Native Bridge apks

[Edgardo Gho]

Hi,

I setup my build (5.1.1) with the native bridge binaries from Fugu. This is an x86 device.

If I install an APK that has ARM binaries, it gets installed in the data partition and runs ok.

But If I try to make the APK part of the build (using PREBUILT) it thinks its an x86 apk and fails to run it (error of machine code 40 when loading the libraries).

Any other APK that is x86 gets deployed ok if I add it to the build using PREBUILT, but stuff depending on ARM emulation does not.

Any suggestion?

Thanks!

[Dave Smith]

Edgardo -

I have not tried this on more recent versions, but in the past this was because the search paths for native libraries (i.e. the .so files) are different for system applications vs. installed applications. Applications on the /system partition would only search for their native libs inside of /system/lib and they were not copied out of the APK file, whereas post-installed applications would copy their native code into /data/data/ and that would be included in the search path.

This behavior may have changed in later builds. You could try adding your native libs as additional explicit PREBUILT targets and ensure they are copied into /system/lib. If it's the same issue, that should solve the problem.

Cheers,

--

Dave Smith, PE

@devunwired

[Edgardo Gho]

Thanks for the reply.

I tried many things:

1) Having the libraries in /system/lib does not work (crashes when it tries to run them as x86 when they are ARM)

2) Having the libraries in /system/arm/lib does not work (it looks for them on /system/lib)

3) I tried putting the apk in /system/app/theApp/theApp.apk. This does not work. If its an x86 APK it works, but fails on arm APKs.

If I get the package manager info on the APK (on option 3) I get primaryCpuAbi and secondaryCpuAbi as null.

If I force an install of that APK (pm install -r /system/app/theApp/theApp.apk) It goes into data, and If I get the package info again, the primaryCpuAbi is properly filled with armeabi. So when its executed it brings houdini into play.

The problem seems to be that I can't set that primaryCpuAbi during the build. I tried many options on LOCAL_DEX_PREOPT but does not have any effect.

Is there any

[Dave Smith]

The native lib directories usually have an actual ABI sting in the path, so I would expect the location to be /system/lib/armeabi (it might be /system/lib/arm… that was backwards in your message).

The CPU ABI metadata is set by PM on install, which is why its null for a system APK. Just like the fact that system APKs can't have their .so files in the APK, there may be stricter rules about them only using the primary ABI.

You might also try the Android-IA mailing list, as houdini is an Intel creation: https://01.org/android-ia/community

[Edgardo Gho]

Thanks for the reply.

I tried many different approaches, but was unable to make it work. I guess PM assumes that any system APK (prebuilt, since all other apps will be built during the build process) match the system ABI.

It would be great if it would support detecting the ABI.

For the moment, I work around this by deploying houdini-requiring apks on /system/vendor/thirdParty. On the first boot I just install them using pm (which seems to support installing from /vendor path since I had problems installing from other locations). 

[Russell Mowszowski]

have you tried /system/app/<appname>/lib/arm   ?

Since you say that your native bridge works since you installed to data ( I assume you are sure that the app doesnt have x86 libs in it ), you could try patching the pm for your use. 

--
--
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.
For more options, visit https://groups.google.com/d/optout.