Android - Processing

http://wiki.processing.org/w/Android

Android
From Processing

Contents
1 About Processing for Android 2 Instructions 3 Download 4 Android Mode 5 Troubleshooting, Discussion, and Known Issues 5.1 Common problems 5.2 Running on a Device 6 Developing for Android 7 Understanding changes to processing.core 7.1 Mouse, Motion, Keys, and Input 7.2 Screen, Orientation, and the size() command 7.3 API Changed, Gone, or Forgotten 8 Loading files, connecting to the internet, and permissions 9 What about Multi-touch, GPS, SMS, Compass? 9.1 Examples 9.2 Contributed Examples 10 Using Eclipse for Development 11 Integrating with other Android code 12 Distributing Apps 12.1 Signing 12.2 Icons 12.3 AndroidManifest.xml

About Processing for Android

The primary goal of this project is to make it foolishly easy to create Android apps using the Processing API. Once you have Processing on your machine (and the Android developer tools), you can simply write a line of code, hit Run (Ctrl-R or Cmd-R), and have your sketch show up in the emulator as a working Android app. Select Run on Device (Ctrl-Shift-R or Cmd-Shift-R) to have it run on an Android device that you have plugged into your machine. That's good stuff! Note that this code is incomplete and contains bugs. It should be considered "beta" quality. Do not use this code while operating heavy equipment. Do not rely on this code for thesis or diploma work, as you will not graduate. Do not use this code if you're prone to whining about incomplete software that you download for free. We currently have no plans to make a version of the development environment (the PDE) that runs on the phone, but that might be fun for you internetpeople to hack together on your own, and amaze us all.

1 of 13

03.06.2012 06:51

Android - Processing

http://wiki.processing.org/w/Android

