Just An Application

March 27, 2011

“No MIDlet-<n> registration” ?

Filed under: Java, JME, Meta, MIDlets, MIDP, Push Registration — Tags: , , , , — Simon Lewis @ 9:36 am

This is another in the occasional series of meta or recursive posts prompted by the appearance of a specific query in the list of search terms used by people who have ended up here, despite the fact that I have not written about it.

In this case the query is the gnomic

No MIDlet-<n> registration

It looks as though it is probably an error message and it turns out that it is.

Like the subject of this post, it originates in the company formerly known as SUN‘s MIDP implementation.

If you do this at runtime

    PushRegistry.registerConnection("socket://:8888", "xper.midlet.Lamiel", "*")

but the only thing in the JAD and/or JAR manifest of your MIDlet suite is this

    MIDlet-1: UsefulMIDlet, UsefulMIDletIcon.png, xper.midlet.Colgrevance

and you are using the TCFKAS MIDP implementation then you will get a ClassNotFoundException with the message

    No MIDlet-<n> registration

even if the MIDlet suite JAR contains the class xper.midlet.Lamiel

Why ?

Because, as it says, in the documentation

The named MIDlet MUST be registered in the application descriptor or the JAR manifest with a MIDlet-<n> record.

Adding something like this

    MIDlet-2: PushableMIDlet, PushableMIDletIcon.png, xper.midlet.Lamiel

to the JAD and/or JAR manifest of the MIDlet suite in the example above would fix the problem.

The same problem, but not the same error message, occurs with static registration.

If the JAD and/or JAR manifest of the MIDlet suite only specifies these attributes

    MIDlet-1: UsefulMIDlet, UsefulMIDletIcon.png, xper.midlet.Colgrevance
    MIDlet-Push-1: socket://:8888, xper.midlet.Lamiel, *

then the MIDlet suite will not install.

As before, the second MIDlet needs to be registerd

    MIDlet-1: UsefulMIDlet, UsefulMIDletIcon.png, xper.midlet.Colgrevance
    MIDlet-2: PushableMIDlet, PushableMIDletIcon.png, xper.midlet.Lamiel
    MIDlet-Push-1: socket://:8888, xper.midlet.Lamiel, *

Note that the ordinals of the

    MIDlet-<n>

and

    MIDlet-Push-<n>

attributes do not have to match, they identify the attributes not the MIDlets.


Copyright (c) 2011 By Simon Lewis. All Rights Reserved.

Advertisements

March 18, 2010

MIDP 3.0 On Maemo 5: A TabbedPane And Some Lists … Again

Filed under: Java, JME, LCDUI, Maemo, MIDlets, MIDP, MIDP3, MIDP3LCDUI, Mobile Java, Qt — Tags: , , , , , , , — Simon Lewis @ 1:43 pm

It’s that MIDlet again. This time running on the Maemo5 emulator. The implementation code is identical to the Symbian version with vanilla Qt being used as the LCDUI back-end.





Copyright (c) 2010 By Simon Lewis. All Rights Reserved.

September 11, 2009

“MIDlet not constructed by createMIDlet.” ?

Filed under: Java, JME, MIDlets, MIDP, MIDP Implementation, Mobile Java — Tags: , , , , — Simon Lewis @ 11:23 am

This is a bit of a meta or recursive post in a way because it is prompted by my curiousity as to why the phrase

MIDlet not constructed by createMIDlet.

keeps turning up in the list of search terms used by people who have ended up here.

It is not really a generic term like some of the others which bring people here. For example

MIDP3

or

MIDlets on Android

or variations thereof.

It is pretty specific, and it is the same phrase everytime, but It is not one I’ve ever used here. So what does it match here and what is everyone looking for ?

Finding out what the search engines are matching here is easy enough. Type it in and see what they reference. The answer is this post

      What’s New In MIDP 3.0 ? Part 10: The MIDlet Lifecycle

which contains the terms “constructed”. “create”, and “MIDlet()”. Hence the match, but obviously not very useful given the actual search term.

Where does the search term itself originate ? Judging from some of the other search results it is an error message associated with a SecurityException thrown by Sun’s MIDP implementatation, so I’m guessing that people are seeing this exception and want to know what causes it.

The answer I suspect is that they are trying to create a MIDlet programatically and you are not allowed to do that as it says in the Throws clause of the documentation for the javax.microedition.midlet.MIDlet constructor

