wiki:AndroidBoinc

Version 17 (modified by davea, 12 years ago) (diff)

--

BOINC on Android

Because of the increasing power of mobile computers (e.g. smart phones) and their large population (~5 billion) we're interested in using them for scientific computing.

Apple iOS has a number of technical and legal barriers. For now, we're concentrating on Android, which is Linux-based and open-source.

To avoid battery drain, the plan is to do computing only when the device is recharging. During these periods the device typically is on wifi. To avoid using up cell-phone data transfer quotas, we plan to do network communication only over wifi.

In terms of software, our goals include:

  • A BOINC client and GUI that we (BOINC project staff) can cross-compile on Linux, and can debug using an Android emulator.
  • The source code for both of these in the BOINC repository, with the copyright assigned to UCB.
  • A "cookbook" set of instructions allowing existing C++ applications to be cross-compiled on Linux for Android/ARM.
  • Scripts for creating an Android installer for the generic BOINC client, using the BOINC graphical identity.
  • Scripts for creating an Android installer for a package that includes the BOINC client configured to attach to a particular project, using the graphical identity of that project.
  • Cookbooks for putting these installers on several Android app stores.

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. Called BOINCoid, 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:

Communication:

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.

Common objections

Power management turns the CPU to low power usage (1/10 clock rate or slower) when user not active.

Reduced battery lifetime if left plugged in all the time.

Many cell phone plans have restrictions on data usage.

We'll do communication only over wifi.