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 <[email protected]> wrote: > ah, ok :) understood. > > On Sun, Jan 24, 2021 at 6:02 PM Vitor Dall'Acqua <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> la, 2021-01-23 kello 23:38 +0200, Shaya Potter kirjoitti: >>>>>>> > On Sat, Jan 23, 2021, 11:32 PM Petri Hintukainen < >>>>>>> > [email protected]> 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 >>>>>>> > [email protected] >>>>>>> > https://mailman.videolan.org/listinfo/libbluray-devel >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> libbluray-devel mailing list >>>>>>> [email protected] >>>>>>> https://mailman.videolan.org/listinfo/libbluray-devel >>>>>>> >>>>>> _______________________________________________ >>>> libbluray-devel mailing list >>>> [email protected] >>>> https://mailman.videolan.org/listinfo/libbluray-devel >>>> >>> _______________________________________________ >>> libbluray-devel mailing list >>> [email protected] >>> https://mailman.videolan.org/listinfo/libbluray-devel >>> >> _______________________________________________ >> libbluray-devel mailing list >> [email protected] >> https://mailman.videolan.org/listinfo/libbluray-devel >> > _______________________________________________ > libbluray-devel mailing list > [email protected] > https://mailman.videolan.org/listinfo/libbluray-devel >
_______________________________________________ libbluray-devel mailing list [email protected] https://mailman.videolan.org/listinfo/libbluray-devel