java.lang.SecurityException – unless the application management software is creating the MIDlet.

There are a good reasons for not allowing this. It would be very hard if not impossible to implement MIDP and ensure the correct lifecycle behaviour if MIDlets could be constructed programmatically.

Ironically it is actually pretty tricky to prevent it happening as well. As an implementor the only hook you have is the javax.microedition.midlet.MIDlet constructor which is in what is effectively a sealed package, but it can be done.

If you want to see exactly how Sun did it you can download their MIDP implementation as part of Phoneme Feature or Phoneme Advanced.

If you want to see how we (Symbian) did it, well unfortunately currently you can’t, which is a shame, because it was quite clever. Well at least I thought so, but then I would.

July 24, 2009

What’s New In MIDP 3.0 ? Part 38: Tied Operator MIDlets

Filed under: Java, JME, MIDlets, MIDP, MIDP3 — Tags: , , , , — Simon Lewis @ 8:51 am

At installation time a MIDlet Suite can be tied to a specific country and network using the

    MIDlet-Operator-Allowed

attribute.

The value must be a blank separated list of MCC/MNC pairs, where an MCC/MNC pair is a three digit MCC separated from a two or three digit MNC by a hyphen.

For example,

        234-15

Following a successful installation, MIDlets in the MIDlet Suite will not be excutable unless the current MCC and MNC correspond to one of the specified pairs.

This attribute only applies to MIDlet Suites bound to the Operator protection domain.


Copyright (c) 2009 By Simon Lewis. All Rights Reserved

July 23, 2009

What’s New In MIDP 3.0 ? Part 37: ScreenSaver MIDlets

Filed under: Java, JME, MIDlets, MIDP, MIDP3 — Tags: , , , , — Simon Lewis @ 8:03 pm

The ScreenSaver MIDlet Model

  • A ScreenSaver MIDlet is any MIDlet which has been declared with a type of screensaver at installation time.

  • A ScreenSaver MIDlet may be selected by the user as the current screen saver.

  • A ScreenSaver MIDlet is responsible for determining when it should be acting as the screen saver.

    • To do this it must determine

      1. whether it is the currently selected screen saver

      2. when the device enters and leaves screensaver mode

  • A MIDlet can determine whether it is the currently selected screen saver by calling it’s isSelectedScreenSaver() method.

  • A MIDlet can determine when the device enters and leaves screensaver mode by listening for EventData.SCREENSAVER_MODE events.

  • A ScreenSaver MIDlet will be started automatically if it is is the currently selected screen saver and it is not running when the device enters screen saver mode.

Notes

  1. It is not clear what behaviour is expected of a ScreenSaver MIDlet if it has access to multiple Displays.

  2. Although there is apparently a potential race-condition if a ScreenSaver MIDlet is started automatically when the device enters screen saver mode, the semantics of the EventManager.addEventListener() methods should help avoid this. As the EventManager class documentation says

    For system events, as soon as a listener is added or an application is registered to be launched the current value is checked. If the current value is matched, the listener MUST be immediately notified or the application is launched.

    If the ScreenSaver MIDlet uses the EventManager.addEventListener(String, EventDataListener, boolean) variant of the method to register for the EventData.SCREENSAVER_MODE eventthen it will be notified of current state of the device’s screen saver mode

  3. Listening for the EventData.SCREENSAVER_MODE requires an EventPermission for that event with an action of read. A MIDlet Suite containing a Screensaver MIDlet needs to ensure it requests that permission.

  4. In the javax.microedition.midlet package documentation, when describing the sequence of events that the screen saver MIDlet MAY expect it says

    The MIDlet’s Display capabilities are changed to indicate no further user input events will be delivered to the screen saver MIDlet.

    It is not clear whether capabilities in this context means the values returned by the Display.getCapabilities() method. The reference to Display and the use of the word indicate seem to imply that it does, but if so then it contradicts the Display documentation where it says

    A given Display’s capabilities are static; that is, they do not change over time or in response to the state of the device.

    If not then this should be made clear.


Copyright (c) 2009 By Simon Lewis. All Rights Reserved

What’s New In MIDP 3.0 ? Part 36: IdleScreen MIDlets

Filed under: Java, JME, MIDlets, MIDP, MIDP3 — Tags: , , , , , — Simon Lewis @ 11:52 am

