Rockbox as an Application (Android, WebOS etc.)

[ploco]

about to 5.0 lollipop crash:

from my understanding, after disable the battery monitor, the RaaA can stay alive as long as user not trying to play a song.
by press play, the audioTrack/Streamer thread will call nativeWrite(), contain AudioTrack.write(), a blocking method that jammed the whole process while waiting in write(). I suspect this is where it crashes.
https://mailman.videolan.org/pipermail/vlc-devel/2015-March/101597.html
VLC using a non-blocking AudioTrack write() method for lollipop.
fixed the forever waiting according to this post:
https://mailman.videolan.org/pipermail/vlc-devel/2015-March/101596.html
I wonder how hard it is to bring this method to RaaA.
==[12.08.15 update]=============================
after test with a build disabled both audioTrack and it's jni, The program still crashes in genymotion.
so it's not the JNI but something between read file and pcm_play_dma_init()?
 

[p.h.]

Is there currently a way to build RaaA working in Lollipop?
Is it enough to apply the mentioned patch or something more has to be done for RaaA to work?

[ploco]

Is there currently a way to build RaaA working in Lollipop?
Is it enough to apply the mentioned patch or something more has to be done for RaaA to work?

No. If such patch exists, would have been merged into the source already.

[p.h.]

No. If such patch exists, would have been merged into the source already.

What about this patch?

RaaA: Android work around the Kitkat ART crashes Change-Id: I21d00aa669295a615bc203555d57ca9cebb20da7
[Saint]

[ploco]

What about this patch?

RaaA: Android work around the Kitkat ART crashes Change-Id: I21d00aa669295a615bc203555d57ca9cebb20da7
[Saint]

I committed that one. Doesn't help with the lollipop case. 

[p.h.]

Do you have an idea what the problem is?
Does someone trying to tackle the problem?

[wodz]

Startup crash is related to _battery_level().

[p.h.]

The function seems not to be essential. What if the function have been disabled or just returned preset value. Would such a workaround make RaaA work?

[ploco]

Startup crash is related to _battery_level().

I knew this since Feb, but theres more after this.

The function seems not to be essential. What if the function have been disabled or just returned preset value. Would such a workaround make RaaA work?

after disable that function, if we stay away from WPS, RaaA will not crash.
as soon as it step into wps, crash! with no meaningfull adb logs.
my log shows somthing about was updateing framebuffer then stackoverflow.

 

[wodz]

Entering WPS setups PCM subsystem which is probably the cause of later crash.

[p.h.]

as soon as it step into wps, crash! with no meaningfull adb logs.
my log shows somthing about was updateing framebuffer then stackoverflow.

Have you tried to use old-fashioned printf() to output debug messages at critical points?

[wodz]

The current theory is that due to stricter policy in ART, JNI calls can be made from the rockbox main thread only.

[p.h.]

An app of hello world type, with single JNI call from outside main thread, should give an answer whether or not the theory is true.

[wodz]

Feel free to test.

[p.h.]

Unfortunately I'm not Android programmer. I'm merely build RaaA.

But I have found something that could help in finding the cause. It is possible to get more detailed debug logs, after enabling CheckJNI.
http://android-developers.blogspot.com/2011/07/debugging-android-jni-with-checkjni.html

There's a website, which give some tips on how to verify an app is ART ready:
http://developer.android.com/guide/practices/verifying-apps-art.html

Hope this helps.