The Motorola J2ME Platform
Functionality not covered by the CLDC and MIDP APIs is left for individual OEMs to implement and support. By adding to the standard APIs, manufacturers can allow developers to access and take advantage of the unique functionality of their handsets. The Motorola C381p handset contains OEM APIs for extended functionality ranging from enhanced UI to advanced data security. While the Motorola C381p handset can run any application written in standard MIDP, it can also run applications that take advantage of the unique functionality provided by these APIs. These OEM APIs are described in this guide.

MIDP 1.0

J2ME is the version of Java that the mobile device will support. It was developed to support devices with limited memory, i.e mobile devices, pagers, SIM cards. J2ME maintains the qualities that Java technology has become famous for: built-in consistency across products in terms of running anywhere, any time, over any device portability of the code leveraging of the same Java programming language safe network delivery applications written with J2ME are upwardly scalable to work with J2SE and J2EE.
J2ME enables device manufacturers, service providers, and content creators to deploy compelling new applications and services to their customers rapidly and cost-effectively while capitalizing on new revenue streams. In using J2ME, the handset must be MIDP 1.0 and CLDC 1.0 compliant. To assure this compliance, the handset must pass the Technology Certification Kit, TCK, provided by Sun.
Resources and APIs Available
MIDP 2.0 will provide support to the following functional areas on the Motorola C381p handset: MIDP 2.0 Application delivery and billing Application lifecycle Application signing model and privileged security model End-to-end transactional security (HTTPS) Networking Persistent storage Sounds Timers User Interface File Image Support (.PNG,.JPEG,.GIF)
Additional Functionality WMA (JSR 120) MMA (JSR 135) Phonebook API Telephony API
3 Developing and Packaging J2ME Applications
Guide to Development in J2ME
Introduction to Development This appendix assumes the reader has previous experience in J2ME development and can appreciate the development process for Java MIDlets. This appendix will provide some information that a beginner in development can use to gain an understanding of MIDlets for J2ME handsets. There is a wealth of material on this subject on websites maintained by Motorola, Sun Microsystems and others. Please refer to the following URLs for more information: http://www.motocoder.com http://www.java.sun.com/j2me http://www.corej2me.com/ http://www.javaworld.com/ As an introduction, brief details of J2ME are explained below. The MIDlet will consist of two core specifications, namely Connected, Limited Device Configuration (CLDC) and Mobile Information Device Profile (MIDP). Both of these specifications (Java Specification Requests) can be located at the http://www.jcp.org/ site for reading. For MIDP 1.0; JSR 37 should be reviewed. For MIDP 2.0; JSR 118 should be reviewed. For CLDC 1.0.4; JSR 30 should be reviewed. For CLDC 1.1; JSR 139 should be reviewed. To determine what implementation is on Motorola handset, review the Java System details through the menu on the Motorola handset (located under Java Settings). For beginning development, key points to remember are memory size, processing power, screen capabilities and wireless network characteristics. These all play an important part

904 JAR Size Mismatch 905 Attribute Mismatch 906 Invalid Descriptor 907 Invalid JAR 908 Incompatible Configuration or Profile 909 Application Authentication Failure 910 Application Authorization Failure 911 Push Registration Failure 912 Deletion Notification 913 Required package not supported by device 999 Other errors Please be aware that the method used by the handset, as per the specifications, is POST. Using a GET (URL encoding) style for the URL will fail. This is not the correct use of the MIDlets JAD parameters. Possible Screen Messages Seen With Downloading: If JAR -file size does not match with specified size, it will display a dialog stating Installation failed. Package invalid. To dismiss this dialog, press OK. When downloading is done, the handset displays a transient notice Download Completed and starts to install the application. Upon completing installation, the handset displays a dialog Install complete. To dismiss this dialog, press OK. If the MANIFEST file is wrong, the handset displays a dialog stating Installation failed. Package invalid. To dismiss this dialog, press OK. If JAD does not contain mandatory attributes, Installation failed. Package invalid. notice appears.

Error Logs