The IdleScreen MIDlet Model

  • An Idlescreen MIDlet is any MIDlet which has been declared with a type of idlescreen at installation time.

  • A user may choose to add an Idlescreen MIDlet to the idle screen of a Display.

    • If the chosen MIDlet is not running when added then it will be started automatically.

  • An Idlescreen MIDlet can access the idle screen of a Display using an IdleItem.

  • An Idlescreen MIDlet which has been added to the idle screen of a Display but which does not access it using an IdleItem may be removed from the idle screen and terminated

  • A MIDlet which is not declared to be an Idlescreen MIDlet cannot access the idle screen of any of its Displays

Notes

  1. Should it have access to the idle screens of multiple Displays it is not clear how an Idlescreen MIDlet is supposed to determine which of them,
    if any, it is supposed to be responsible for displaying on.

  2. The javax.microedition.lcdui documentation says

    If a MIDlet that has not announced itself as an idle screen MIDlet with the JAD or JAR Manifest attribute
    tries to add content to the idle screen, the system MUST ignore this request.

    Presumably this means that any calls to Display.setIdleItem(IdleItem) will simply have no effect.


Copyright (c) 2009 By Simon Lewis. All Rights Reserved.

What’s New In MIDP 3.0 ? Part 35: AutoStart MIDlets

Filed under: Java, JME, MIDlets, MIDP, MIDP3 — Tags: , , , , , — Simon Lewis @ 8:54 am

An AutoStart MIDlet is any MIDlet which has been declared with a type of autostart at installation time.

An AutoStart MIDlet is started automatically at device start-up, and re-started automatically should it terminate, subject to resource limitations.

To declare a MIDlet as an AutoStart MIDlet the MIDlet Suite must have been granted the AutoStart permission. The default MIDP3 security policy does not permit MIDlet Suites bound to the Identified Third-Party protection domain or the Unidentified Third-Party protection domain to have this permission. By default therefore, only manufacturers and operators are going to be able to take advantage of the AutoStart MIDlet feature.


Copyright (c) 2009 By Simon Lewis. All Rights Reserved

What’s New In MIDP 3.0 ? Part 34: MIDlet Splash Screens

Filed under: Java, JME, MIDlets, MIDP, MIDP3 — Tags: , , , , , — Simon Lewis @ 7:38 am

1. Specifying A Splash Screen

At installation time it is possible to specify an image to be used as a splash screen during the launch of any MIDlet in the MIDlet Suite.

This is done by using the

    MIDlet-Splash-Screen-Image

attribute to specify a comma separated list of file names. Each name should be the absolute path of a file within the MIDlet Suite JAR containing an Image.

At runtime the list is traversed in the order specified and the first image, if any, that is successfully loaded is used as the splash screen.

Alternatively the value of the attribute can be specified as

    suppress

in which case there will be no visual indication that the MIDlet is being started.

2. Splash Screen Behaviour

The splash screen image is displayed automatically on the primary Display when the MIDlet is started by the user, and is guaranteed to be visible to the user by the time the MIDlet’s startApp() method is called.

It then remains visible until the MIDlet’s startApp() method returns, or the MIDlet shows a Displayable on the primary Display if this occurs first, or if the MIDlet’s primary Display is no longer in the foreground state.

The amount of time for which the splash screen has been visible to the user can be determined by calling the MIDlet’s getSplashScreenTime() method.


Copyright (c) 2009 By Simon Lewis. All Rights Reserved

June 23, 2009

What’s New In MIDP 3.0 ? Part 18: LCDUI – Displays

Filed under: Java, JME, LCDUI, MIDlets, MIDP, MIDP3, MIDP3API, MIDP3LCDUI — Tags: , , , , , , , — Simon Lewis @ 9:28 am

1. The Display Model

  • A device has one or more physical displays.

  • Each physical display may support sharable and non-sharable functionality.

  • The supported functionality may differ between physical displays.

  • A Display gives a MIDlet access to a fixed set of the functionality of a corresponding physical display.

  • A MIDlet will always have access to a primary display corresponding to the main physical display of the device.

  • If a device has additional physical displays a MIDlet will have access to corresponding secondary Displays.

  • If a physical display has two or more operating modes each with a discrete set of functionality a MIDlet will have access to those
    modes via two or more Displays.

2. Display Characteristics

2.1 Getting The Display’s Height

A Display’s height in pixels can be obtained by calling its

    public int getHeight()