Instructions
Download and install the Android SDK from here (http://developer.android.com /sdk/index.html) . You do not need the ADT Plugin for Eclipse. However when looking at the Available packages (see the installation guide (http://developer.android.com /sdk/installing.html) ), make sure the following are also installed: Underneath Tools, check the box for Android SDK Platform-tools. The Android SDK Tools item should already be installed. Beneath Android 2.2 (API 8), select SDK Platform and Google APIs by Google Inc. At the right is an image of what it looks like on Mac OS X (current as of November 2011). If any of the items above are missing from the list, use the checkboxes next to Show at the bottom of the window. On Windows, it looks like this (http://wiki.processing.org/images/d/da/Android-sdk-manager-15-windows.png) , and you should also install the Google USB Driver Package under Extras. Linux users also need the USB Driver Package. You can install other versions of the Android API as well, but you must include version 8. You can't install API 10 or 13 or 14 just because it's newer. Also note that these revisions are for the individual "SDK Platforms" (which refer to Android OS versions), which is different from the revision numbers (see the Rev. column in the GUI) on the "Android SDK Tools" mentioned above. Confusing? Yes. Once the Android SDK is installed, use the download links below to grab a version of Processing that includes the new Android mode. In keeping with the spirit of the Processing project, we hope to remove the Android SDK installation step from the download/install process (Issue 203 (http://code.google.com/p/processing/issues/detail?id=203) ). We also hope to no longer require installation of the Google APIs, since we're not using them (Issue 613 (http://code.google.com/p/processing/issues/detail?id=613) ).

Download
These are pre-release versions of the Processing code. When it's ready for prime time, the Android components will be available as a separate download, or added to the main download. Due to significant SDK changes by Google, Processing 2.0a3 requires Android SDK Tools revision 15 (or later).

2 of 13

03.06.2012 06:51

Android - Processing

http://wiki.processing.org/w/Android

Please do not use earlier releases of Processing for Android. Help us out by using the most current release and filing a bug (http://code.google.com/p/processing/issues/entry) if you run into a problem. Do not use the forums to post bug reports, I cannot fix bugs if they only show up on the forum, and I cannot track bugs that are posted there. Note that due to major changes by Google to the Android dev tools, Android mode in Processing 1.5.x no longer works. You must use 2.0a4 for Android development. 2011 11 10 | 2.0 alpha 4 | Windows standard (http://processing.googlecode.com/files/processing-2.0a4windows.zip) or without Java (http://processing.googlecode.com/files/processing-2.0a4-windows-expert.zip) | Mac OS X (http://processing.googlecode.com/files/processing-2.0a4-macosx.zip) | Linux x86 (http://processing.googlecode.com/files/processing-2.0a4-linux.tgz) 2011 11 05 | 2.0 alpha 3 | Windows standard (http://processing.googlecode.com/files/processing-2.0a3windows.zip) or without Java (http://processing.googlecode.com/files/processing-2.0a3-windows-expert.zip) | Mac OS X (http://processing.googlecode.com/files/processing-2.0a3-macosx.zip) | Linux x86 (http://processing.googlecode.com/files/processing-2.0a3-linux.tgz) Read the revisions.txt (http://processing.googlecode.com/svn/trunk/processing/build/shared/revisions.txt) document in the download to find out what's new and old in this release.

Android Mode
To build for Android, select Android from the drop-down box in the toolbar (by default it reads Standard). This places the current editor window into Android mode. To show you that you've now entered a new world, the window will also get a lot more green. The Run and Export features change a bit in Android mode: Run in Emulator - preprocess the current sketch, create an Android project, and run (debug) it in the Android emulator. Run on Device - the same as Run, but run on a device (phone) that's attached by USB. Export Android Project - creates an 'android' folder that contains the files necessary to build an APK using Ant. Export Signed Package - same as export, but creates a signed version of the 'release' build for the market. (not yet implemented, coming soon (http://code.google.com/p/processing/issues/detail?id=222) ) (As of 0193, these are thankfully no longer called Run, Present, Export, and Export Application.)

Troubleshooting, Discussion, and Known Issues

Use this forum (http://forum.processing.org/android-processing) for questions about Processing for Android. Do not put questions in the general questions category, otherwise it's gonna be a confusing mess. A list of known bugs, sorted by priority, can be found here (http://code.google.com/p/processing/issues /list?can=2&q=Android&sort=priority&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary& cells=tiles#) . If you find a bug, please file it here (http://code.google.com/p/processing/issues/entry) , and if possible, tag it
3 of 13

03.06.2012 06:51

Android - Processing

http://wiki.processing.org/w/Android

Component-Android, so that it's routed to the correct location. Please report issues: as much as I'd like to sit over the should of you and the other 30,000 people who will do battle with Processing this week, current laws of physics disqualify me. If it's not in the bugs database, I don't know about it, and it probably won't be fixed. Second, it's much easier for me to mark a bug as duplicate rather than trying to separate a new issue that's been added to an existing bug, so please just file things separately.

Common problems
If you get an error that reads Error: Android Virtual Device 'Processing-Android-7' already exists., select Android SDK & AVD Manager beneath the Processing Android menu, and delete the Processing-Android-7 AVD. It will be automatically re-created the next time you try to run a sketch.

Running on a Device
Before testing your sketch on your device, you must: Turn on "USB Debugging" on your device. Press Menu, select Applications Development, then enable USB debugging. If you are running Windows or Linux, you need additional setup (refer to this page on android.com (http://developer.android.com/guide/developing/device.html) ) to install a special USB driver. We've also had a report that Ubuntu Lucid (10.04) users may want to rename the USB config file 70-android.rules to make it work, but we've not tested that officially.

Developing for Android

The emulator stays running, even after you hit stop. This is because it takes a fortnight to launch the emulator. You don't have that kind of time. We're only supporting Android 2.1 and later. After years of supporting Java 1.1, we're not going to start out this Android effort by supporting an already abandoned (by Google) version of the OS. It's already difficult enough supporting a handful of devices, screen resolutions, and various installed features across just Android 2.1 and 2.2. And it's only going to get worse better. Performance reminds me a lot of Java performance on desktop machines when we first started the project in 2001. Most Processing sketches will benefit significantly from the JIT that arrived with Android 2.2 (Froyo). There are some things that we can speed up, but short of writing everything in native code, we'll be praying for enhancements to the Android platform. Android seems to have a very shallow stack depth, perhaps ~32 calls. As a result, you might get StackOverflowError in code that worked fine with the Java version of Processing. You cannot use .gz files in the data or assets folder, because Android wants to compress the files itself. Accuracy of colors is more limited on Android. Most screens will not be full 24-bit color, which especially shows up with gradients, highly detailed color sketches, or when using a lot of transparency. With gradients, you might see banding of colors, or when using transparency, you might see halos or visual artifacts left behind. These are just mathematical artifacts due to how colors are handled, subject to limitations of the screen.

4 of 13

03.06.2012 06:51

Android - Processing

http://wiki.processing.org/w/Android

Using createFont() (instead of loadFont()) can help improve text quality, particularly with 2D rendering. Use PFont.list() to get a list of available fonts on the system, and select one of those, or include a .ttf or .otf file in the data directory of your sketch. Because all code for Android exists inside packages, any .java files included with your sketch that do not specify a package will be placed into the same package as the main class for your sketch. This breaks the "we won't touch .java files with the preprocessor" rule we have on the desktop side, but the alternatives are truly much worse. We simply don't support packages at this point on the desktop side, so don't get any weird ideas about adding package declarations to your .java files in general. If this bothers you deeply, stop taking yourself so seriously you'll probably be happier using Eclipse for development.

Understanding changes to processing.core

A guide for the excited, hopeful, weary, and confused.

Mouse, Motion, Keys, and Input

For compatability, mouseX and mouseY work similar to the original API, and always contain the most recent mouse position. In addition, the motionX, motionY, pmotionX, pmotionY, and motionPressure variables can be used to track relative motion (the native way Android handles input). Unlike mouseX/mouseY, those variables are also float values.
void draw() { fill(0,60); rect(0,0,width, height); colorMode(HSB); fill(motionPressure*500,motionPressure*500,255); ellipse(mouseX, mouseY, motionX,motionY); }

motionPressure is only updated when the screen is touched. So you will need to set its value to zero to avoid false-touch inputs. The mouseButton variable is not available, for perhaps obvious reasons. Watch out for rollovers. While commonly used in mouse-based interfaces, they don't make any sense for touch interfaces. Lots of sketches (most of them, really) will need to be rewritten for use on Android to make better use of the affordances given by the hardware. To use the virtual keyboard, hold down the MENU key on the device. This is an Android default, but some users might not be familiar with it. The 'back' key works similar to ESC in the desktop version of Processing. (Pressing ESC in the emulator actually emulates hitting the 'back' key, though it may beep at you first.) By default, this will exit your application. If you want to do something smarter, override keyPressed() and set 'key' to 0 so that the key doesn't get picked up by the base class:
void keyPressed() { // doing other things here, and then: if (key == CODED && keyCode == KeyEvent.KEYCODE_BACK) { keyCode = 0; // don't quit by default } }

5 of 13

03.06.2012 06:51

Android - Processing

http://wiki.processing.org/w/Android

The keyEvent and mouseEvent variables are not available. If you want to work with event objects, you'll need to override the key and motion handler. Because onTouchEvent() is called inside the SurfaceView, you'll need to override the Processing-specific touch handler:
public boolean surfaceTouchEvent(MotionEvent event) { // your code here // if you want the variables for motionX/motionY, mouseX/mouseY etc. // to work properly, you'll need to call super.surfaceTouchEvent(). return super.surfaceTouchEvent(event); }

You can use a handler like this to incorporate other libraries that support multitouch or fancier touch event handling than just the basics we currently provide. The key methods work in a similar fashion:
public boolean surfaceKeyDown(int code, KeyEvent event) { return super.surfaceKeyDown(code, event); } public boolean surfaceKeyUp(int code, KeyEvent event) { return super.surfaceKeyDown(code, event); }

These three functions behave a bit differently than their counterparts in java.awt, so make sure you know what you're doing before messing with them. The reason that the variables are not kept around is because the KeyEvent and MotionEvent objects are reused, which means they can't be reused without an expensive clone operation. And because it's so rare that they're used in Processing code, it's better to simply remove them and let advanced users who would otherwise rely on the events to handle the overrides themselves. Constants for ALT, CONTROL, and SHIFT are not present. SHIFT may come back, but the other two don't exist on Android. The LEFT, RIGHT, UP and DOWN constants are mapped to the directional pad. To get the center button on the d-pad, use DPAD (added in revision 0190). Keep in mind that the meaning of UP, DOWN, LEFT and RIGHT can feel different based on the hardware: it might be a trackball, or an optical pad, or even hard buttons.
void keyPressed() { if (key == CODED) { if (keyCode == DPAD) { // user pressed the center button on the d-pad } else if (keyCode == UP) { // user triggered 'up' on the d-pad } else if (keyCode == DOWN) { // user triggered 'down' on the d-pad } else if (keyCode == LEFT) { // user triggered 'left' on the d-pad } else if (keyCode == RIGHT) { // user triggered 'right' on the d-pad } } }

Starting with revision 0190, new constants for the BACK and MENU keys are available, as seen in this example:

6 of 13

03.06.2012 06:51

Android - Processing

http://wiki.processing.org/w/Android

void keyPressed() { if (key == CODED) { if (keyCode == BACK) { // do something here for the back button behavior // you'll need to set keyCode to 0 if you want to prevent quitting (see above) } else if (keyCode == MENU) { // user hit the menu key, take action } } }

Other key codes can be found in the Android documentation for KeyEvent (http://developer.android.com /reference/android/view/KeyEvent.html) . We're including what we feel are the essentials, so as not to pollute the namespace too much. To use one of those constants, you'd do something like the following, replacing KEYCODE_HOME with whatever other key code you wish. For instance, you might want KEYCODE_VOLUME_DOWN, KEYCODE_VOLUME_UP, KEYCODE_CAMERA, etc.
void keyPressed() { // doing other things here, and then: if (key == CODED && keyCode == KeyEvent.KEYCODE_HOME) { // override the home key here } }

Screen, Orientation, and the size() command

The main issue with size() is that it doesn't make a lot of sense on a mobile device. Outside of compatibility with older sketches, there isn't a good reason to set the width and height of a sketch. The size() method operates differently on Android. If no size() method is used, then the sketch is opened and uses the entire display. Use the width and height variables to get the size of the display that's available to you. Then, make calculations in your sketch based on how those are set. Also note that if the phone/device is rotated while the sketch is running, the sketch will reset, and the width and height updated. One reason to use the size() method is to set the renderer to use 3D. (Like the desktop version, the default is the built-in 2D renderer). To use 3D, it's recommended that you use something like:
size(screenWidth, screenHeight, P3D);

Android is even more particular about the "no variables in the size() method" rule found in the desktop version. This is because the size() method is actually removed from the sketch. Behind the scenes, source like:
void setup() { size(screenWidth, screenHeight, P3D); }

will be removed from the source when it's preprocessed, and turned into:
void setup() { } public int sketchWidth() { return screenWidth;

7 of 13

03.06.2012 06:51

Android - Processing

http://wiki.processing.org/w/Android

} public int sketchHeight() { return sketchHeight; } public String sketchRenderer() { return P3D; }

Basically, we opted not to duplicate the (error-prone) dark magic used in the desktop version to change the sketch size mid-setup. There are only two renderers on Android. If you specify P2D or JAVA2D, that simply uses the built-in Android 2D renderer. Similarly, both P3D and OPENGL specify 3D graphics rendered OpenGL. In previous releases we also had A2D and A3D (which were aliases to the same 2D and 3D renderers), but those only create confusion. In the lead-up to 2.0 (revision 0198 and later), those constants have been removed. Because the size() command is handled by the preprocessor, Eclipse users will have to write sketchWidth(), sketchHeight(), and sketchRenderer() methods if they want to control the size. In most cases, you shouldn't need to mess with the size, but you may want to override the sketchRenderer() method so that you can use P3D. If you're more capable with Eclipse than reading comprehension, the previous points boil down to: When using Eclipse, 1) never call size(), 2) don't try to specify dimensions via sketchWidth/Height methods, and 3) if you want to use 3D instead of 2D, add this single method to your sketch:
public String sketchRenderer() { return P3D; }

Including both size() and the sketchXxxx() methods in a sketch will cause an error. Don't do that. Use screenWidth and screenHeight instead of screen.width and screen.height. Since Processing 1.2, both variables have been added to the desktop version of processing.core, where the screen variable has been deprecated. Aside from this being more consistent with the rest of the Processing API, the java.awt.Dimension type that's used for screen is not present on Android. The screen variable was something that was being used internally and then others began to use it so we felt compelled to document it. Not a terribly well thought out decision. Use keypad 7 or keypad 9 to rotate the emulator one direction or another. Or if you don't have a keypad or numlock, like you're using a laptop from the all-knowing geniuses from Cupertino, then press Ctrl-F12 (Ctrl-Fn-F12 on OS X) to rotate the screen. If you want to lock orientation to one direction, you can use one of the following commands inside setup(). These are new as of revision 0190.
orientation(PORTRAIT); // the hamburger way orientation(LANDSCAPE); // the hot dog way

We considered using size() as a hint for whether the emulator should open in portrait or landscape mode, but decided against it because it 1) added additional complexity, and 2) there wasn't a good way to control what actually happened one you're started up. Would it lock in one orientation? Hm, too clever.

8 of 13

03.06.2012 06:51

Android - Processing

http://wiki.processing.org/w/Android

Instead, we're keeping it simple and we'll play it by ear. Screen density and pixels/dots per inch can vary greatly between devices. If you need specific information about density to make your application work, you can use the DisplayMetrics class from android.util. Use the following to get the density and densityDpi for the sketch:
// Place this at the top of your sketch import android.util.DisplayMetrics; // Place this inside your setup() method DisplayMetrics dm = new DisplayMetrics(); getWindowManager().getDefaultDisplay().getMetrics(dm); float density = dm.density; int densityDpi = dm.densityDpi; println("density is " + density); println("densityDpi is " + densityDpi);

The Android documentation describes the 'density' value like so: This is a scaling factor for the Density Independent Pixel unit, where one DIP is one pixel on an approximately 160 dpi screen (for example a 240x320, 1.5"x2" screen), providing the baseline of the system's display. Thus on a 160dpi screen this density value will be 1; on a 120 dpi screen it would be .75; etc. The densityDpi value is simply 160 on a 160dpi screen, and you can guess what it is on a 240dpi screen. More can be found in the DisplayMetrics (http://developer.android.com/reference/android /util/DisplayMetrics.html) documentation. The OpenGL renderer is built-in on Android, no need to use 'import processing.opengl.*;' at the beginning of your sketch. The preprocessor will actually remove that text since it would otherwise cause a conflict. This is handled by the preprocessor so that users can quickly move between desktop and Android versions without needing to incessantly comment/uncomment the import line.

API Changed, Gone, or Forgotten

The package for the core library remains processing.core on Android. Early releases used processing.android.core in an attempt to avoid confusion between the two platforms. Unfortunately, this requires all librarieseven those that make only basic use of PApplet featuresto maintain separate sets of code for each. Because this would needlessly affect nearly all libraries, we've decided to just use the same package naming. This makes us cringe a little, but the alternative is perpetual annoyance at maintaining separate code bases for libraries for which only the package imports differ. In practice, there is little chance for processing.core packages for both platforms to ever collide with one another, since they require completely separate classpaths to build. The size() method operates differently, see above. Using createGraphics() with P3D/OPENGL is only available on devices that support the FBO extension properly, which is mostly Android 2.2 and later devices. Some others may work, but lots of the implementations are very buggy. screen.width and screen.height are replaced by screenWidth and screenHeight. See above. beginRecord, endRecord, beginRaw, endRaw are not available. There are no plans to include them, because it doesn't make sense to use them to export geometry on a handheld or portable device.

9 of 13

03.06.2012 06:51

Android - Processing

http://wiki.processing.org/w/Android

Registering methods (registerPost(), registerDraw(), etc) is not supported. Too much overhead for too little benefit. We'll need to bring these back in a future release. All cursor-related methods have been removed. (They don't make sense in a touch-controlled interface.) The all-lowercase version of arraycopy() (deprecated from the desktop version) has been removed. The (long since) deprecated openStream() method has been removed. Use createInput(). PImage.image is PImage.bitmap, to reflect that a different object type is there, in spite of its identical purpose. PFont.font is PFont.typeface, similar as above. The 'online' variable is not available. It's for applets to determine whether they're running online or not, which doesn't make sense on Android, where there's no such thing as an applet.

Loading files, connecting to the internet, and permissions

If you want to load data from the internet, or otherwise connect to other servers, you'll need to enable INTERNET permission for your sketch. To do so, use Tools Android Permissions to bring up the permissions editor. Check the box next to internet. If you want to use methods like saveStrings() or createWriter, you'll need to enable WRITE_EXTERNAL_STORAGE so that you can save things to the built-in flash a plug-in card. There are similar permissions for access to the phone, compass, etc. Look through the list in the permissions dialog, or check out other documentation that explains Android permissions in greater detail.

What about Multi-touch, GPS, SMS, Compass?

We hope to have simple examples or libraries for some of this. For multi-touch, I recommend this code (http://lukehutch.wordpress.com/2010/01/06/my-multi-touch-code-ported-to-eclair/) that handles some of the awfulness. For other features, please help us out by writing examples and tutorials on how it works. Then we can include them on the site and with the Processing download. Note, however, that any of these examples will come lateronce the software and processing.core has been debugged. So don't hold your breath waiting for us. You'll be disappointed. And turn blue.

Examples
In release 0193, examples have been added for the Compass and Accelerometer. These are very basic (and need additional improvements and API tweaks), but should be helpful for getting started.

Contributed Examples
From Rolf van Gelder, NL (http://cage.nl)
10 of 13

03.06.2012 06:51

Android - Processing

http://wiki.processing.org/w/Android

How to read the GPS (http://cagewebdev.com/android/gps_example.zip) , Feb 2011 How to read the compass (http://cagewebdev.com/android/compass_example.zip) , Mar 2011 From Eric Pavey (http://www.akeric.com) Interacting via multitouch (http://www.akeric.com/blog/?p=1435) , Mar 2011 Accessing the camera (http://www.akeric.com/blog/?p=1342) , Mar 2011 Making the phone vibrate (http://www.akeric.com/blog/?p=1334) , Mar 2011 Accessing the sensors (http://www.akeric.com/blog/?p=1313) (accelerometer, magnetic field, etc.), Mar 2011

Using Eclipse for Development

Ok, so you're smarter than the rest of us, and are using Eclipse. Some notes for you, bigshot: The tutorial on how to use Eclipse with Processing has nothing to do with developing for Android. You should only use Eclipse for Android development if you've already spent time learning how to develop Android applications using Eclipse (separately from Processing), and want to make use of the Processing core library. Android development in Eclipse is significantly more difficult than desktop Processing/Java development with Eclipse. Take time to learn it if you're going this route: get a book, read some Android development tutorials, etc. See the section above regarding how the size() command is handled. Instead of a 'data' folder, use the 'assets' folder. If you're converting a Processing project, rename your data folder to assets. Or if you have files you'd like to get at with loadStrings(), put them in the assets folder. The best way to make an Android application is to use Subclipse to check out the source for processing/android/core as its own project in Eclipse. Call that project android-core. Then create a new Android project using the Eclipse ADT, and include android-core as a 'required project'. For nearly everything else, you're on your own. The point of the PDE is to not have to use something like Eclipse. When you shoot yourself in the foot, don't complain to us when it hurts. Don't take your guns to town, son. Leave your guns at home, Bill.

Integrating with other Android code

We definitely *do not* recommend incorporating Android GUI components into Processing sketches. The drawing model is incompatible, and like using AWT/Swing components can cause trouble with the desktop version of Processing, the same issues apply here: they might work in some cases, but will be inconsistent across other devices and/or Android OS versions. Because a Processing sketch is an Android Activity, it's a non-trivial task to embed a Processing sketch within another application. In a future release, we'd like to support this better, however it's quite difficult in the meantime. For instance: We could make a sketch into a SurfaceView, but because 2D and 3D drawing surfaces on Android have different base classes, it would require us to duplicate all of the base implementation into two versions.

11 of 13

03.06.2012 06:51

Android - Processing

http://wiki.processing.org/w/Android

To fix the issue above, the preprocessor would have to instead detect whether using 2D or 3D, and then subclass PApplet2D and PApplet3D (or something along those lines) at compile time. This is a significant departure from the desktop version (and the current implementation) which allows the user to dynamically specify the renderer. Similarly, for implementing wallpapers or widgets, they also have a different base class, which would mean additional duplication. These issues are not insurmountable, since we could heavily refactor the PApplet code so that the Activity class is a much thinner layer, and to make a series of base classes that handle 2D, 3D, Wallpaper, and Widget. However, this is a very large undertaking, and is a huge departure from the desktop version, which means a lot more code for us to maintain. Where us is a couple people working (largely) in their free time. So for the time being, we've made the decision to get Android up and running for the vast majority of Processing users first, and once that's reached a state where we're happy with it, we can address these issues in a future release.

Distributing Apps
It's a lot more fun to share your applications with other people. I'll build out this section as we clear up the features that make it easier to publish your apps on the market (or to make them available yourself from a web page). You might want to read Google's guidelines on Preparing to Publish (http://developer.android.com/guide /publishing/preparing.html) .

Signing
To publish with the market, your application must be signed. At the moment, you can Export your code, and self-sign it by following these instructions (http://developer.android.com/guide/publishing/app-signing.html) from Google. We're also working on an easier method (http://code.google.com/p/processing/issues/detail?id=222) to do this from within the PDE. A great, clear instruction on signing and deploying your app you can find here (http://www.akeric.com /blog/?p=1352) ! (added by RvG)

Icons
Starting with revision 0190, it's possible to specify an icon that goes with your sketch. Actually Android wants lots of icons, which cover the varying screen resolutions where your app might show up, and the different contexts (launcher icons or a long list) where your app might be used. All sketches use a default icon unless you specify otherwise. To create your own, save images as icon-36.png, icon-48.png, and icon-72.png. These should be 36x36, 48x48, and 72x72 pixel icons. Place them in the sketch folder (not the data folder or any other subfolder). The next time you build your app, these will be used instead of the defaults. Your icons shouldn't just be images that use the full area of the icon. See the design guidelines (http://developer.android.com/guide/practices/ui_guidelines/icon_design.html) for information on how to size, color, and shade your icons.

12 of 13

03.06.2012 06:51

Android - Processing

http://wiki.processing.org/w/Android

AndroidManifest.xml
Starting with revision 0190, Android sketches have an AndroidManifest.xml file in their sketch folder. This is manipulated by the various options that control permissions, naming of the sketch, etc. You can also make edits yourself, but keep in mind that breaking the manifest file can cause a lot of trouble. If you start making changes, be sure to back up your previous file first. Also, be sure to modify the copy in your sketch folder, not the file created by using Export or Export to Application. Those will be replaced next time you use the Export function. In some cases, you may want to make tweaks to the exported folder, but be sure to move it to a new location first so that you don't inadvertently lose changes when using the Export command again. Retrieved from "http://wiki.processing.org/w/Android" This page was last modified on 25 January 2012, at 16:15. Content is available under Attribution-Noncommercial-Share Alike 3.0 Unported. Powered by MediaWiki

13 of 13

03.06.2012 06:51