← Back to team overview

ubuntu-phone team mailing list archive

Re: Using 64bit Android BSPs with Ubuntu

 

On 08.09.2015 09:14, Vicamo Yang wrote:
On Tue, Sep 8, 2015 at 12:54 PM, Simon Fels <simon.fels@xxxxxxxxxxxxx>
wrote:

On 07.09.2015 17:21, Oliver Grawert wrote:

Am Montag, den 07.09.2015, 14:57 +0100 schrieb John McAleely:


Are these the two options we have? What pros and cons are there for
each?


do you actually know (did anyone test) if hybris would get along with
running in 32bit on the ubuntu side while the container is 64bit ? i
suspect there needs to be some syscall translation between the two
hybris sides ...


I doubt that will work. At least not for libGLES, libEGL, .. as they don't
use proper length-defined types like uint16_t. Also from what I've seen we
can't promise which HAL libraries we get in 32 / 64 bit and which only in
32 bit and which only in 64 bit. The Android CDT defines a small subset of
Android libraries which must be available in both variants but that isn't
enough for our purpose. Also I am not entirely sure if the HAL API is
reliable in terms of well defined types.


Most of the Android BSP libraries has both 32 and 64 bit builds on aarch64
if LOCAL_32_BIT_ONLY is not specified. libmediaplayerservice [1] is one of
the exceptions. HAL modules usually come with both versions, too. But
sometimes there is no 32 bit NFC module, and sometimes no 64 bit bluetooth
and camera modules. libGLES, libEGL and all the libs that are required by
app_process{32,64} must have both 32 and 64 bit versions because you need
app_process32 to exist in 64 bit android to launch 32 bit apps.

My point was just that we can rely on anything other than what the CDD defines. If we have a 64 bit only -> ubuntu lib -> 32 bit app dependency somewhere in our system than we need to rework that on our side. However this might end up very complex if we have to deal with multiple devices where one has a 32 bit NFC HAL module where the other one has a 64 bit one.

For the bluetooth HAL it looks like this comes down to problems with Bluedroid which in turn requires the the whole JNI layer to be 32 bit only [1]. We need to identify all those flows in our system and see where we end up with problems.

regards,
Simon

[1]: https://android.googlesource.com/platform/packages/apps/Bluetooth/+/master/jni/Android.mk



References