method.

The value returned is the maximum height available for the display of a Displayable including its Title, Ticker, Commands and Menus, if present.

2.2 Getting The Display’s Width

A Display’s width in pixels can be obtained by calling its

    public int getWidth()

method.

The value returned is the maximum width available for the display of a Displayable including its Title, Ticker, Commands and Menus, if present.

2.3 Getting The Display’s Dot Pitch

A Display’s dot pitch can be obtained by calling its

    public int getDotPitch()

method.

The value returned is the distance between adjacent pixels in micrometers (1 x 10-6m).

2.4 Does The Display Support Pointer Events ?

Whether or not a Display supports Pointer events can be determined by calling its

    public boolean hasPointerEvents()

method.

The method returns true if the Display is capable of reporting Pointer pressed and released events.

Notes

  1. This method effectively supercedes the Canvas.hasPointerEvents() method. Whether Pointer events are supported by a Canvas is actually dependent upon the Display on which the Canvas is currently visible.
  2. It is not clear why, other than for convenience, this functionality is not implemented using the capabilites mechanism.

2.5 Does The Display Support Pointer Motion Events ?

Whether or not a Display supports Pointer Motion events can be determined by calling its

    public boolean hasPointerMotionEvents()

method.

The method returns true if the Display is capable of reporting Pointer motion eventst.

Note

  1. This method effectively supercedes the Canvas.hasPointerMotionEvents() method. Whether Pointer motion events are supported by a Canvas is actually dependent upon the Display on which the Canvas is
    currently visible.
  2. It is not clear why, other than for convenience, this functionality is not implemented using the capabilites mechanism.

2.6 Is The Display Built-in ?

Whether or not the corresponding physical of a Display is built-in can be determined by calling its

    public boolean isBuiltIn()

method.

The method returns true if the corresponding physical display is built-in, that is, if it is an integral part of the device. If it is then the corresponding Display will never become unusable as the result of the removal of the corresponding physical display.

3. Display Capabilities

The functionality supported by a given Display is specified at runtime using capabilities, where a capability typically represents a discrete LCDUI feature.

The following capabilities are defined as constants in the Display class.

  • SUPPORTS_ALERTS
  • SUPPORTS_COMMANDS
  • SUPPORTS_FILESELECTORS
  • SUPPORTS_FORMS
  • SUPPORTS_IDLEITEM
  • SUPPORTS_INPUT_EVENTS
  • SUPPORTS_LISTS
  • SUPPORTS_MENUS
  • SUPPORTS_ORIENTATION_LANDSCAPE
  • SUPPORTS_ORIENTATION_LANDSCAPE180
  • SUPPORTS_ORIENTATION_PORTRAIT
  • SUPPORTS_ORIENTATION_PORTRAIT180
  • SUPPORTS_TABBEDPANES
  • SUPPORTS_TEXTBOXES
  • SUPPORTS_TICKER
  • SUPPORTS_TITLE

The constants are bit-flags and can be combined using bit-wise OR.

A MIDlet’s primary Display will support all LCDUI features but a secondary Display may not.

All Displays provides basic Canvas support.

The capabilities of a Display are fixed.

3.1 Getting A Display’s Capabilities

A Display’s capabilities can be obtained using its

 public int getCapabilities()

method.

The return value will either be the bit-wise OR’ed combination of the supported capabilities, or 0 indicating that the Display only provides basic Canvas support.

3.2 DisplayCapabilityException

A DisplayCapabilityException is thrown when an attempt is made to perform an operation which directly or indirectly involves a Display which does not support the functionality required for the operation. For example, passing an instance of Form to the setCurrent() method of a Display which does not support Forms.

4. Display State

A Display can be in one of three states

  • Foreground,
  • Background, or
  • Visible

depending upon its current level of access to the functionality of the corresponding physical display.

4.1 Foreground

If a Display is in the Foreground state then it currently has exclusive access to all non-sharable functionality of the corresponding physical display, and first-call on any sharable functionality.

4.2 Background

If a Display is in the Background state then it currently has no access to the functionality of the corresponding physical display.

4.3 Visible

If a Display is in the Visible state then it has access to at least one pixel of the corresponding physical display, but it has no access to any of the non-sharable functionality.

4.4 Runtime Constants

The possible display states are represented by the following constants defined in the Display class

  • STATE_BACKGROUND
  • STATE_FOREGROUND
  • STATE_VISIBLE