The Table 1 represents the error logs associated with downloading applications. Error Logs 906 Invalid Descriptor. Scenario JAD Download Possible Cause Missing or incorrectly formatted mandatory JAD attributes Mandatory: MIDlet-Name (up to 32 symbols) MIDlet-Version MIDlet-Vendor (up to 32 symbols) MIDlet-JAR-URL (up to 256 symbols) MIDlet-JAR_Size JAD signature verification failed Unknown error during JAD validation The received JAR size does not Error Dialog Failed: Invalid File

904 JAR Size

OTA JAR

Download Failed

Mismatch. 902 User Cancelled. 903 Loss of Service. 901 Insufficient Memory. 905 Attribute Mismatch 901 Insufficient Memory. 907 Invalid JAR.
Download OTA JAR Download OTA JAR Download OTA JAR Download Installation Installation Installation
match the size indicated in JAD User cancelled download Browser lost connection with server Insufficient space to install the MIDlet suite Mandatory attributes are not identical in JAD & Manifest Insufficient Space to install MIDlet suite Class references non-existent class or method Security Certificate verification failure Checksum of JAR file is not equal to Checksum in MIDlet-JAR-SHA attribute Application not authorized Security Certificates expired or removed Authorization failure during MIDlet execution Incorrect MIDlet

Table 1 Error Logs

Cancelled: <Icon> <Filename> Installation Failed Insufficient Storage Installation failed. Package invalid. Insufficient Storage Installation failed. Package invalid.
MIDlet Launching MIDlet Execution
Application Expired Application Error

OTA and Download

Comply with OTA User Initiated Provisioning Specifications in MIDP 2.0. The user MUST be prompted if the midlet is chargeable. Terminals should compare and predict the application program that will be downloaded is the latest or old versions and give indication to users. Check the available memory before any downloads. Users should be able to terminate the download process any time by pressing END key. Before downloading the following JAD file information must be displayed first:
Contents Application program name (Midlet name) Application program version number Vendor Name
Maximum length 32 Bytes Max 16 Bytes Max 32 Bytes Max
URL of JAR file Size of JAR file Applicable Terminal Type Application program introduction (Midlet description) Information Fee (Media price).
Table 2 JAD file information
Not specified 8 Bytes Max not specified 512 Bytes Max 32 Bytes Max
End user should be able to delete the applications downloaded.

5 Application Management

The following sections describe the application management scheme for the Motorola C381p handset. This chapter will discuss the following: Downloading a JAR without a JAD MIDlet upgrade Installation and Deletion Status Reports System Menu
Downloading a JAR file without a JAD
In Motorolas MIDP 2.0 implementation, a JAR file can be downloaded without a JAD. In this case, the user clicks on a link for a JAR file, the file is downloaded, and a confirmation will be obtained before the installation begins. The information presented is obtained from the JAR manifest instead of the JAD.

MIDlet Upgrade

Rules from the JSR 118 will be followed to help determine if the data from an old MIDlet should be preserved during a MIDlet upgrade. When these rules cannot determine if the RMS should be preserved, the user will be given an option to preserve the data. The following conditions are used to determine if data can be saved: If the cryptographic signer of the new MIDlet suite and the original MIDlet suite are identical, then the RMS record stores MUST be retained and made available to the new MIDlet suite. If the URL of the new MIDlet suite is identical to the URL the original MIDlet suite was downloaded from, then the RMS MUST be retained and made available to the new MIDlet suite. If the above statements are false, then the device MUST ask the user whether the data from the original MIDlet suite should be retained and made available to the new MIDlet suite.

MIDlet-Jar-URL MIDlet-Jar-Size MIDlet-Data-Size MicroEdition-Profile
The URL from which the JAR file can be loaded. The number of bytes in the JAR file. The minimum number of bytes of persistent data required by the MIDlet. The J2ME profiles required. If any of the profiles are not implemented the installation will fail. The J2ME Configuration required, i.e CLDC 1.0 Zero or more permissions that are critical to the function of the MIDlet suite. Zero or more permissions that are noncritical to the function of the MIDlet suite. Register a MIDlet to handle inbound connections The URL to which a POST request is sent to report installation status of the MIDlet suite. The URL to which a POST request is sent to report deletion of the MIDlet suite. A text message to be provided to the user when prompted to confirm deletion of the MIDlet suite. MIDlets with this Motorola specific attribute will continue to run when not in focus.
Table 5 MIDlet Attributes, descriptions, and JAD and/or JAR location

Yes Yes

