JPPF Issue Tracker
Please log in to bookmark issues
CLOSED  Feature request JPPF-136  -  Android node
Posted Apr 13, 2013 - updated Sep 12, 2015
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Feature request
  • Status
  • Assigned to
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
  • Owned by
    Not owned by anyone
  • Category
  • Resolution
  • Priority
  • Targetted for
    icon_milestones.png JPPF 5.1
Issue description
This is about enabling submitting jobs from and Android device, and an Android version of a JPPF node.

Comment posted by
Aug 05, 04:19
The possibility to have offline nodes (see comments in Feature request JPPF-11 - Ability for the nodes to work offline) opens interesting possibilities for Android devices.

However, there is currently one hiccup: the latest version of android does not suport the JDK 7 language features and APIs. I don't really want to have to maintain 2 separate code bases for the Java and Android implementations of the node, common and server modules, so I propose that we postpone this feature until Android updates its JDK support, pending further news from Google. Thus I am setting this issue as targeted for 'JPPF Vision'.
Comment posted by
Mar 11, 20:18
Update: as of Android 4.4 (KitKat), Java 7 is supported, so this feature is on.

I also found this article on dynamic class loading with Dalvik, it looks like it may be possible to implement dynamic class loading as well.
Comment posted by
Mar 21, 03:47
I just committed a first version of an Android node. It works as an offline node and can handle dynamically loaded jar files with claases in dex format. The biggest problem was that* and* are not part of the Android SDK, so all static dependencies to thee APIs had to be removed or abstracted by using reflection. What' really amazing is the compatibility of serialized objects between Oracle's and Android's JVM. The Android developers did a great job of it.
Comment posted by
Mar 21, 04:13
Need to add a UI with at least two parts:

1) There should be a way to provide visual feedback while the node is running, the Android equivalent for what the standard node screensaver does. This means a customizable UI with an integration with node events: notifications from the tasks and node life cycle events.

2) A settings/preferences UI is needed as well, so the node can be configured properly while complying with the Android standards. In particular, there's a need to configure which servers the node can connect to. Thus, it makes sense to have a node connection strategy associated with a settings UI, among others.
Comment posted by
Mar 24, 09:09

Security Considerations  ⇑ top

The situation  ⇑ top

  • as of the Android security model, the permissions must be granted at the time the node is installed
  • security matters on mobile devices appear to be much more sensitive than on PCs, servers, etc...
  • what the Android node is designed for - dynamic loading of arbitrary code for distributed execution - can be perceived as a security issue
  • the only permission the node cannot do without is INTERNET permission: it has to connect to a JPPF server to fetch jobs and return the execution results

Possible impact and questions  ⇑ top

  • if the node is limited to INTERNET permission, then functionality will be drastically limited (no access to GPS, location, file system, etc...). It will still be able to do pure computations and access the network. What can we do about that?
  • the node security needs to be tightened - how?
  • this can have a huge impact if we choose to distribute the android node via the play store or another appstore. How to resolve the problem of threat perception?

Suggestions and proposals for solutions  ⇑ top

  • limitations of functionality: we need to provide a source dsitribution that can be built easily and which allows the user to add permissions. Permissions are stored statically in the Android manifest file.
  • is explaining clearly "what the node does and that if any doubt about security remains it should not be installed" sufficient?
  • I don't think that securing the network communications with SSL/TLS will be sufficient: how to prevent unauthorized code sent by an unauthorized client from executing on the node? The pb is that SSL is between node and server and between client and server but not between client and node. So we need a way to verify that the code in a dex jar sent with a job can be safely loaded