4.5 Getting The Current Display State

The current state of the Display can be obtained using the Display’s

    public int getDisplayState()

method which will return one of the constants listed above.

5. Hardware State

The hardware state of a Display is equivalent to the state of the corresponding physical display.
The physical display may be

  • Enabled,
  • Disabled, or
  • Absent

The hardware state of a MIDlet’s primary display will never be Absent.

5.1 Enabled

If the hardware state of a Display is Enabled then the functionality of the corresponding physical display is available to the Display.

5.2 Disabled

If the hardware state of a Display is Disabled then the functionality of the corresponding physical display is not available to the Display.

5.3 Absent

If the hardware state of a Display is Absent then the corresponding physical display is no longer available and the Display itself is no longer usable.

5.4 Runtime Constants

The possible hardware states are represented by the following constants defined in the Display class

  • DISPLAY_HARDWARE_ABSENT
  • DISPLAY_HARDWARE_DISABLED
  • DISPLAY_HARDWARE_ENABLED

5.5 Getting The Current Hardware State

The current hardware state of a given Display can be obtained used the Display’s

    public int getHardwareState()

method which will return one of the constants listed above.

6. Activity Mode

The activity mode of a Display may be either Normal or Active.

If a Display is in the Foreground state and its activity mode is Normal then the corresponding physical display may enter a reduced functionality power-saving state if the current power management policies of the device allow it.

If a Display is in the Foreground state and its activity mode is Active then the corresponding physical display should remain in a fully functional state.

If a Display in the Foreground state changes its activity mode from Normal to Active and the corresponding physical display is in a power-saving state it should return to a fully functional state.

The possible activity modes are represented by the following constants defined in the Display class.

  • MODE_ACTIVE
  • MODE_NORMAL

6.1 Getting The Current Activity Mode

The current activity mode of a Display can be obtained by calling it’s

    public int getActivityMode()

method which will return one of the runtime constants listed above.

6.2 Setting The Current Activity Mode

The current activity mode of a Display can be set by calling it’s

    public void setActivityMode(int mode)

method.

The mode argument must be one of the constants listed above.

7. Display Orientation

A Display may support more than one orientation.

Possible orientations are

Landscape Display’s width is greater than its height
Landscape 180 Landscape with content rotated through 180 degrees
Portrait Display’s height is greater than its width
Portrait 180 Portrait with content rotated through 180 degrees

The orientations supported by a Display can be determined by calling its getCapabilities() method.

7.1 Runtime Constants

The possible orientatations are represented by the following constants defined in the Display class

  • ORIENTATION_LANDSCAPE
  • ORIENTATION_LANDSCAPE180
  • ORIENTATION_PORTRAIT
  • ORIENTATION_PORTRAIT180

7.2 Getting The Orientation

The current orientation of the Display can be obtained by calling its

    public int getOrientation()

method which will return one of the constants listed above.

7.3 Setting The Preferred Orientation

The preferred orientation of a Display can be set using its

    public void setPreferredOrientation(int orientation)

method where orientation must be one of the constants listed above.

Note

It is not clear from the specification exactly what setPreferredOrientation() does. It states

This call may not have an effect on the actual orientation of the display if the specified orientation is not supported on the device.

It then goes on to say

The application may use getOrientation() to detect the actual orientation of the display after this call.

which would seem to imply that it is not guaranteed to do anything even if the specified orientation is supported by the Display.

More generally it is not clear what it means for a Display to support a given orientation. One possible interpretation is that if a Display supports more than one orientation, then, if the orientation of the Display changes it will automatically re-render all visible UI elements appropriately. This would seem to make sense as there is no API by which a MIDlet could achieve the same effect. Other aspects of the UI such as the size of the UI elements are potentially under the control of the MIDlet and are presumably, therefore, its responsibility.

8. Display Events

A MIDlet can listen for the addition of secondary Displays, and for changes in the

  • display state
  • hardware state
  • orientation
  • size

of individual Displays using an instance of the DisplayListener interface.

All Display events are serialized with respect to other LCDUI events.

Note

An orientation change may also result in a size change, but the specification does not explicitly state that the resulting events must occur in a particular order.

8.1 Adding A DisplayListener

A MIDlet can begin listening by using the Display method

    public static void addDisplayListener(DisplayListener l)

