Rockbox as an Application (Android, WebOS etc.)

[LambdaCalculus]

I see that it's still being reviewed. I've rolled an Android build for my N4 with this patch, and have managed to get RaaA working again with ART enabled.

Hopefully this gets accepted in soon, as I'm reading that Android L will be using ART only, and will ditch Dalvik completely.

Here's the link to the new ART runtime in Android L: https://developer.android.com/preview/api-overview.html#ART

[zzw83]

Hi

I am having the same issues with the ART runtime.
Coupld someone tell me how to apply the patch or upload a patched .apk?

Thanks

[[Saint]]

We offer a guide to working with patches on our wiki.

But before being able to consider working with patch sets, one must first set up a development environment (if you're building for Android exclusively it is not necessary to build any of our source toolchains), and be able to compile Rockbox.

In the case of compiling for Android, this also entails having the Android SDK and NDK, and a Java JRE and JDK implementation (either Oracle Java 7 or openjdk-7 is fine) installed.

I have been considering making the process of setting up an Android suitable Rockbox build environment semi-automated, but I haven't had a lot of time lately and there are quite a few OS/shell specific considerations to take into account.

Setting up a development environment may seem like a daunting task, and indeed some people may find it somewhat challenging, but it is worth the effort for several reasons in my opinion. Primarily due to the fact that you would no longer be dependant on hoping that someone will be able to provide you with an updated patched binary if a feature you would like to test is introduced, or a bug that annoyed you fixed.
You could supply your own binaries as desired, at your leisure.
Secondarily for the sake of education and self discovery, there is vast potential for learning here.


[Saint]

[ZincAlloy]

Setting it up can be challenging, indeed. I'm starting to consider it a necessity, though. People come up with bugfixes rather quickly, but it can take months until they are committed.

[zzw83]

We offer a guide to working with patches on our wiki.

But before being able to consider working with patch sets, one must first set up a development environment (if you're building for Android exclusively it is not necessary to build any of our source toolchains), and be able to compile Rockbox.

In the case of compiling for Android, this also entails having the Android SDK and NDK, and a Java JRE and JDK implementation (either Oracle Java 7 or openjdk-7 is fine) installed.

I have been considering making the process of setting up an Android suitable Rockbox build environment semi-automated, but I haven't had a lot of time lately and there are quite a few OS/shell specific considerations to take into account.

Setting up a development environment may seem like a daunting task, and indeed some people may find it somewhat challenging, but it is worth the effort for several reasons in my opinion. Primarily due to the fact that you would no longer be dependant on hoping that someone will be able to provide you with an updated patched binary if a feature you would like to test is introduced, or a bug that annoyed you fixed.
You could supply your own binaries as desired, at your leisure.
Secondarily for the sake of education and self discovery, there is vast potential for learning here.


[Saint]

Thanks for this. I've built rockbox before but haven't used patches. Also I don't have a linux machine at the moment.

If someone built this with the art patch, would you upload it?
There'd be more than a few grateful here!
 

[Sakura90]

Setting it up can be challenging, indeed. I'm starting to consider it a necessity, though. People come up with bugfixes rather quickly, but it can take months until they are committed.

I see... would that be the case for this fix?

So I see a fix for a crash in the Android build was committed yesterday:

http://git.rockbox.org/?p=rockbox.git;a=commit;h=4b181b4

Great stuff Jonathan Gordon! Can't wait to try it out once Rasher's builds start going again.

I'm hoping this will fix the problem I have with Rockbox in that I get random black screen crashes. But also, in more recent builds, I find that audio starts stuttering once the screen goes off. Problems perhaps related to my ROM (Cyanogenmod 11) and ancient phone (Galaxy S[1]).

It was made a while ago, but I tried a Rasher build yesterday and I have the same problem. Random black screens and occasional stuttering.

It's the only serious issue it seems, aside that I didn't have problems in 2 days of general use. I'm trying to see if the Android port can replace my beaten up Fuze. I'm on an old LG P500, Froyo 2.2.1.

Other minor issues are the fact that the graphical EQ is unusable, I touch every square inch of the screen but it has no effect . Also the balance setting doesn't work at all, be it 100% or -100% audio is always centered.


Edit: An old build from 26/2 (taken from an Internet Archive link posted in the rasher's daily builds thread) seems to work perfectly. No black screens so far, and I went to homescreen and back to Rockbox several times. With current builds by the 3rd or 4th time of doing so it's black screen for sure.

Will try the stuttering with music tomorrow. Aside the clock not working there isn't any apparent drawbacks with this old build. I'm happy for now

[[Saint]]

If you're on 2.2.1, then why are you asking about a patch for a runtime that your device is incapable of supporting?

Additionally, if this patch were to be accepted, and you remained on Android 2.2.1 (and even if you upgraded to 2.3), you would lose your ability to run this software due to the minimum API required to run it being bumped. So I don't believe this to be in your best interests.

Removing your case from perspective entirely, it still isn't clear whether or not adding this patch is in the interests of the many. Currently, statistically speaking, there are exactly zero people in the world who need this patch. As of this writing, every single man, woman, and child using the ART runtime is doing so in a completely unsupported fashion. Either by way of installing a developer preview, or enabling an alternate runtime from the developer menu that comes with a specific warning which states that it is unsupported.

Considering historical data on adoption rates, I would be incredibly surprised in more than 10%  of the population were using Android 5+ in the next 12 months. When one considers how many of that 10% would be using Rockbox on their devices (hint: it would be sweet fuck all), the need to add this patch becomes considerably less urgent. Especially considering that I don't think it too much of a stretch to suggest that most people using Rockbox on their Android devices would be perfectly capable of compiling a patched build themselves.

To make a long story short, I would not consider this patch beneficial until the amount of devices running Android 5 or greater outnumbers the amount of devices running Android 2.3 or lesser. I would not expect this to be the case for at least 12 months time.


[Saint]

[RowaN]

If you're on 2.2.1, then why are you asking about a patch for a runtime that your device is incapable of supporting?

Additionally, if this patch were to be accepted, and you remained on Android 2.2.1 (and even if you upgraded to 2.3), you would lose your ability to run this software due to the minimum API required to run it being bumped. So I don't believe this to be in your best interests.

Removing your case from perspective entirely, it still isn't clear whether or not adding this patch is in the interests of the many. Currently, statistically speaking, there are exactly zero people in the world who need this patch. As of this writing, every single man, woman, and child using the ART runtime is doing so in a completely unsupported fashion. Either by way of installing a developer preview, or enabling an alternate runtime from the developer menu that comes with a specific warning which states that it is unsupported.

Considering historical data on adoption rates, I would be incredibly surprised in more than 10%  of the population were using Android 5+ in the next 12 months. When one considers how many of that 10% would be using Rockbox on their devices (hint: it would be sweet fuck all), the need to add this patch becomes considerably less urgent. Especially considering that I don't think it too much of a stretch to suggest that most people using Rockbox on their Android devices would be perfectly capable of compiling a patched build themselves.

To make a long story short, I would not consider this patch beneficial until the amount of devices running Android 5 or greater outnumbers the amount of devices running Android 2.3 or lesser. I would not expect this to be the case for at least 12 months time.


[Saint]

The kind of people that run the Android port of Rockbox are exactly the kind of people who will upgrade to the latest version of Android ASAP, one could argue. Because both are of the same category, bleeding edge and unofficial.. although Lollipop (ART) has officially come to many devices now, a month after your post.

Personally I'm using CM12 (Lollipop) on my Galaxy S4 now.
http://forum.xda-developers.com/galaxy-s4/i9505-orig-develop/rom-cyanogenmod-12-t2943934/

[steak]

If you're on 2.2.1, then why are you asking about a patch for a runtime that your device is incapable of supporting?

Additionally, if this patch were to be accepted, and you remained on Android 2.2.1 (and even if you upgraded to 2.3), you would lose your ability to run this software due to the minimum API required to run it being bumped. So I don't believe this to be in your best interests.

Removing your case from perspective entirely, it still isn't clear whether or not adding this patch is in the interests of the many. Currently, statistically speaking, there are exactly zero people in the world who need this patch. As of this writing, every single man, woman, and child using the ART runtime is doing so in a completely unsupported fashion. Either by way of installing a developer preview, or enabling an alternate runtime from the developer menu that comes with a specific warning which states that it is unsupported.

Considering historical data on adoption rates, I would be incredibly surprised in more than 10%  of the population were using Android 5+ in the next 12 months. When one considers how many of that 10% would be using Rockbox on their devices (hint: it would be sweet fuck all), the need to add this patch becomes considerably less urgent. Especially considering that I don't think it too much of a stretch to suggest that most people using Rockbox on their Android devices would be perfectly capable of compiling a patched build themselves.

To make a long story short, I would not consider this patch beneficial until the amount of devices running Android 5 or greater outnumbers the amount of devices running Android 2.3 or lesser. I would not expect this to be the case for at least 12 months time.


[Saint]

The kind of people that run the Android port of Rockbox are exactly the kind of people who will upgrade to the latest version of Android ASAP, one could argue. Because both are of the same category, bleeding edge and unofficial.. although Lollipop (ART) has officially come to many devices now, a month after your post.

Personally I'm using CM12 (Lollipop) on my Galaxy S4 now.
http://forum.xda-developers.com/galaxy-s4/i9505-orig-develop/rom-cyanogenmod-12-t2943934/

As a matter of fact I am the kind of user that run rb as an app and I will NOT upgmade to the latest version of Android. Why should I if it does whaè I need. = run rb and the 20 or so app that I need. Besides I have 2 android devices and one is so "old" by cutting edge standards (2010) nobody's going to propose an upgrade for it. I plan to upgrade to 2.3 though, since 2.2 is not supported by some useful apps. Upgrading ASAP was an emergency until the hardware+software became usable & stable. Computer wise I'm perfectly happy with my Windows XP on my 12 years old desktop. I can see why I could upgrade but technology is not the big thing in my life, just a very useful tool that helps.
Of course there are rb users who will upgrade ASAP but most logically it has nothing to do with the fact they like rb : an app which moves from one port to the next without changing much because it's been carefully thought for years. Rockbox does not strike me as something that has to be redesigned every five minutes.

Having said that, it's good to see that bleeding edge users who need to upgrade Android ASAP pick rb as an app. Clearly it's not just the latest upgrade they are after but also something that makes sense. I don't upgrade asap but I keep an eye on what upgrading could bring me...

[zzw83]

Is anyone using this successfully with lollipop?
The program crashes for me in lollipop.

[LambdaCalculus]

That's to be expected. If you go back through this topic thread, you'll see that RaaA doesn't work with the new ART runtime in Lollipop.

[zzw83]

That's to be expected. If you go back through this topic thread, you'll see that RaaA doesn't work with the new ART runtime in Lollipop.

There was a build a few months ago that actually worked in lollipop.

[[Saint]]

I sincerely doubt this, sorry.

Absolutely nothing has changed during that time in the areas that affect this.


[Saint]

[Boite de roche]

Hello!

Rockbox on Android is a very good news!

After installation, I can't locate the .rockbox directory on my Galaxy S4 mini (GT-I9195, Android 4.4.2).
Can anyone confirm that root access is needed to use my own modified .wps file?

Thanks

[steak]

In android the folder name is <rockbox> without dot. No need for a rooted phone (mine are not)