IcedRobot

Project Proposal Guidelines

This document describes a list of guidelines that can help you in preparing your application form for the Summer of Code 2011. We really suggest you to give a look to the following resource also, as most of this document is based on these:

• http://summer.cs.pdx.edu/propose

Requirements

• Please, follow all the guidelines and rules defined by Google, as these are the most important requirements.

• A program like the Summer of Code can be very difficult to manage, especially for students in the European Community whose summer schedule is usually later than that in the United States, this is why we recommends that students do not work on other projects outside the GSoC, or limit the time spent on these project to a maximum of 10 hours per week, depending on the task being proposed.

• We require students to get in touch with IcedRobot mentors on a regular basis. We have various communication channels to enable that, like IRC and the so please, be sure to have stable Internet access during the whole project.

• All applicants must be reasonably fluent in the Java and C programming languages, and have strong knowledge of build tools like make. Knowing the Android platform is also helpful, and may be mandatory depending on the project proposed. The GSoC is a mean of learning and gaining experience, and our mentors will do everything to help the student, but a student must start from a solid basis already to have a chance to successfully complete the program.

Proposal Outline

The guidelines offered by the GSoC FAQ page are generally enough for us, the FAQ provides two example, also linked here for reference: http://www.booki.cc/gsocstudentguide/_v/1.0/proposal-example-2/ and http://www.booki.cc/gsocstudentguide/_v/1.0/proposal-examples/

Ideas

IcedRobot consist of few different projects. Currently, we are still working on decoupling the Dalvik VM from the custom Android Linux kernel and we are writing a Dalvik to Java compiler, that is responsible to translate the dex bytecode to java. We are also writing a tool, called Ika, that help us to manage our complex workflow.

• Daneel
  • There are many areas were we can use help, and given the nature of the project is hard to identify a specific idea, but in general work on Daneel includes helping to write the DEX parser, together with complete unit tests and write the custom Classloader that is responsible to map the java byte code from dex

• Build machinery and Ika
  • We need help in designing the build machinery. Currently, IcedRobot uses a combination of ant and CMake to compile the source files and to create the share libraries that are needed, it would be nice to be able to replace most of this infrastructure with plugins written for Ika, and make easy to parallelise the build procedure. The dependencies that we need to track are quite straightforward, so part of this task would be to write a custom make-like tool that can take the compiler definitions, a predefined set of common build options and the source files to compile.
  • Ika is already a very flexible tool and is currently used to operate on the git and mercurial repositories. Ika is also able to apply the git patch queues by using guilt internally, but we would like to get rid of guilt and to extend Ika to also handle directly the patch queues.
• Porting
  • IcedRobot aims to port Dalvik on platforms where Dalvik is probably not intended to run out of the box, like QNX and OSX. We need help in porting the class library and the native code to those platform and ensure that Dalvik can still be run. We also need to be sure that the Dalvik Class library works as expected under Daneel and the JDK.