to add a DisplayListener.

8.2 Removing A DisplayListener

A MIDlet can stop listening using the Display method

    public static void removeDisplayListener(DisplayListener l)

to remove a DisplayListener added previously.

8.3 DisplayListener

Events are reported to a DisplayListener using event specific methods as follows.

8.3.1 Addition

The addition of secondary display is reported via the

    public void displayAdded(Display d)

method.

8.3.2 State Changes

Changes to the state of a Display are reported via the

    public void displayStateChanged(Display d, int newState)

method.

The newState argument will be one of the Display state runtime constants.

8.3.3 Hardware State Changes

Changes to the hardware state of a Display are reported via the

    public void hardwareStateChanged(Display d, int newState)

method.

The newState argument will be one of the Hardware state runtime constants.

8.3.4 Orientation Changes

Changes to the orientation of a Display are reported via the

     public void void orientationChanged(Display d, int newOrientation)

method.

The newOrientation argument will be one of the Orientation runtime constants.

8.3.5 Size Changes

Changes to the size of a Display are reported via the

    void sizeChanged(Display d, int w, int h)

method.

The arguments w and h are the new width and height of the Display respectively.

9. Getting Displays

9.1 Getting The Primary Display

The existing Display method

    public static Display getDisplay(MIDlet m)

will return the primary Display for the given MIDlet.

9.2 Getting Displays With Specific Capabilities

The new Display method

    public static Display[] getDisplays(int capabilities)

can be used to obtain a list of all the Displays currently available, or a list of those which support a specified set of capabilities.

If capabilities is 0 then a list available Displays will be returned, with the primary Display first.

If capabilities is a bit-wise ORed combination of the runtime constants representing capabilities, then the list of Displays supporting those capabilities will be returned, with the primary Display first.

Note

The method documentation states

Since the Primary Display must support all capabilities, it is always returned as the first element regardless of the capabilities requested.

For this to be true the Primary display must not only support all the LCDUI features, but all the possible orientations as well. It is not clear what supporting all possible orientations entails nor whether it is necessarily feasible on every device.

10. Transient Secondary Displays

The physical display corresponding to a secondary Display can become unavailable. In this case the hardware state of the secondary Display will change to Absent. Once this happens the secondary Display is no longer usable, and calls to methods such as setCurrent(Displayable) will throw an IllegalStateException.

If the physical display corresponding to the secondary Display becomes available again it
will be reported as a new Display via a call to the DisplayaListener.displayAddedd(Display) method.

12. Backwards Compatibility

Some existing methods now throw new exceptions. For example, Display.setCurrent(Displayable) can now throw a DisplayCapabiltyException or an IllegalStateException. However, as required to ensure binary compatibility, all new exceptions thrown are RuntimeExceptions. In addition these exceptions cannot occur when using the Primary display which is the only Display that a legacy MIDlet has access to,


Copyright (c) 2009 By Simon Lewis. All Rights Reserved.

June 19, 2009

What’s New In MIDP 3.0 ? Part 17: Preventing Users From Starting And Stopping MIDlets

Filed under: Java, JME, MIDlets, MIDP, MIDP3 — Tags: , , , , , , — Simon Lewis @ 6:27 pm

A user can be prevented from starting and/or stopping a given MIDlet.

This can be done by using a

    MIDlet-<n>-UserDenied

attribute corresponding to the

    MIDlet-<n>

attribute used to declare the MIDlet itself.

It is an error if a MIDlet-<n>-UserDenied attribute is specified without a corresponding MIDlet-<n> attribute and installation will fail.

The value of the attribute must be a comma separated list of actions, where an action is one of

  • run
  • stop

If the run action is specified then a user will not be able to start the MIDlet using the device’s application launcher.

If the stop action is specified and a device supports application management level functionality for stopping applications then the user will not be able to use that functionality to stop the MIDlet. It does not affect the user’s ability to stop the MIDlet using functionality provided by the MIDlet itself via the UI, if any.

To specify a MIDlet-<n>-UserDenied attribute or attributes a MIDlet Suite must have been granted the ActionsDeniedPermission.

The specified MIDP 3 security policy does not make it possible for MIDlet Suites bound to either the Identified Third Party or the Unidentifed Third Party protection domains to be granted the ActionsDeniedPermission under any circumstances.

Older Posts »

Blog at WordPress.com.

%d bloggers like this: