BOINC on Android

History and people

Jeff Eastlack (then of Freescale) has been working on getting SETI@home (and other scientific programs) to run fast on ARM processors since 2007. As of 2011 he had SETI@home doing about 1 GFLOPS on the latest Freescale processor.

In 2008 a team led by Oded Ben-Dov ported SETI@home and a simplified BOINC client to Java on Android. This was a proof of concept but is not the right long-term approach, as Android is now able to run native-mode programs.

At about the same time, Peter Hanappe from Sony Research wrote, in C++, a simplified BOINC client called BOINCLite, which is able to handle only 1 project attachment and 1 job at a time. We considered this as a basis for BOINC on Android but decided it was too limited.

In 2009, Michael Black (a CS prof at American Univ) wrote a prototype Python-based "BOINC on an iPhone".

In 2011 someone named Palo M. implemented AndroBOINC, a BOINC GUI for Android: ​http://code.google.com/p/androboinc/ AndroBOINC is intended to control BOINC clients running on remote hosts, but in principle it could control a local client. I haven't looked at it.

At the 2011 BOINC Workshop, Keith Uplinger, Peter Hanappe and Michael Tarantino experimented with Android and wrote up instructions for building Android apps on Windows.

In 2011, Carl Christensen and Peter Hanappe independently built the BOINC client (and the various libraries it uses) on Android.

In 2012 Janus Kristensen wrote a document about the battery and energy impacts of computing on phones.

In March 2012 I learned about ​Native BOINC for Android; I'm currently investigating this.

Architecture

As of now, the preferred architecture is based on the standard BOINC client, so that we can allow multiple attachments, multiple jobs running in parallel, and queued jobs.

On Win/Mac/Linux, the GUI and the client are separate processes that communicate over a TCP connection. However (as proposed by Peter Hanappe) for Android it's probably better to bundle them in the same program. The BOINC client would be included as a library, and would run in a separate thread.

What about the GUI?

The current BOINC GUI (the Manager) is implemented using WxWidgets, for which no port to Android exists. Also, though the Manager's "simple view" is similar to what we might want on Android, it's not quite right.

So the plan is to implement a new GUI, in Java, using the Android toolkit, which will communicate with the client using the existing GUI RPC mechanism. (Note: this mechanism currently uses a TCP connection, but it could be modified to use Unix pipes or some other IPC mechanism).

We maybe able to use some or all of AndroBOINC; I've contacted its author asking about the status of its source code.

Security

Carl tells me that Android doesn't let apps download and execute code. We need to investigate this. If so, we could

• Convince Google to provide a workaround for us (unlikely).
• Switch to a model where volunteers download an app that includes (as libraries) all the app versions of all projects. This is non-ideal but it wouldn't be the end of the world.

Peter thinks it may be possible for the client to download .so files and dynamically link them with ldopen(). If so apps could be packaged as .so files. Also, in this case it would be possible to run the apps in threads within the client; this would avoid reported problems with fork().

Building apps

What's the easiest way for projects to compile existing apps for ARM/Android?

Packaging

I think that what users see in Android app stores should be branded with a particular project's identity, rather than a generic BOINC identity. When the volunteer first runs the app they're prompted for email/password on that project (this could be made optional, in which case we'd create an anonymous account for them).

Resources

Source code:

• Carl's code and instructions for building the client, libssl and Curl is here.
• Peter's script for building the client and libraries is in the BOINC repository here.
• Jeff Eastlack's instructions for building apps for ARM (both cross-compile and native) are ​here.

Documents:

• Jeff Eastlack's MS Thesis, Extending Volunteer Computing to Mobile Devices (.pdf)
• ​Memory management in Android

Project plan

• Standardize on the code and scripts for building the BOINC client on Android (based on Peter and Carl's work). Put these files in the BOINC repository.

• Get the scripts/makefiles for building SETI@home for Android into the SETI@home repository, and make an Android/ARM app version available on SETI@home. (Jeff, Eric)

• Persuade some other projects to build Android/ARM apps.

• Create a template for making a project-specific Android app, with instructions for adding it to app stores.