Android app release: feedback thread

Claggy
Claggy
Joined: 29 Dec 06
Posts: 560
Credit: 2694028
RAC: 0

RE: RE: Restart the

Quote:
Quote:
Restart the phone

Doesn't work... and I don't even have to restart it as, well, that's the other issue that the phone reboots about 2-3x a day when BOINC is running E@H.

I just checked it and it was off again. When I rebooted and went back into E@H, all workunits again running a few seconds and resetting to zero. A whole week of running and progress is still close to zero and not a single work unit completed.


Might have guessed, actually I did guess and wasn't surprised:

Quote:
Qualcomm Snapdragon 400


My running on my Qualcomm Snapdragon S4 powered HTC One S has hinted that there's something not fully compatible with Qualcomm processors and running Boinc apps, not sure what it is, most probably power or load management, or how apps are scheduled,
The only Boinc apps that work without erroring often or causing validate error are the Albertathome apps, tried Seti, PrimeGrid and Asteroids and Einstein, the first three get frequent SIGSEGV: segmentation violations, the Einstein app validate errors,
But even then the Albert apps aren't fully error free, the HTC One S wasn't maintaining a full charge last week, and even those apps were erroring, perhaps that hints at a Boinc api problem too,
then there's a very intermittent no progress problem, where the process got signal 9, and restarts, then gets signal 9 and restarts, I see this often on the HTC One S, But very rarely on my 2012 Nexus 7 (Nvidia Tegra CPU),
the HTC One S is doing it at the moment (I did report it to the Boinc for Android list, But since I was the only one that reported it they didn't take any notice):

Quote:
Thu Nov 27 21:27:44 GMT 2014|Albert@Home|[task] task_state=EXECUTING for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 from start
Thu Nov 27 21:27:44 GMT 2014|Albert@Home|[task] ACTIVE_TASK::start(): forked process: pid 14300
Thu Nov 27 21:27:44 GMT 2014|Albert@Home|[task] task_state=UNINITIALIZED for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 from handle_exited_app
Thu Nov 27 21:27:44 GMT 2014|Albert@Home|[task] process got signal 9
Thu Nov 27 21:27:44 GMT 2014|Albert@Home|[task] Process for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 exited, status 9, task state 1
Thu Nov 27 21:26:49 GMT 2014|Albert@Home|[task] task_state=EXECUTING for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 from start
Thu Nov 27 21:26:49 GMT 2014|Albert@Home|[task] ACTIVE_TASK::start(): forked process: pid 13946
Thu Nov 27 21:26:49 GMT 2014|Albert@Home|[task] task_state=UNINITIALIZED for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 from handle_exited_app
Thu Nov 27 21:26:49 GMT 2014|Albert@Home|[task] process got signal 9
Thu Nov 27 21:26:49 GMT 2014|Albert@Home|[task] Process for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 exited, status 9, task state 1
Thu Nov 27 21:26:48 GMT 2014|Albert@Home|[task] task_state=EXECUTING for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 from start
Thu Nov 27 21:26:48 GMT 2014|Albert@Home|[task] ACTIVE_TASK::start(): forked process: pid 13917
Thu Nov 27 21:26:48 GMT 2014|Albert@Home|[task] task_state=UNINITIALIZED for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 from handle_exited_app
Thu Nov 27 21:26:48 GMT 2014|Albert@Home|[task] process got signal 9
Thu Nov 27 21:26:48 GMT 2014|Albert@Home|[task] Process for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 exited, status 9, task state 1
Thu Nov 27 21:26:29 GMT 2014|Albert@Home|[task] task_state=EXECUTING for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 from start
Thu Nov 27 21:26:29 GMT 2014|Albert@Home|[task] ACTIVE_TASK::start(): forked process: pid 13797
Thu Nov 27 21:26:29 GMT 2014|Albert@Home|[task] task_state=UNINITIALIZED for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 from handle_exited_app
Thu Nov 27 21:26:29 GMT 2014|Albert@Home|[task] process got signal 9
Thu Nov 27 21:26:29 GMT 2014|Albert@Home|[task] Process for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 exited, status 9, task state 1
Thu Nov 27 21:26:11 GMT 2014|Albert@Home|[task] task_state=EXECUTING for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 from start
Thu Nov 27 21:26:11 GMT 2014|Albert@Home|[task] ACTIVE_TASK::start(): forked process: pid 13692
Thu Nov 27 21:26:11 GMT 2014|Albert@Home|[task] task_state=UNINITIALIZED for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 from handle_exited_app
Thu Nov 27 21:26:11 GMT 2014|Albert@Home|[task] process got signal 9
Thu Nov 27 21:26:11 GMT 2014|Albert@Home|[task] Process for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 exited, status 9, task state 1
Thu Nov 27 21:26:10 GMT 2014|Albert@Home|[task] task_state=EXECUTING for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 from start
Thu Nov 27 21:26:10 GMT 2014|Albert@Home|[task] ACTIVE_TASK::start(): forked process: pid 13679
Thu Nov 27 21:26:10 GMT 2014|Albert@Home|[task] task_state=UNINITIALIZED for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 from handle_exited_app
Thu Nov 27 21:26:10 GMT 2014|Albert@Home|[task] process got signal 9
Thu Nov 27 21:26:10 GMT 2014|Albert@Home|[task] Process for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 exited, status 9, task state 1
Thu Nov 27 21:25:35 GMT 2014||log flags: file_xfer, sched_ops, task, task_debug
Thu Nov 27 21:25:35 GMT 2014||Config: report completed tasks immediately
Thu Nov 27 21:25:35 GMT 2014||Not using a proxy
Thu Nov 27 21:25:35 GMT 2014||Re-reading cc_config.xml
Thu Nov 27 21:12:28 GMT 2014||Resuming network activity
Thu Nov 27 21:12:28 GMT 2014||Resuming computation
Thu Nov 27 21:10:01 GMT 2014||Suspending network activity - user request
Thu Nov 27 21:10:01 GMT 2014||Suspending computation - user request
Thu Nov 27 21:10:00 GMT 2014|SETI@home Beta Test|task 10fe09ab.19922.7025.438086664203.16.28.vlar_0 resumed by user
Thu Nov 27 21:09:54 GMT 2014|Albert@Home|Starting task p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2
Thu Nov 27 21:09:53 GMT 2014|SETI@home Beta Test|task 10fe09ab.19922.7025.438086664203.16.28.vlar_0 suspended by user
Thu Nov 27 20:51:43 GMT 2014||Resuming network activity
Thu Nov 27 20:51:43 GMT 2014||Resuming computation
Thu Nov 27 20:45:43 GMT 2014||Suspending network activity - user request
Thu Nov 27 20:45:43 GMT 2014||Suspending computation - user request
Thu Nov 27 19:58:23 GMT 2014|Albert@Home|Finished download of p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873.bin4
Thu Nov 27 19:58:21 GMT 2014|Albert@Home|Started download of p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873.bin4
Thu Nov 27 19:58:19 GMT 2014|Albert@Home|Scheduler request completed: got 1 new tasks
Thu Nov 27 19:58:01 GMT 2014|Albert@Home|Requesting new tasks for CPU
Thu Nov 27 19:58:01 GMT 2014|Albert@Home|Reporting 1 completed tasks
Thu Nov 27 19:58:01 GMT 2014|Albert@Home|Sending scheduler request: To report completed tasks.

Claggy

Claggy
Claggy
Joined: 29 Dec 06
Posts: 560
Credit: 2694028
RAC: 0

RE: RE: I'm running into

Quote:
Quote:
I'm running into a bit of a problem, where the tasks run for 3 minutes, then seem to reset themselves at 0 min 0 sec crunch time, with completion never going over 0.0% complete. It's got itself looped indefinitely in restarting the tasks.

Having the same issue with this host. The tasks don't even run at all unless I expand them in the Tasks window. Then the Elapsed Time starts, but it goes back to 0:00 after a second or two. After numerous retries, it starts counting up but doesn't get far. I have one task that keeps going back to 00:00 after a few seconds, another resets to 01:08, another to 02:26 etc. So this host has zero completion after over a week. Had a RAC of about 150 with SETI@Home and no issues with task completion.

Motorola Moto G XT1032, updated to Android 4.4.4 kernel 3.4.42.

All your Wu's are erroring, Check the stderr of your errored tasks:

http://einsteinathome.org/host/11687171/tasks&offset=0&show_names=1&state=0&appid=0

Maximum disk usage exceeded

Try increasing the Max used storage on the device, and leave the min spare storage low, (Mine are 90% and 0.1GB), Boinc for Android only uses local preferences, the Web computing preferences are not used.
(If you check the computing preferences of a project with recent server code like Seti, the computing preferences page has a 'These preferences do not apply to Android devices.' mention)

If increasing the diskspace doesn't cure the errors, then try the Albertathome app.

Claggy

Claggy
Claggy
Joined: 29 Dec 06
Posts: 560
Credit: 2694028
RAC: 0

A heads up if no one is

A heads up if no one is watching the boinc_projects mailing list:

http://lists.ssl.berkeley.edu/mailman/private/boinc_projects/2014-November/011225.html

Quote:

Android apps (if your project has them, read this!)â€

At some point, Google introduced the notion of
"position-independent executable" (PIE) native-mode programs:
http://stackoverflow.com/questions/24818902/

Support for PIE programs was added in Android 4.1.
Starting with Android 5.0 (which is now shipping on some devices)
native-mode applications *must* be PIE.
This means that your current Android apps will fail on Android 5.0.

(BTW, the BOINC client is a native-mode app; we've built a PIE version
of it, which seems to work on Android 5.0).

Building PIE versions of apps just requires adding a couple of compile flags; see
http://boinc.berkeley.edu/trac/wiki/AndroidBuildApp#Position-independentexecutablesPIE

So, I recommend that you do the following:

- build PIE versions of your applications
- deploy the new versions, with a plan class that sends them
only to Android 4.1+ clients
- if you like, deploy your old non-PIE app versions with a plan class
that sends them only to pre-4.0 clients.
Note: pre-4.0 clients account for less than 10% of the pool.

Currently, Android clients report their Linux kernel version,
not their Android version.
I believe that Android 4.1 uses Linux 3.0.31,
while earlier Androids use earlier Linux.
So, if you use XML plan class specs, use
30031
for your PIE version.

Sorry for the late notice; we found out about this ourselves only a few days ago.

-- David

Claggy

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3522
Credit: 686219439
RAC: 552581

We are currently seeing a

We are currently seeing a great lot of Android task failures which have something like this at the end of the log output:

[12:51:37][11541][INFO ] Checkpoint committed!
[12:52:41][11541][INFO ] Checkpoint committed!
error: only position independent executables (PIE) are supported. 

So what is happening is that the app used to run fine but now fails with said error message.

The only explanation I have is that these failures happen on phones that are just now being updated to Android 5. The tasks that were running or that were waiting to run in the work-cache of BOINC were received at the time before Android 5 was installed and at that time they worked ok, but after the update they will fail because of the new Android 5 requirements outlined in the message above by Claggy.

Since a few days we do have an app that is Android 5 compliant, so once all the "old" tasks have errored out, newly fetched task should run ok.

On Monday I'll try to have BOINC deliver the Android 5 "PIE" compliant version to all devices that can actually run it (Android 4.1+) and not just to Android 5 devices, which should make the transition a bit smoother from now on.

HBE

Claggy
Claggy
Joined: 29 Dec 06
Posts: 560
Credit: 2694028
RAC: 0

RE: On Monday I'll try to

Quote:
On Monday I'll try to have BOINC deliver the Android 5 "PIE" compliant version to all devices that can actually run it (Android 4.1+) and not just to Android 5 devices, which should make the transition a bit smoother from now on.


Is the 1.46 (NEONPIE) a rebuild of the 1.43 (NEON) app that's in use here, or the 1.44 (NEON) app that's in use at Albert?

I somehow suspect my Android 4.1.1 powered HTC One S is going to continue it's validate error run here it had with the 1.43 (NEON) app, now with the 1.46 (NEONPIE) app,
It has continued to crunch the 1.44 (NEON) app at Albert without major problem, the one 1.46 (NEONPIE) workunit it did there ended up validate error:

http://albertathome.org/workunit/674497

http://albertathome.org/host/9756/apps
[pre]Binary Radio Pulsar Search 1.44 arm-android-linux-gnu (NEON)
Number of tasks completed: 617
Max tasks per day: 91
Number of tasks today: 2
Consecutive valid tasks: 60
Average processing rate: 0.51 GFLOPS
Average turnaround time: 1.47 days[/pre]

Claggy

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3522
Credit: 686219439
RAC: 552581

It is a recompile of the NEON

It is a recompile of the NEON app at E@H. The one on A@H, was, IIRC, exactly the same except it used a different version of FFTW, which turned out to be slower on almost all devices, therefore it never made it to E@H. I'll keep an eye on this, so far the NEONPIE version seems to run ok. Puzzling.

HB

Claggy
Claggy
Joined: 29 Dec 06
Posts: 560
Credit: 2694028
RAC: 0

RE: It is a recompile of

Quote:

It is a recompile of the NEON app at E@H. The one on A@H, was, IIRC, exactly the same except it used a different version of FFTW, which turned out to be slower on almost all devices, therefore it never made it to E@H. I'll keep an eye on this, so far the NEONPIE version seems to run ok. Puzzling.

HB

I've set it loose on Einstein again:

Computer 9721755

Claggy

Dave
Dave
Joined: 31 Oct 10
Posts: 5
Credit: 306750
RAC: 0

Hi Discovered Android

Hi

Discovered Android client so having a play with benchmarking a bit of E@H.

Is it possible for the computer name to be the device name, not the hex name returned currently? I see this was mentioned nearly 2 years ago.

Regards
Dave

Yavanius
Yavanius
Joined: 1 Jan 15
Posts: 17
Credit: 4726965
RAC: 13113

RE: Is it possible for the

Quote:
Is it possible for the computer name to be the device name, not the hex name returned currently? I see this was mentioned nearly 2 years ago.

The naming of Android_ABCD1234 is caused by BOINC. For some reason when they designed the Android client, they designed it like that instead of pulling the info from the device (such as you might see from benchmark programs) or preferably allowing you to name it yourself.

If you run NativeBOINC, you find you can actually set your device name. Regrettably, there's been no support for it in a couple of years although some people still run it.

Yavanius
Yavanius
Joined: 1 Jan 15
Posts: 17
Credit: 4726965
RAC: 13113

I posted this originally over

I posted this originally over at Albert@home thinking it was an issue there, being the beta project, but this issue upon further testing affects the current Einstein Android client too.

https://albertathome.org/content/amazon-fire-hd7-android-will-not-run-more-one-task-concurrently

On my Amazon Fire HD 7: https://albertathome.org/host/13576

I was having an issue with Albert@home and WCG where the WUs would get stuck in a short repeating cycle in the middle of processing a WU. Basically it would keep flipping back 10 seconds roughly, hit the same point and back up again. Pausing the client and restarting it wouldn't cure it. Force stopping seems to help although it seemed most of the time I seem to have had to restart the tablet.

That was on 7.4.14, which was in the Amazon store (a newer version supposedly was uploaded but it never showed up). I went and sideloaded 7.14.41 within the last couple days and it seemed all was well initially then I saw the same issue, although the cycle seems closer to 30 seconds or more now. I did not notice any issues with WCG being affected.

After a little more playing around I discovered when running more one WU at the same time this issue occurs. At the moment I have two WUs going. I suspended one and the other one proceeds just fine. I have a Fire HDX I 8.9 (3rd gen) that runs it just fine as well as other Android devices. If I try to get both to run, in very short time this issue repeats itself.

Another thing I had noted on 7.4.14 shortly before updating the client, was that I had some WUs were registering as 100% yet 2-3 hours later they were still running. I finally aborted the tasks. I also noted I had some computation errors (I've never managed to get an Albert WU to finish previously and the problem still existed with .41) which I don't know are related. I do know on my HDX that when running while the tablet is active that some apps didn't play nice with BOINC and would cause WUs to result in computation errors when causing BOINC to suspend due to the CPU utilization. However, I haven't had that issue in a whiles which makes me think that it was a problem with the apps (one a game and the other a ported web browser).

UPDATED INFO: Einstein/Albert WUs don't like it when other WUs are working too. (At first it seemed if I ran one of each, things were just fine but later I discovered the problem had started up again.) If I use just a single core, WUs seem to run just fine. However, as I add more cores, the problem worsens. At four cores, WUs get stuck in a 2 second cycle. The interesting and odd thing is if I drop down the number of cores, the WUs will run normal for a whiles and then eventually end up in that cycle again. Everything else works fine though...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.