Child pages
  • Guide to distributing a RAMP app
Skip to end of metadata
Go to start of metadata

Guide to distributing a RAMP app

All RAMP apps are automatically hosted on the RAMP Deployment Platform at{CompanyId}/{AppId} 

where {CompanyId} is the company you registered with and {AppId} is the name of the app.

This guide is for users planning on hosting their app at multiple locations, e.g. in an app store.

Retrieve specific app build

This section explains how to retrieve the correct device- or OS-specific build of your app from the Deployment Platform, so that you can host it for a device or OS specific device or submit it to a device or OS specific application store.

Log on to the Deployment Platform and select Applications, Now select the app that you want to submit. You will be presented with a list of options. In the example, app "demo" was selected.

From the options available for the app, select Manage Versions to display a list of the available sets of app builds. The name of a set of builds is derived from the app's name and the version of the RAMP platform it is built against. In the example, sets based on version 3.5 and 4.3 are available.


More than one build set with the same name could be available if newly uploaded build sets are built against a similar RAMP platform version.

Select the desired build set to view a list of each build in the set followed by info on its id, when it was created and the devices and capability groups it is aimed at. The example selected build set demo 4.3 and a portion of the list is displayed.


Many device families are split across various builds, e.g. the Java ME device family has separate builds for touch, non-touch and stylus builds and many device specific builds.

Examine the devices and capability groups column in the list and select the build that is best suited for your purpose. The selected build can now be downloaded using its id from the far left column.

All builds can be downloaded using the address{id}.{extension}, where {id} is the build's id (the most left column) and {extension} depends on the targeted device. The list of {extension} values associated with each device family is as follows:


Some built files can only be downloaded if the browser's User Agent matches the User Agent of a browser from the targeted device family.

For example, to be able to download the Android build I need an Android User Agent. This problem is solved when I set the browser's User Agent to that of the Google Nexus (an Android device),

Mozilla/5.0 (Linux; U; Android 2.2; en-us; Nexus One Build/FRF91) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 

Java ME device family

Files available for download have {extension} values:

  • jad
  • jar

Both the two files are required for distributing the app. In the example, the Nokia 6600 version of the app is downloaded with links and

BlackBerry device family

Files available for download have {extension} values:

  • jad
  • cod
  • alx
  • cso
  • csl

To submit a Blackberry app to an app store, e.g. BlackBerry App World, you typically just need the .cod file. If you plan on hosting the app on a web site for OTA (Over The Air) installation, you need the cod file and also the .jad file. A third method for installing the app on a BlackBerry device is via the BlackBerry Desktop Manager, for this method you need the .cod file and the .alx file.

In the example, the BlackBerry 7290 build is intended for the BlackBerry App World and is obtained with link

Android device family

Files available for download have {extension} values:

  • apk

Android only requires one file for both installing manually or submitting to an app store.

In the example, I first set my browser's User Agent to that of an Android device, and then download the build with link

App signing

Most apps require some form of signing before they are accepted on a distribution platform. The varying signing requirements can include: self-performed, third-party or app-store performed.

This section covers performing signing with the RAMP Deployment Platform and the signing requirements of the most common platforms.

RAMP VM signing

The RAMP VM itself can be signed, currently signing is only supported for Java ME MIDP 2.0 and Android based VMs. The user submits a key and certificate to the Deployment Platform to sign an app build.

Obtain/generate key-certificate pair

The Deployment Platform requires a private key and certificate that is in DER format in order to be able to sign the VM. They can be self generated for self signing or obtained from a third party.

The easiest way to generate a private key and certificate is to use openssl. The following openssl commands generate a DER private key and self-signed certificate which is valid for 10000 days (the minimum recommended duration):

openssl genrsa -out key.pem 1024
openssl req -new -key key.pem -out key.csr
openssl x509 -req -days 10000 -in key.csr -signkey key.pem -out crt.pem
openssl pkcs8 -topk8 -nocrypt -in key.pem -inform PEM -out key.der -outform DER
openssl x509 -in crt.pem -inform PEM -out crt.der -outform DER


Jave ME MIDP 2.0 does not allow for self-signed applications, and a valid certificate from a certificate authority that has its root certificate present on the device, should be used.

