[libbluray-devel] Found a JRE compiled for Android (ARM)

Sun Jan 24 15:45:24 UTC 2021

Today I tried with the 32bits build of Kodi with the arm build of that java
for termux, now that I know how to add files to the apk, it was much
easier.

So, the files for java need to be in the lib folder of the apk and adding
subfolders break the jarsigner.
This means some files will be overwritten and I used the JRE ones to do so.

with the 64bits version the error is always the same ELF TLS DT entry is
failing, with some google skills this seem like something about improperly
linking the libs and this would only be possible to overcome with the
source and the possibility to build our own java for android.

Next the 32bits, first it failed because of ld-linux-armhf.so.3 not found.
This isn't part of the package so I grabbed it from arm-linux-gnueabihf.
$ sudo apt-get install libc6-armhf-cross
and it was found in usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3

so, after that the error is:
2021-01-24 13:32:26.058 T:18658   DEBUG <general>: CBlurayCallback::Logger
- dl_posix.c:54: can't open library 'libjvm.so': dlopen failed: unknown
reloc type 17 @ 0x981984c8 (65342)

If you guys know anything else I would be happy to try but...
beyond that I have no idea what can be done.
I'm throwing the towel and giving up.

It would be outstanding to have full blurays and blurays uhd on Android. As
Shaya said it is the holy grail because it's a much better experience than
having a computer running windows and CoreElec is very hardware restricted.

On Sat, Jan 23, 2021 at 9:02 PM Vitor Dall'Acqua <veggav at gmail.com> wrote:

> I managed to insert everything into the apk, here's how:
>
> use sdk command lines tool aapt and do:
> $aapt add -v apkname.apk files/*
>
> sign with
> jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore
> ~/.android/debug.keystore apkname.apk androiddebugkey
>
> ok, now that we have everything inside the apk and unpaking the way we
> want here's the new problem:
> 2021-01-23 21:58:03.326 T:30186   DEBUG <general>: CBlurayCallback::Logger
> - dl_posix.c:54: can't open library 'libjvm.so': dlopen failed: unsupported
> ELF TLS DT entry in
> "/mnt/expand/cab01563-bcca-48fa-a0bf-0fbddaf9b192/app/org.xbmc.kodi19DV-ZUB_1OMT4YBiycijbgSzvA==/lib/arm64/libjvm.so"
>
> so, is this a game over without the source code?
>
>
> On Sat, Jan 23, 2021 at 7:53 PM Vitor Dall'Acqua <veggav at gmail.com> wrote:
>
>> Ok 10 hours of work is enough for a day. I'll be back tomorrow.
>>
>> And from what I see we actually need the files inside
>> /mnt/expand/cab01563-bcca-48fa-a0bf-0fbddaf9b192/app/org.xbmc.kodi19DV-
>> BHAaVSj7u8lhvDk_OSQttQ==/
>>
>> looking clearly now it's no == the path actually has 2 =
>>
>> I already know how to pack stuff using Kodi make apk, I'm adding here:
>>
>> build/tools/android/packaging/xbmc/build/intermediates/stripped_native_libs/debugUnsigned/out/lib/arm64-v8a/
>>
>> and when compiling those are showing up.. but for some reason.. the *so.6
>> isn't going.. probably because it is a link...
>>
>> On Sat, Jan 23, 2021 at 7:37 PM Petri Hintukainen <
>> phintuka at users.sourceforge.net> wrote:
>>
>>> la, 2021-01-23 kello 23:38 +0200, Shaya Potter kirjoitti:
>>> > On Sat, Jan 23, 2021, 11:32 PM Petri Hintukainen <
>>> > phintuka at users.sourceforge.net> wrote:
>>> > > la, 2021-01-23 kello 17:43 -0300, Vitor Dall'Acqua kirjoitti:
>>> > > > Well, I'm no expert but when I tried to add it along with other
>>> > > > libraries it ended up in the same folder along with all other
>>> > > libs.
>>> > >
>>> > > Then, it should find libjvm.so from there without any path ? If
>>> > > JAVA_HOME is unset, first probed library is "libjvm.so" without any
>>> > > path added to it.
>>> > >
>>> > > If not, you could try adding following snippet to
>>> > > bdj.c:_load_jvm(),
>>> > > before "java_home = getenv("JAVA_HOME")" line:
>>> > >
>>> > >     handle = dl_dlopen("/lib/arm64/libjvm.so", NULL);
>>> > >     if (handle) {
>>> > >         return handle;
>>> > >     }
>>> > >
>>> > > But JVM probably won't find other files it needs if those are
>>> > > inside
>>> > > the apk.
>>> >
>>> > I was arguing that the whole jvm needs to be in the apk, see the
>>> > phoneme apk I linked to.  It includes cvm in /assets/
>>>
>>> Yes, that seems to allow keeping the directory structure. libjvm.so
>>> probably looks for the other files using paths relative to it's
>>> location. But how are files in assets accessed? If those are not
>>> accessible from "normal" filesystem it doesn't work.
>>>
>>> Can we use something similar to this:
>>> /mnt/expand/cab01563-bcca-48fa-a0bf-0fbddaf9b192/app/org.xbmc.kodi19DV-
>>> BHAaVSj7u8lhvDk_OSQttQ==/lib/arm64/libkodi.so
>>>
>>> If not, those files need to be extracted somewhere in the filesystem.
>>>
>>> > _______________________________________________
>>> > libbluray-devel mailing list
>>> > libbluray-devel at videolan.org
>>> > https://mailman.videolan.org/listinfo/libbluray-devel
>>>
>>>
>>> _______________________________________________
>>> libbluray-devel mailing list
>>> libbluray-devel at videolan.org
>>> https://mailman.videolan.org/listinfo/libbluray-devel
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/libbluray-devel/attachments/20210124/302823d6/attachment.html>