Third Party > Unsupported Builds
Making Rockbox android run on Art
greatjack:
I have heard many reports that the rockbox android app does not run when using the newer ARt runtime engine instead of the older Dalvik. Obviously since the android port relies heavily on the Jni, It would be logicial to assume that the stricter Jni settings is what is causing it to crash. I found this page https://developer.android.com/guide/practices/verifying-apps-art.html which discusses many things that can cause Jni code to malfunction, and plan on working on fixing this issue.
If anyone has a inkling of why the crash is occuring, please post it in this forum as it will help me look in the right direction
wodz:
The short answer is http://gerrit.rockbox.org/r/#/c/1211/
I abandoned this approach when figured out that text scrolling code is affected as well.
greatjack:
--- Quote from: wodz on February 24, 2017, 04:41:56 AM ---The short answer is http://gerrit.rockbox.org/r/#/c/1211/
I abandoned this approach when figured out that text scrolling code is affected as well.
--- End quote ---
Thanks wodz for your input, can you point me to the text scrolling code that needs to be fixed?
BenBrown:
Through some research I found a few relative things to note;
The minimum android-X version for art support is 21 -> https://developer.android.com/guide/practices/verifying-apps-art.html
That highest available stable build-tools for sdk release of sdk 21 is 21.1.2, the highest being 21.1.3(unstable)
I have a 5.1.1 device that I have cherry picked the above gerrit task in to rockbox and lowered the build requirements to android-21. And built against the latest ndk with sdk 21.1.2 then loading it on my 5.1.1 device. RaaA loads momentarily with a loading bar (the first time it runs) and then crashes.
I have also found BOOTDIR "/.rockbox" defined in android.h, but changing that to ./.rockbox or .rockbox did not help either
I have also simply tried to load a dummy app without jni calls and it still crashed, but in this case the executable was still packaged with in the apk.
Question, I understand the "purest" form of rockbox is straight up compile c and execute, but is running an all new main thread in pure java such a bad idea? One with its own way to show the ui menu, handle input and make calls to c functions, without the need for things like jni calls to compiled c in order to read a button press for the menu. Or is this the "great pain in the ass to make it work" that everyone has been talking about?
Edit: upon verifying my build-chain with a lower android api 4.2 I might have missed a few details, so I'm going to test 5.0 again
Edit2: Yes it actually does run on my 5.1.1 device
Chiwen:
--- Quote from: wodz on February 24, 2017, 04:41:56 AM ---The short answer is http://gerrit.rockbox.org/r/#/c/1211/
I abandoned this approach when figured out that text scrolling code is affected as well.
--- End quote ---
I encounter the text scrolling crash way before your patch back in 2014 . http://gerrit.rockbox.org/r/#/c/838/
JGordon strongly disagreed with how I mute the part that triggers the crash. http://gerrit.rockbox.org/r/#/c/838/4/firmware/drivers/lcd-scroll.c
Adb log listed this Jni call was from a different thread, not main or the one dealing with audio. Which I still couldn't figure out why till this day.
So, no its not you who make it crash. the bug has been there for a long time.
Navigation
[0] Message Index
[#] Next page
Go to full version