Create a RAMP VM Signing Parameter

The generated key and certificate need to be added to the VM Signing Params associated with your RAMP account. On the Deployment Platform, select RAMP VM Config. You are presented with a list of options from which you select VM Signing.

A list of all the signing parameters available to your account is displayed. Select New Signing Params to add your generated key and certificate. Upload key.der in section Private key.

Upload crt.der in section Certificate.


Finally, tick the capability groups the signing parameters should be applied to and fill in fields to identify the parameters before submitting. The example selects to sign only Android apps with this signing parameter.

Create a RAMP VM Config

On the Deployment Platform, again select RAMP VM Config. Now select VM Configs from the list of options.

A list of all the VM Configs available to your account is displayed. Select New VM Config to add your newly created signing parameters to a VM configuration.

In section VM signing params, select the signing parameter you created from the list of parameters available to your account. Add information to identify the config and submit. In the example the newly created myAndroidSignParams was selected.

Create a signed RAMP app

When creating a new RAMP app that should be signed with the generated certificate-key pair, make sure to set the VM Config section to a VM Config with its VM Signing Params set. In the example a new app is created with its VM Config set to the newly created myAndroidSigning.

Device family specific signing requirements

Java ME

A RAMP Java ME app does not require signing to be installed on a device, but signing is typically required when submitting to a distribution platform.

If you did not perform RAMP VM signing, the Java ME app is unsigned. Some devices have issues with unsigned apps requesting device permissions, consequently these permission requests are removed from all unsigned apps. If you should choose to sign the app with a third party, the permission requests must be added back into the app files. The standard RAMP Java ME VM only requires the permission


 but an app using plugins may require more.


A script to automatically update your obtained Java ME build is available here.

Adding permissions require editing the app's jad and jar file, obtained when following the guide here.  The jar file must be unzipped (append .zip to the file) and the permissions added to a manifest file among the unzipped files. Appende the permission at the end of file META-INF/MANIFEST.MF on its own line. An example of an updated manifest file:

MIDlet-Vendor: vmt
Manifest-Version: 1.0
MicroEdition-Profile: MIDP-2.0
Ant-Version: Apache Ant 1.8.2
MIDlet-Name: demo
MIDlet-1: demo,/icon.png, _demo
MicroEdition-Configuration: CLDC-1.0
MIDlet-Icon: /icon.png
Created-By: 1.6.0_20-b02 (Sun Microsystems Inc.)
MIDlet-Version: 4.3.1

The unzipped contents of the jar file can then be zipped again and renamed to its original name.

The same permission must then also be appended to the jad file on its own line, and the jad file property "MIDlet-Jar-Size" must be updated with the new size of the jar file in bytes.  An example of a jad file that includes a permission :

MIDlet-Vendor: vmt
MIDlet-Jar-Size: 125815
MicroEdition-Profile: MIDP-2.0
MIDlet-Name: demo
MicroEdition-Configuration: CLDC-1.0
MIDlet-1: demo,/icon.png, _demo
MIDlet-Icon: /icon.png
MIDlet-Jar-URL: build-40419.jar
MIDlet-Version: 4.3.1


An unsigned (or self-signed) Java ME app can request to be signed for free by Nokia when it is submitted to the Ovi Store. This reduces the turnaround time and eliminates the signing costs.

Nokia Ovi Store

The following extra properties should also be included in the jad file:

Nokia-MIDlet-On-Screen-Keypad: no

The Nokia content guidelines must be adhered to:

Here are some common reasons for QA failure:!top-10-qa-issues.html

The app must include a help screen which links to the privacy policy, and an about screen which includes information matching that in the jad file (!top-10-qa-issues/java-app-missing-about-information.html).


The BlackBerry app is automatically signed during the build process.


All Android apps need to be signed, even when testing on the emulator. Self signing is allowed and RAMP VM signing from this section can be used.


If no VM Signing Params was set for the Android build of an app, it will be signed with default parameters. These parameters are fine for testing on a device, but may not have a long enough duration to be valid for a distribution platform like the Google Play Store (formerly Android Market). The VMTAndroidMarketSign signing parameter can be used for signing apps for the Google Play Store.


An Android app can always be manually re-signed, just follow the relevant directions at

  • No labels