Changes between Version 18 and Version 19 of AndroidBoinc


Ignore:
Timestamp:
Jun 1, 2012, 2:18:51 PM (12 years ago)
Author:
davea
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • AndroidBoinc

    v18 v19  
    33= BOINC on Android =
    44
    5 Because of the increasing power of mobile computers (e.g. smart phones)
     5Because of the increasing power of mobile computers (e.g. smart phones and tablets)
    66and their large population (~5 billion)
    7 we're interested in using them for scientific computing.
     7we're interested in using them for volunteer computing.
    88
    99Apple iOS has a number of technical and legal barriers.
    … …  
    1414To avoid using up cell-phone data transfer quotas,
    1515we plan to do network communication only over wifi.
    16 
    17 In terms of software, our goals include:
    18 
    19  * A BOINC client and GUI that we (BOINC project staff)
    20    can cross-compile on Linux, and can debug using an Android emulator.
    21  * The source code for both of these in the BOINC repository,
    22    with the copyright assigned to UCB.
    23  * The client can download apps from projects or use the anonymous platform mechanism.
    24  * A "cookbook" set of instructions allowing existing C++ applications
    25    to be cross-compiled on Linux for Android/ARM.
    26  * Scripts for creating an Android installer for the generic BOINC client,
    27    using the BOINC graphical identity.
    28  * Scripts for creating an Android installer for a package that includes the
    29    BOINC client configured to attach to a particular project,
    30    using the graphical identity of that project.
    31  * Cookbooks for putting these installers on several Android app stores.
    3216
    3317== History and people ==
    … …  
    4731In 2009, Michael Black (a CS prof at American Univ) wrote a prototype Python-based "BOINC on an iPhone".
    4832
    49 In 2011 someone named Palo M. implemented AndroBOINC, a BOINC GUI for Android: http://code.google.com/p/androboinc/
     33In 2011 Palo M. implemented AndroBOINC, a BOINC GUI for Android: http://code.google.com/p/androboinc/
    5034AndroBOINC is intended to control BOINC clients running on remote hosts,
    51 but in principle it could control a local client.
    52 I haven't looked at it.
     35but can potentially also control a local client.
    5336
    5437At the 2011 BOINC Workshop, Keith Uplinger, Peter Hanappe and Michael Tarantino
    … …  
    6144In 2012 Janus Kristensen wrote a [wiki:BOINConPhones document about the battery and energy impacts of computing on phones].
    6245
    63 In March 2012 I learned about
     46In March 2012
    6447[https://github.com/matszpk/native-boinc-for-android Native BOINC for Android];
    65 I'm currently investigating this.
    66 
    67 == Architecture ==
    68 
    69 As of now, the preferred architecture is based on the standard BOINC client,
    70 so that we can allow multiple attachments, multiple jobs running in parallel,
    71 and queued jobs.
    72 
    73 On !Win/Mac/Linux, the GUI and the client are separate processes that
    74 communicate over a TCP connection.
    75 However (as proposed by Peter Hanappe) for Android it's probably better
    76 to bundle them in the same program.
    77 The BOINC client would be included as a library,
    78 and would run in a separate thread.
    79 
    80 == What about the GUI? ==
    81 
    82 The current BOINC GUI (the Manager) is implemented using !WxWidgets,
    83 for which no port to Android exists.
    84 Also, though the Manager's "simple view" is similar to what
    85 we might want on Android, it's not quite right.
    86 
    87 So the plan is to implement a new GUI, in Java, using the Android toolkit,
    88 which will communicate with the client using the existing GUI RPC mechanism.
    89 (Note: this mechanism currently uses a TCP connection, but it could be modified
    90 to use Unix pipes or some other IPC mechanism).
    91 
    92 We maybe able to use some or all of AndroBOINC;
    93 I've contacted its author asking about the status of its source code.
    94 
    95 == Security ==
    96 
    97 Carl tells me that Android doesn't let apps download and execute code.
    98 We need to investigate this.
    99 If so, we could
    100 
    101  * Convince Google to provide a workaround for us (unlikely).
    102  * Switch to a model where volunteers download an app that includes
    103    (as libraries) all the app versions of all projects.
    104    This is non-ideal but it wouldn't be the end of the world.
    105 
    106 Peter thinks it may be possible for the client to download .so
    107 files and dynamically link them with ldopen().
    108 If so apps could be packaged as .so files.
    109 Also, in this case it would be possible to run the apps in threads
    110 within the client;
    111 this would avoid reported problems with fork().
    112 
    113 == Building apps ==
    114 
    115 What's the easiest way for projects to compile existing apps for ARM/Android?
    116 
    117 == Packaging ==
    118 
    119 I think that what users see in Android app stores should be
    120 branded with a particular project's identity,
    121 rather than a generic BOINC identity.
    122 When the volunteer first runs the app they're prompted
    123 for email/password on that project
    124 (this could be made optional, in which case we'd create
    125 an anonymous account for them).
     48was released.
     49This consists of modified versions of the BOINC client (based on 6.10.58)
     50and AndroBOINC,
     51together with Android versions of several applications.
    12652
    12753== Resources ==
    … …  
    14571   We might want to use this group in the future.
    14672
    147 == Project plan ==
     73== Current plans for BOINC on Android ==
    14874
    149  * Standardize on the code and scripts for building the BOINC client on Android
    150    (based on Peter and Carl's work).
    151    Put these files in the BOINC repository.
     75=== Goals ===
    15276
    153  * Get the scripts/makefiles for building SETI@home for Android
    154    into the SETI@home repository,
    155    and make an Android/ARM app version available on SETI@home.
    156    (Jeff, Eric)
     77 * A BOINC client and GUI that we (BOINC project staff)
     78   can cross-compile on Linux, and can debug using an Android emulator.
     79 * The source code for both of these in the BOINC repository,
     80   with the copyright assigned to UCB.
     81 * The client can download apps from projects or use the anonymous platform mechanism.
     82 * A "cookbook" set of instructions allowing existing C++ applications
     83   to be cross-compiled on Linux for Android/ARM.
     84 * Scripts for creating an Android installer for the generic BOINC client,
     85   using the BOINC graphical identity.
     86 * Scripts for creating an Android installer for a package that includes the
     87   BOINC client configured to attach to a particular project,
     88   using the graphical identity of that project.
     89 * Cookbooks for putting these installers on several Android app stores.
    15790
    158  * Persuade some other projects to build Android/ARM apps.
     91=== Architecture ===
    15992
    160  * Create a template for making a project-specific Android app,
    161    with instructions for adding it to app stores.
     93The proposed architecture is based on the standard BOINC client,
     94so that we can allow multiple attachments, multiple jobs running in parallel,
     95and queued jobs.
    16296
    163 == Common objections ==
     97On !Win/Mac/Linux, the GUI and the client are separate processes.
     98However (as proposed by Peter Hanappe) for Android it may be better
     99to bundle them in the same program.
     100The BOINC client would be included as a library,
     101and would run in a separate thread.
     102We'd still use the TCP-based GUI RPC mechanism
     103(this eliminates the synchronization issues that would arise
     104if we had the GUI call client functions directly).
    164105
    165 '''Power management turns the CPU to low power usage
    166 (1/10 clock rate or slower) when user not active.'''
     106=== Runtime system ===
    167107
    168 '''Reduced battery lifetime if left plugged in all the time.'''
     108On !Win/Mac/Linux, apps are run in separate processes,
     109which communicate with the client via shared-memory message-passing.
     110Android doesn't let apps download and run other programs,
     111so we can't use this approach.
    169112
    170 '''Many cell phone plans have restrictions on data usage.'''
     113However, Android lets apps download and dynamically link .so files.
     114So the plan is that apps will be deployed as .so files that combine
     115the application (main()) with an Android version of the BOINC API.
     116This API includes an entry point '''app_start''',
     117which does initialization and then calls main().
    171118
    172 We'll do communication only over wifi.
     119The client will run apps as follows:
     120 * Link the .so file using dlopen() if it's not already linked.
     121 * Create a PTHREAD_APP_INFO structure, which contains control and status info.
     122 * Create a pthread, running the .so's '''app_start''' function,
     123   and passing to it a pointer to the PTHREAD_APP_INFO structure.
     124
     125Process control operations (suspend, resume, quit, abort, check completion)
     126will be implemented differently than other platforms.
     127For example, the client will suspend an app by setting a flag
     128in the PTHREAD_APP_INFO and sending the thread a SIGUSR1 signal.
     129The handler for this signal will sleep until the flag is cleared.
     130
     131This architecture has some drawbacks, of course:
     132
     133 * If any app crashes or exits, so does the entire client.
     134   (We may be able to minimize this risk by installing signal handlers in the app thread.)
     135 * If an app trashes memory, it may crash the entire client.
     136 * For now, we can't support multithreaded apps.
     137
     138TO BE DETERMINED: can the client map in the .so file, then fork()?
     139That would allow apps to be run in separate processes.
     140
     141=== GUI ===
     142
     143The current BOINC GUI (the Manager) is implemented using !WxWidgets,
     144for which no port to Android exists.
     145Also, though the Manager's "simple view" is similar to what
     146we might want on Android, it's not quite right.
     147AndroBOINC's GUI is probably a bit too "techie".
     148So we plan to implement a new GUI, in Java, using the Android toolkit.
     149
     150On Android, some functions (e.g. checking CPU temperature and battery life)
     151are available in Java but not C++.
     152So we'll do these things in the GUI,
     153and create GUI RPCs for passing the info to the client.
     154
     155=== Building apps ===
     156
     157We'll provide a cookbook for cross-compiling apps on Linux.
     158
     159=== Packaging ===
     160
     161It's desirable that what users see in Android app stores is
     162branded with a particular project's identity,
     163rather than a generic BOINC identity.
     164When the volunteer first runs the app they're prompted
     165for email/password on that project
     166(this could be made optional, in which case we'd create
     167an anonymous account for them).
     168
     169=== Technical issues ===
     170
     171Power management turns the CPU to low power usage
     172(1/10 clock rate or slower) when user not active.
     173
     174Reduced battery lifetime if left plugged in all the time.
     175