Mine does not in 99% of the cases. Sometimes am the whole day on the road, come back, connect to juice and hit 'Resume', and it goes on to the minute where it left off, and valid. Last trip, put it in the car, navigator on and waited for 100% charge, then hit resume and almost whole trip of 12 hours it did 'mobile' computing [Sits front of the airco vent with an Tetrax Xway magnetic seat], Wifi specifically disabled in the OS. Why this unloading happens to one and not the other is unknown to me, and frankly we have discussed this enough times and tried to determine why, but found no root cause. Very possibly it's short of RAM [OET requirements are not high though], no 'swap file' concept that I'm aware off. When the device needs RAM it will kick the oldest idle out [A guess], or choke.

On one device I literally watched as the CPU time counted up and then reset back to a former time repeatedly. I had now idea how long it was doing this. I observed this serveral times with different jobs. Without any logs to figure out what it was doing I just gave up and and unistalled from that device.

Another old Samsung device I have has everything de-installed except BOINC and it "appears" to work. The server results stats tell me it is turning in a few WU every day, but 7-44 daily CPU hours for a 2-core processor running 24x7 is far less than 50% of what it should be doing. I should pull the plug on that one too.

Cheers

Just to be sure, the *observed* 100% state can by as long as 9 hours. Why? Probably the program makes an estimate of progress at start, then writes a checkpoint every so much time passed, but then when the computation proofs non-linear in some way, the overage is not checkpointed until finished.

Notably, I've tested this and on interruption the ones subjected to the test reverted to 99.9%, quickly moved to 100% and the same... hours on end in this state, *but*, they do finish properly and validate.

Remember, this was originally an app [based on AD Vina] without any checkpointing, then with lots of programming effort forced to write one at those 12.5% intervals. Opt-out or let it run it's course... hardly costing pennies.

In the news yesterday, the disease is very very difficult to eradicate... it can return out of nowhere [hiding in human tissue like AIDS does too], so any pennies help is lots appreciated. Maybe your device finds the magic compound. :O)

--//--

[Unfortunately], not. The checkpointing is hardcoded to just those 8 over the full runtime of a task.

The piece about tasks unloading quite quickly is reported by more, but I ain't seeing it. Can be away all day and use the tablet, then when back plug in and resumption from where it got suspended [manually to stop the battery eating]. Gaming in the house and leaving BOINC continue till 30% charge, plug in and resume without loss. Very occasionally it drops back, but why, no idea.

BTW did discover this android has a .5GB storage allocation in the /cache location of which 10mb is used, never seen more. Similar there's /storage of .911GB, always 100% free, but that same number shows up for various folders such as /data, /dev and /mnt so it looks they're reporting the same [shared] space from root.

Hmm, I am not sure if this is helpful, but I noticed that my OET workunits did not restart when I disabled pause when screen is on option for BOINC. I tried a test where I only set one core to run at 100% and that would not pause. The workunit finished from start to finish and then completed. I am thinking of just using that so that I would be able to constantly have it run in the background. I think me using my phone kept suspending it and thus making it go to the previous check point.

Did anyone else try this?