wiki:AndroidBoinc

  1. BOINC on Android
    1. History and people
    2. Resources
    3. Current plans for BOINC on Android
      1. Goals
      2. Architecture
      3. Runtime system
      4. GUI
      5. Building apps
      6. Packaging
      7. Technical issues

BOINC on Android

Because of the increasing power of mobile computers (e.g. smart phones and tablets) and their large population (~5 billion) we're interested in using them for volunteer 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.

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 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 can potentially also control a local client.

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 ​Native BOINC for Android; was released. This consists of modified versions of the BOINC client (based on 6.10.58) and AndroBOINC, together with Android versions of several applications.

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:

Current plans for BOINC on Android

Goals

  • 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.
  • The client can download apps from projects or use the anonymous platform mechanism.
  • 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.

Architecture

The proposed 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. However (as proposed by Peter Hanappe) for Android it may be better to bundle them in the same program. The BOINC client would be included as a library, and would run in a separate thread. We'd still use the TCP-based GUI RPC mechanism (this eliminates the synchronization issues that would arise if we had the GUI call client functions directly).

Runtime system

On Win/Mac/Linux, apps are run in separate processes, which communicate with the client via shared-memory message-passing. Android doesn't let apps download and run other programs, so we can't use this approach.

However, Android lets apps download and dynamically link .so files. So the plan is that apps will be deployed as .so files that combine the application (main()) with an Android version of the BOINC API. This API includes an entry point app_start, which does initialization and then calls main().

The client will run apps as follows:

  • Link the .so file using dlopen() if it's not already linked.
  • Create a PTHREAD_APP_INFO structure, which contains control and status info.
  • Create a pthread, running the .so's app_start function, and passing to it a pointer to the PTHREAD_APP_INFO structure.

Process control operations (suspend, resume, quit, abort, check completion) will be implemented differently than other platforms. For example, the client will suspend an app by setting a flag in the PTHREAD_APP_INFO and sending the thread a SIGUSR1 signal. The handler for this signal will sleep until the flag is cleared.

This architecture has some drawbacks, of course:

  • If any app crashes or exits, so does the entire client. (We may be able to minimize this risk by installing signal handlers in the app thread.)
  • If an app trashes memory, it may crash the entire client.
  • For now, we can't support multithreaded apps.

TO BE DETERMINED: can the client map in the .so file, then fork()? That would allow apps to be run in separate processes.

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. AndroBOINC's GUI is probably a bit too "techie". So we plan to implement a new GUI, in Java, using the Android toolkit.

On Android, some functions (e.g. checking CPU temperature and battery life) are available in Java but not C++. So we'll do these things in the GUI, and create GUI RPCs for passing the info to the client.

Building apps

We'll provide a cookbook for cross-compiling apps on Linux.

Packaging

It's desirable that what users see in Android app stores is 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).

Technical issues

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.

Last modified 12 years ago Last modified on Jun 1, 2012, 2:18:51 PM