Yes, or no if included in the JAD. Yes, or no if included in the JAD.
Yes, or no if included in the JAR Manifest. Yes, or no if included in the JAR Manifest.
MicroEdition-Configuration
MIDlet-Permissions MIDlet-Permissions-Opt MIDlet-Push-<n> MIDlet-Install-Notify
MIDlet-Delete-Notify MIDlet-Delete-Confirm

Background

7 Java.lang Implementation

java.lang support

Motorola implementation for the java.lang.System.getProperty method will support additional system properties beyond what is outlined in the JSR 118 specification and is controlled by a flex bit. These additional system properties can only be accessed by trusted MIDlets. The additional system properties are as follows: Cell ID: The current Cell ID of the device will be returned during implementation. IMEI: The IMEI number of the device will be returned during implementation.
The Code Sample 1 shows java.lang support:
System.getProperty("phone.mcc") System.getProperty("phone.mnc") System.getProperty("phone.imei") System.getProperty("phone.cid") System.getProperty(phone.lai) System.getProperty(phone.ta)
Code Sample 1 Java.lang support

8 Network APIs

Network Connections
The Motorola implementation of Networking APIs will support several network connections. The network connections necessary for Motorola implementation are the following: CommConnection for serial interface HTTP connection HTTPS connection Socket connection SSL

} while (bytes_read > 0); } catch (Exception ex) { System.out.println("IO failed: "+ ex.getMessage()); } finally { closeAllStreams(i); //clean up } }
Code Sample 2 Socket Connection

User Permission

The user of the handset will explicitly grant permission to add additional network connections.

HTTPS Connection

Motorola implementation supports a HTTPS connection on the Motorola C381p handset. Additional protocols that will be supported are the following: TLS protocol version 1.0 as defined in http://www.ietf.org/rfc/rfc2246.txt SSL protocol version 3.0 as defined in http://home.netscape.com/eng/ssl3/draft302.txt
The Code Sample 3 shows the implementation of HTTPS:
HTTPS import javax.microedition.io.*; import java.io.*; import javax.microedition.midlet.*; try { hc[i] = (HttpConnection)Connector.open(https:// + url[i] + "/"); } catch (Exception ex) { hc[i] = null; System.out.println("Open Failed: " + ex.getMessage()); } if (hc[i] != null) {
try { is[i] = hc[i].openInputStream(); byteCounts[i] = 0; readLengths[i] = hc[i].getLength(); System.out.println("readLengths = " + readLengths[i]); if (readLengths[i] == -1) { readLengths[i] = BUFFER_SIZE; } int bytes_read = 0; int offset = 0; int bytes_left = (int)readLengths[i]; do { bytes_read = is[i].read(buffer, offset, bytes_left); offset += bytes_read; bytes_left -= bytes_read; byteCounts[i] += bytes_read; } while (bytes_read > 0); System.out.println("byte read = " + byteCounts[i]); } catch (Exception ex) { System.out.println("Downloading Failed: "+ ex.getMessage()); numPassed = 0; } finally { try { is[i].close(); is[i] = null; } catch (Exception ex) {} } } /** * close http connection */ if (hc[i] != null) { try { hc[i].close();
} catch (Exception ex) { } hc[i] = null; }
Code Sample 3 HTTPS Connection
9 JSR 135 Mobile Media API

JSR 135 Mobile Media API

The JSR 135 Mobile Media APIs feature sets are defined for five different types of media. The media defined is as follows: Tone Sequence Sampled Audio MIDI
When a player is created for a particular type, it will follow the guidelines and control types listed in the sections outlined below. The Code Sample 4 shows the implementation of the JSR 135 Mobile Media API:

SMS Message Types

The types of messages that can be sent are TEXT or BINARY, the method of encoding the messages are defined in GSM 03.38 standard (Part 4 SMS Data Coding Scheme). Refer to section A.5.0 of JSR 120 for more information.

SMS Message Structure

The message structure of SMS will comply with GSM 03.40 v7.4.0 Digital cellular telecommunications system (Phase 2+); Technical realization of the Short Message Service (SMS) ETSI 2000. Motorolas implementation uses the concatenation feature specified in sections 9.2.3.24.1 and 9.2.3.24.8 of the GSM 03.40 standard for messages that the Java application sends that are too long to fit in a single SMS protocol message. This implementation automatically concatenates the received SMS protocol messages and passes the fully reassembled message to the application via the API. The implementation will support at least three SMS messages to be received and concatenated together. Also, for sending, support for a minimum of three messages is supported. Motorola advises that developers should not send messages that will take up more than three SMS protocol messages unless the recipients device is known to support more.

SMS Notification

Examples of SMS interaction with a MIDlet would be the following: A MIDlet will handle an incoming SMS message if the MIDlet is registered to receive messages on the port (identifier) and is running. When a MIDlet is paused and is registered to receive messages on the port number of the incoming message, then the user will be queried to launch the MIDlet. If the MIDlet is not running and the Java Virtual Machine is not initialized, then a Push Registry will be used to initialize the Virtual Machine and launch the J2ME MIDlet. This only applies to trusted, signed MIDlets. If a message is received and the untrusted unsigned application and the KVM are not running then the message will be discarded. The Table 10 depicts list of Messaging features/classes supported in the device.
Feature/Class JSR-120 API. Specifically, APIs defined in the javax.wireless.messaging package will be implemented with regards to the GSM SMS Adaptor All fields, methods, and inherited methods for the Connector Class in the javax.microedition.io package All methods for the BinaryMessage interface in the javax.wireless.messaging package All methods for the Message interface in the javax.wireless.messaging package All fields, methods, and inherited methods for the MessageConnection interface in the javax.wireless.messaging package Number of MessageConnection instances in the javax.wireless.messaging package All methods for the MessageListener interface in the javax.wireless.messaging package All methods and inherited methods for the TextMessage interface in the javax.wireless.messaging package Number of concatenated messages.

" + e.toString()); } } }
Code Sample 5 JSR 120 Wireless Messaging API

11 Phonebook Access API

Phonebook Access API
Using the Phonebook Access API, an application will be able to locate and update contact information on the handset. This contact information includes phone numbers, email addresses, and any other directory information related to individuals, groups, or organizations. The database used to store phonebook information will be unique and integrated for native phonebook, SIM card, and other applications using Phonebook API. The primary goal of the Phonebook Access API is to be simple and thin to fit in resourcelimited devices like the Motorola C381p handset. This API will specify a base storage class for all types of contacts items presented in the vCard specification (RFC2426 vCard MIME Directory Profile vCard 3.0 Specification). In addition, schema strings used in querying and storing contact information are those specified in the RFC2426 specification. The Phonebook Access API will perform the following functions: Allow multiple phone numbers and email addresses for each contact Store new entries Retrieve entries Edit existing entries Delete entries Check memory status Order and sort contact parameters Support standard schema strings
Phonebook Access API Permissions
Prior to a MIDlet accessing the Phonebook API for all Phonebook operations, the implementation will check the Phonebook permissions granted to the application.
In the Motorola C381p, Phonebook API permissions have been added to the MIDP 2.0 security framework com.motorola.phonebook. The behavior is up to the domain setting where the MIDlet falls in. For an untrusted MIDlet, the permission for the API is Oneshot. The Code Sample 6 shows the implementation of the Phonebook API:
Sample of code to create object of PhoneBookRecord class: PhoneBookRecord phbkRecEmpty = new PhoneBookRecord(); String name = Name; String telNo = 9999999; int type = PhoneBookRecord.MAIN; PhoneBookRecord phbkRec = new PhoneBookRecord(name, telNo, type, PhoneBookRecord.CATEGORY_GENERAL); Sample of code for calling of add(int sortOrder) method: int index = phbkRec.add(PhoneBookRecord.SORT_BY_NAME); Sample of code for calling of update(int index, int sortOrder) method: phbkRec.type = PhoneBookRecord.HOME; int newIndex = phbkRec.update(index, PhoneBookRecord. SORT_BY_NAME); Sample of code for calling of delete(int index, int sortOrder) method: PhoneBookRecord.delete(index, PhoneBookRecord. SORT_BY_NAME); Sample of code for calling of deleteAll() method: PhoneBookRecord.deleteAll(); Sample of code for calling of getRecord(int index, int sortOrder) method: phbkRec.getRecord(index, PhoneBookRecord.SORT_BY_NAME); Sample of code for calling of findRecordByTelNo(String tel, int sortOrder) method: index = phbkRec.findRecordByTelNo(telNo, PhoneBookRecord.SORT_BY_NAME); Sample of code for calling of findRecordByName(char firstChar, int sortOrder) method: index = PhoneBookRecord.findRecordByName('N', PhoneBookRecord.SORT_BY_NAME); Sample of code for calling of findRecordByEmail(String email, int sortOrder) method: String email = email@mail.com; index = phbkRec.findRecordByEmail(email, PhoneBookRecord.SORT_BY_NAME);

Newer Application Version Exists:
If the application version on the handset is newer than the downloaded version of application, the following message is displayed. The error occurred can be queried by selecting DETAILS.
Figure 11 Latest (Newer) Version of Application exists
Rules: If the latest or newer version of application is already present on the handset, it cannot be downloaded
18 Lightweight Windowing Toolkit
LWT integrate with the LCDUI API within the MIDP and enhance the capabilities to include a component-level API through which developers can control the contents and layout of their screens. These components are graphical user interface elements such as buttons, check boxes, text fields, images, etc. LWT also allow developers to create new imaginative components or change the look and feel of existing components. Those MIDlets taking advantage of the added capabilities of LWT will only run on those handsets that incorporate the LWT LOC. LWT extends the MIDP class hierarchy by extending the LCDUI Canvas class. The ComponentScreen is a subclass of Canvas, which means it can be easily added to a MIDP implementation and minimize dependencies and maintenance overhead. This also allows standard MIDlets to mix both MIDP screens and LWT screens in their MIDlets. LWT is designed to use MIDP low-level graphics routines exclusively, which adds to the ease of implementation. Although no device-specific modifications are required, an LWT implementation may be tailored to match the rest of the devices user interface. The text components in LWT may be integrated with the devices data entry mechanisms, such as handwriting recognition or predictive keypad input. LWT implementation requires the handset to be MIDP compliant and have approximately 30KB of flash memory. LWT does not expose any additional native interfaces and only relies on mechanisms specified by MIDP 1.0. LWT can be safely exposed to untrusted MIDlets. Once LWT is implemented, the LWT TCK must be completed and pass successfully.

19 UDP Support

This functionality is to enable J2ME applications access to Generic UDP Transport Service. This enhancement allows for J2ME applications to utilize the UDP header compression format for data applications over IP. The API should follow the guidelines of the User Datagram Protocol standard, IETF RFC 768, J. Postel, August 28, 1981. This functionality should be available for both CSD and GPRS connections.

javax.microedition.lcdui.TextBox
The TextBox class is a Screen that allows the user to edit and enter text.
javax.microedition.lcdui.TextField
A TextField is an editable text component that will be placed into a Form. It is given a piece of text that is used as the initial value. Refer to the Table 20 for iTAP feature/class support for MIDP 2.0: Feature/Class Predictive text capability will be offered when the constraint is set to ANY User will be able to change the text input method during the input process when the constraint is set to ANY (if predictive text is available) Multi-tap input will be offered when the constraint on the text input is set to EMAILADDR, PASSWORD, or URL
Table 20 ITAP feature/class

24 LCDUI

LCDUI API
The Table 21 lists the specific interfaces supported by Motorola implementation: Interface Choice CommandListener ItemCommandListener ItemStateListener Description Choice defines an API for user interface components implementing selection from a predefined number of choices. This interface is used by applications which need to receive high-level events from implementation A listener type for receiving notification of commands that have been invoked on Item286 objects This interface is used by applications which need to receive events that indicate changes in the internal state of the interactive items within a Form231 screen.
Table 21 Interfaces supported by Motorola implementation
The Table 22 lists the specific classes supported by Motorola implementation: Classes Alert AlertType Canvas Description An alert is a screen that shows data to the user and waits for a certain period of time before proceeding to the next Displayable. The AlertType provides an indication of the nature of alerts. The Canvas class is a base class for writing applications that need to handle low-level events and to issue graphics calls for drawing to the display. A ChoiceGroup is a group of selectable elements intended to be placed within a Form. The Command class is a construct that encapsulates the semantic information of an action. A CustemItem is customizable by sub classing to introduce new

Flip Behaviors

A Motorola specific JAD attribute called FlipInsensitive exists. When a MIDlet is running and the flip is closed by the user, the MIDlet will follow one of the following behaviors: Suspend if the FlipInsensitive attribute is = false. Continue running if the FlipInsensitive attribute is = true. In this case, audio resources will be available for the MIDlet.

27 Java System Menu

The Java System menu allows the user to see what version of MIDP and CLDC is being used in the phone. It also shows the user the free data space available, program space available, and the heap size being used. The Table 24 describes each function in detail.

Action Description

CLDC Version MIDP Version Data Space Program Space Heap Size
This displays the CLDC version that is being used in the MS. This displays the MIDP version that is being used in the MS. This displays the amount of free memory available for data used by the applications, i.e. phone book entries, game high scores. This displays the amount of free memory available for applications. This is the amount of runtime memory available in the phone.
Table 24 Function Describes

MIDlet Manager Menu

The MIDlet Manager menu lets the user perform certain actions on the selected MIDlet suites. The table 25 describes the various actions that can be performed on a suite.

Details

Displays the information about the suite. This includes MIDlet suite name, vendor, version, number of apps in suite, flash usage, both data and program space of the application. Lets the user delete a suite. A confirmation is requested before the application is deleted.
Table 25 Midlet Manager Menu Description
View MIDlet Suite Information
To view information on any MIDlet suite, the user brings up the MIDlet Manager menu. The user highlights the Details option and SELECTs it to view the information. The information presented includes MIDlet suite name, vendor, version, number of apps in suite, and flash usage, both data and program space. The figure 14 illustrates this:

28 Invisible Net for J2ME

Introduction

This chapter presents the Invisible Net for J2ME feature for multi line graphics displays. By making it quicker and easier for the user to launch the browser for the embedded applications, the carrier can experience ARPU bumps due to the additional Internet traffic. Other benefits to customers and carriers include the simplification of the UI, elimination of the hunt and peck scenario when trying to access URLs across applications, and additional value-add in content/service delivery.
J2ME Invisible NET Options
J2ME applications can embed Invisible Net URLs within the J2ME components or within J2ME context-sensitive menus, such as Games & Apps, and Java Tools, as listed in the following sections.

J2ME Component Options

A product utilizing the Motorola J2ME solution should be able to use the Invisible Net functionality to embed URLs within the following J2ME menus: Rules: The associated right softkey when a URL will be launched shall be GO TO. Games and Apps menu Java Tools menu HTTP downloads operation for J2ME.
URLs associated with J2ME menus or components will be launched using one of the following methods: o HTTP download with the following exceptions: Launch shall be directly to the URL associated with the J2ME menu item. If flexed on, retrieve the URL from the HTTP client. If flexed off, retrieve the URL through the browser. Title can be flexible, and URL can be flexible. o If existing Web Sessions is used, launch shall be using the information from the default Browser session: Instead, launch shall be directly to the URL associated with the J2ME menu item. o For future implementation, if Web Sessions Redesign has been implemented, launch of the URL will use the following: Default Java Session parameters (or in the absence of a Java Session, the default Browser application settings) and the launch shall be directly to the URL associated with the Java menu item. Default data connection parameters Refer to MRS 7535 - Internet Setup (Web Sessions Redesign) for more information on application and data connection session parameters. o Upon exiting the active browser or HTTP session, the user shall be returned to the Java menu from which the browser was launched from. (Games and Apps menu or Java Tools menu). J2ME menu items must be approved by Technical Marketing, CxD and Product Marketing. Position of the Invisible Net J2ME menu item(s) in the menu structure must be approved by the appropriate representatives from the product team, the region, the customer, CxD and Technical Marketing. All prompts (including menu prompts and menu list items) and URL addresses must be accessible through the PRI interface. All prompts and URLs must be set with an option to either allow or not allow access to the carriers as determined by individual regions and customers. All J2ME related application menu or context-sensitive menu item prompts must be flexible, easy to change and provision as customization will be necessary by region and customer. All J2ME related application menu or context-sensitive menu item prompts and URL addresses must be accessible through the PRI interface.

29 Download Midlet through PC
To download MIDlets through a PC, make a connection to a PC through IrDA, Bluetooth, USB or Serial Cable (RS 232). This content considers only the RS232 connection using JAL.

Establishing Connection

When a successful connection to a PC is made, an application can be downloaded. The MS should display that a connection has been made. Only one connection will be active at a time.
30 Operator Apps Provisioning
The application provisioning feature uses the existing functionality to deliver a trigger pull of Java applications. The following steps are performed to achieve this functionality. The operator sets up a URL with the applications that they want to be pushed. Let us assume that this is snake.jar. The operator sets up a WML page with the reference pointing to snake.jad, the corresponding application descriptor file for snake.jar. Operator sends an SMSmessage to all the mobiles with the URL for snake.wml embedded inside. When the Synergy message center receives the message, it is treated as a browser message and the go to browser option is available. The user selects the Go To option to launch a browser that goes to theURL embedded inside the message. The browser loads the page setup by the operator. At this point, browse through the page and select the midlets to be downloaded. The download process is described in the chapter 32 download through the browser.
31 MIDP 2.0 Security Model
The following sections describe the MIDP 2.0 Default Security Model for the Motorola C381p handset. The chapter discusses the following topics: Untrusted MIDlet suites and domains Trusted MIDlet suites and domains Permissions Certificates
For a detailed MIDP 2.0 Security process diagram, refer to the Motocoder website (http://www.motocoder.com). Refer to the Table 26 for the default security feature/class support for MIDP 2.0: Feature/Class All methods for the Certificate interface in the javax.microedition.pki package All fields, constructors, methods, and inherited methods for the CertificateException class in the javax.microedition.pki package MIDlet-Certificate attribute in the JAD A MIDlet suite will be authenticated as stated in Trusted MIDletSuites using X.509 of MIDP 2.0 minus all root certificates processes and references Verification of RSA-1 signatures with a SHA-1 message digest algorithm Only one signature in the MIDlet-Jar-RSA-SHA1 attribute All methods for the Certificate interface in the javax.microedition.pki package All fields, constructors, methods, and inherited methods for the CertificateException class in the javax.microedition.pki package Will preload at least one self authorizing Certificates All constructors, methods, and inherited methods for the Supported Supported Supported Supported Implementation

Permissions within the above domains will authorize access to the protected APIs or functions. These domains will consist of a set of Allowed and User permissions that will be granted to the MIDlet suite.
Permission Types concerning the Handset
A protection domain will consist of a set of permissions. Each permission will be Allowed or User, not both. The following is the description of these sets of permissions as they relate to the handset: Allowed (Full Access) permissions are any permissions that explicitly allow access to a given protected API or function from a protected domain. Allowed permissions will not require any user interaction. User permissions are any permissions that require a prompt to be given to the user and explicit user confirmation in order to allow the MIDlet suite access to the protected API or function.
User Permission Interaction Mode
User permission for the Motorola C381p handsets is designed to allow the user the ability to either deny or grant access to the protected API or function using the following interaction modes (bolded term(s) is prompt displayed to the user): blanket grants access to the protected API or function every time it is required by the MIDlet suite until the MIDlet suite is uninstalled or the permission is changed by the user. (Never Ask) session grants access to the protected API or function every time it is required by the MIDlet suite until the MIDlet suite is terminated. This mode will prompt the user on or before the final invocation of the protected API or function. (Ask Once Per App Running) oneshot will prompt the user each time the protected API or function is requested by the MIDlet suite. (Always Ask)
No will not allow the MIDlet suite access to the requested API or function that is protected. (No Access)
The prompt No, Ask Later will be displayed during runtime dialogs and will enable the user to not allow the protected function to be accessed this instance, but to ask the user again the next time the protected function is called. User permission interaction modes will be determined by the security policy and device implementation. User permission will have a default interaction mode and a set of other available interaction modes. The user should be presented with a choice of available interaction modes, including the ability to deny access to the protected API or function. The user will make their decision based on the user-friendly description of the requested permissions provided for them. The Permissions menu allows the user to configure permission settings for each MIDlet when the VM is not running. This menu is synchronized with available run-time options.
Implementation based on Recommended Security Policy
The required trust model, the supported domain, and their corresponding structure will be contained in the default security policy for Motorolas implementation for MIDP 2.0. Permissions will be defined for MIDlets relating to their domain. User permission types, as well as user prompts and notifications, will also be defined.