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

Vitor Dall'Acqua veggav at gmail.com
Sun Jan 24 16:11:23 UTC 2021 

This is a neat idea but this kind defeats the purpose, unless it was mostly
a copy and paste solution from what you already did and easy to achieve.
Also I don't know much of how to work with the skin kodi uses. I believe it
uses information stored in xml files to show content on the screen.

but it's kinda of a bittersweet solution, menus are part of the appeal of
physical media, that's the beauty of it.

On Sun, Jan 24, 2021 at 1:03 PM Shaya Potter <spotter at gmail.com> wrote:

> ah, ok :)  understood.
>
> On Sun, Jan 24, 2021 at 6:02 PM Vitor Dall'Acqua <veggav at gmail.com> wrote:
>
>> the thing is, I'm not a computer engineer, I'm just a veterinary that
>> knows how to solve a few problems.
>> Doing a project in this magnitude is beyond what I can do.
>>
>> I would gladly help fund something like that, and I believe many others
>> in the Kodi forum would feel the same but this is as far as my skills go.
>>
>> On Sun, Jan 24, 2021 at 12:55 PM Shaya Potter <spotter at gmail.com> wrote:
>>
>>> as I said, reach out to them to get the source code and put the work
>>> into building it with the ndk that kodi uses.  One can also look at phoneme
>>> (as petri mentioned)
>>>
>>> https://github.com/nikita36078/phoneME-android (example, don't know if
>>> this is the most uptodate version of the phoneme / android code floating
>>> around)
>>>
>>> this is a java me environment and while not what libbluray is commonly
>>> used with today, should be all that's needed for blurays to run.  With that
>>> said, I don't know what limitations it has and how its graphic drawing
>>> capabilities will work with libbluray.
>>>
>>> getting it to build with the ndk that kodi uses is probably going to be
>>> a bit of work (perhaps an understatement), but if you do, all these linking
>>> problems should hopefully disappear. (in the case of java me, it's no
>>> longer the jvm binary, but the cvm binary that you will be using)
>>>
>>> On Sun, Jan 24, 2021 at 5:45 PM Vitor Dall'Acqua <veggav at gmail.com>
>>> wrote:
>>>
>>>> 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
>>>>>>>
>>>>>> _______________________________________________
>>>> 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
>>>
>> _______________________________________________
>> 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/f2a52e6d/attachment-0001.html>

More information about the libbluray-devel mailing list