Showing posts with label J2ME. Show all posts

Showing posts with label J2ME. Show all posts

J2ME and I

One of the reasons I've not been blogging regularly recently is that I've been learning J2ME. The two books helped me a lot. The first is more organized and gives a good overview of J2ME. It clearly explains the differences between CLDC 1.1 and 1.0 and MIDP 2.0 and 2.1. It also covers security, deployment and the Push Registry in ample detail.

Knudsen's book is a more interesting read with chapters on Bluetooth and SMS Messaging. What's more I made it through the J2ME exam affectionately called Sun Certified Mobile Access Developer for the J2ME platform or sometimes called Sun Certified MAD exam. These books were a big help.

MIDlet Methods

startApp can fail in 2 ways

Transient

at a certain point in time(lack of conn, res,etc.)
javax.midlet.MIDletStateChangedException

Non-Transient

unexpected and uncaught runtime error
Such errors are propogated back to system that it will destroy midlet immediately and call destroyApp.

Midlet States

3 distinct phases

Paused:

Just been constructed and not yet entered startApp
Can be in paused state after a call to pauseApp or notifyPaused methods
Should hold as few resources in this state
Can receive asynchronous notifications like a timer firing

Active

After entry to startApp
moves from Paused to Active after a call to resumeRequest
Can allocate and hold all resources for active execution

Destroyed

After return from destroyApp or notifyDestroyed
Cannot reenter any other state.
Replaces System.exit which will throw a java.lang.SecurityException

Midlet states can be triggered by MIDP or requests from app.
All states except startApp complet after return from caller

Midlet App Model

MIDlet - basic unit of execution
Extends javax.microedition.midlet
Implements

startApp
pauseApp
destroyApp

Can have a constructor which CANNOT handle exceptions
Must implement the 3 abstract lifecycle methods
can implement Command Listener Interface (along with TextBox, Command and Display -part of javax.microedition.lcdui classes.

Midlet Suite Security

Assumptions on MIDlets

Need not be aware of security policy except for security exceptions
Subject to 1 protection domain and permissions
Internal representation of domain is implementation specific
UI and results of authentication attempts to user out of MIDP scope
Device must protect its security policy and domain info
For static security policies, unused security functions may be eliminated on device
Security policy not to be used for security sensitive functionality, merely to restrict access.

Sandboxes and Trust

MIDP 1.0 MIDlets operate as untrusted on MIDP 2.0 devices
Untrusted Midlets: Cannot access protected API/Functions. Restricted environment-untrusted domain,
javax.microedition.io.HttpConnection and HttpConnection APIs require confirmation from untrusted MIDlets.
Trust determination is device specific.
Trusted Apps have increased access to protected APIS

Permissions and APIS

Permissions Restricted API

Javax.microedition.io.Connector Java.microedition.io

http HttpConnection

https HttpsConnection

datagram UDPDatagram

datagramReceiver UDPDatagram

socket SocketConnection

serversocket ServerSocketConnection

ssl SecureSocketConnection

PushRegistry PushRegistry

Permission Names

Case sensitive
Each API defines its own permissions

Requesting permissions

MIDlet Permissions specified in JAD/ Jar manifest
MIDlet-Permission/MIDlet-Permisssion-Opt used to specify permissions

Comma separated, leading/trailing spaces ignored.
If both are set, their values must be identical.

All requested critical permissions must be known and present. Otherwise the suite is not installed.

Protection Domains

Defines permission sets, interaction modes.
2 types

Allowed: All protection domain suites allowed access
User: Access only after user auth. - User prompt that user can allow/deny

Interaction Modes for User Permisssions

blanket: Grant perms for every interaction
session: Grant perms until MIDP terminates
oneshot: only current invocation- prompt user for each invocation of protected API.

Interaction determined by device security policy.

Non Security Sensitive APIs: javax.micoredition.rms, midlet, lcdui, lcdui.game, media, media.control

CLDC Security

Three levels

Low Level Security(virtual Machine Security)

Apps follow Java Semantics
Ill formed code does not crash JVM

App Level Security

Code can only access features and functions it is allowed to

End To End Security

Transactions initiated on device protected(Out of CLDC scope)

Features not in the J2ME JVM

User Defined Class Loaders
Thread Groups & Daemon Threads
Finalization
Asynchronous Exceptions

CLDC (Connected Limited Device Configuration)

CLDC Scope

JVM and Java Language
Internationalization
I/O
Networking
Security
Internationalization

Requirements

CLDC 1.1 requires 192K total memory(1.0 required 160K)
16/32 bit processor
Low power OS
some sort of connectivity

CLDC libraries

System (java.lang)

Object
Class
Runtime
System
Thread
Runnable
String
String Buffer
Throwable

Data Type(java.lang)

Boolean
Byte
Short
Long
Integer
Character
Double*
Float*

*New in CLDC 1.1

Collections(util)

Vector
Stack
Hashtable
Enumeration

I/O(java.io)

InputStream
OutputStream
ByteArrayInputStream
ByteArrayOutputStream
DataInput
DataOutput
DataInputStream
DataOutputStream
Reader
Writer
InputStreamReader
OutputStreamReader
PrintStream

Calendar/Time(util)

Calendar
Date
TimeZone

CLDC1.1

Math(for floating pt ops.)
Random

References(java.lang.ref)

Reference
Weak Reference

Error Classes(java.lang)

Error
NoClassdefFoundError(new to CLDC 1.1)
OutOfMemoryError
Virtual Machine Error

CLDC Generic Connection Framework framework

Generalization of J2SE NW and I/O framework
Can map to low level hardware/J2SE classes
General Form

Connector.open(":

;");

Static function

No network protocols defined in CLDC
Bulk of App code stays same for diff protocols
Protocol Binding done at runtime.
Implemented as a hierarchy of connection interfaces(7)
One exception class: ConnectorNotFound

Classes and Interfaces

Interface Connection- Basic Connection

public void close() throws IOException;

Interface InputConnection- Device with data read capability

public InputStream openInputStream() throws IOException;
public DataInputStream openDataInputStream() throws IOException;

Interface OutputConnection- Device with Data write capability

public OutputStream openOutputStream() throws IOException;
DataOutputStream openDataOutputStream() throws IOException;

Interface StreamConnection-Combines InputConnection & OutputConnection
Interface ContentConnection -Sub interface of StreamConnection-Access to HTTP metadata

public String getType();
public String getEncoding();
public long getLength();

Interface StreamConnectionNotifier

public StreamConnection acceptAndOpen() throws IOException;

Interface DatagramConnection -Datagram endpoint

public int getMaximumLength() IOException;
public int getNominalLength() IOException;

Other functions for

send,
receive,
4 newDatagram(with params byte, size, address)

Datagram type

has a data buffer associated with it.
Use DataInput and DataOutput.
Can behave like a stream

CLDC Error Handling

VM halts in implementation specific manner
VM throws error closest to nearest CLDC Error Superclass

Exceptions

Supports exception handling defined by JVM.
No Asynchronous exceptions

Goals Requirements and Scope of J2ME

JHighly portable, secure, small app. dev. env.

CLDC goals

Lowest common denominator platform
targets all kinds of small connected devices
Device category independent.
Generic Connection framework

MIDP goals

Wireless mobile communication devices
Meaningful high level abstractions
Mask lower level network transmission protocols(GSM, TDMA. CDMA PDC)
Build on Generic Framework

J2ME goals

Extensible customizable devices
Dynamic delivery of apps, content

CLDC Software Requirememts:

Assumes os/kernel available
OS provides atleast one schedulable entry.
No need- separate address spaces/processes

MIDP Software requirements

Kernel/OS
Mechanism to R/W non-volatile memory
R/W access to NW
Mechanism to provide time-base for timestamping records written to perm. storage
Ability to write to bit-mapped graphical display
Mechanism to capture user input

Scope of CLDC

Java language and VM features
Core libraries
I/O
Networking
Security
Internationalization

Does NOT address

App lifecycle mgmt.
UI functionality
Event handling
High level app model

MIDP Scope

App Model
UI
Persistent Storage
Networking
Timer

MIDP 2.0

Sounds
2D games
MIDLet Signing
end-end HTTPS security
App delivery and installation

Also

System level APIs
Low level security
App level cryptography

rich dynamic interactive content from 3rd party developers, content providers
Secure development of dynamic content

CLDC MIDP Packages

CLDC 1.1

java.lang
java.lang.ref
java.util
javax.microeditiom.io

MIDP 2.0

javax.microedition.lcdui
javax.microedition.lcdui.game
javax.microedition.media
javax.microedition.media.control
javax.microedition.midlet
javax.microedition.pki
javax.microedition.rms

J2ME

J2ME made of profiles, configurations and optional APIs.(Together called a Stack)
Configuration

memory size and processing power
Subset of Java 2
JVM

Profiles

Additional APIs for UI, persistent storage, etc.

CLDC

160-512K Total memory
Minimum 160K RAM, 32K ROM

JVM (KVM)Limitations

Native methods cannot be added at runtime.
Only has a subset of bytecode verification- The task of verifying classes -split between CLDC device and external mechanism

MIDP

>= 256K ROM
>= 128K RAM for Java runtime heap
>= 8K non volatile permanent storage
96*54 pizel screen size
Some capacity for keypad, screen i/p
2 way NW connection possibly intermittent.

Understanding JSR 185 - Quick notes

Reduces fragmentation
Improves interoperability
Foundation for next gen. devices.
Functionality

Required

CLDC 1.o

MIDP 2.0

WMA 1.1

Optional

MMAPI

Size

JAR 64KB
JAD 5KB
Persistent Storage 30KB
Devices can use more but one cannot expect more.
Heap size 128K required, 256K Recommended.

Tickers(wake-up timers)

Open ended in MIDP not required

UI

Screen size

96X54 screen size, 1 bit color depth required
125X125 required, 12 bit color depth recommended
JSR 185 jpeg support, MIDP png support

Text Messaging

SMS capability required on GSM/UMTS networks
Text box, Text field required.
Phone book capability required to fill text field required on MIDLet.

Multimedia

MMAPI
MIDI and tone sequence support
8 bit 8Khz mono PCM WAV supprt required for audio capture
JPEG support

Security

Vague about protected domain defintion
Specifies GSM/UMTS device behavior on untrusted code

Class File Verification

Step1: Preverification-Typically done on developer workstation.

Move some bytecodes, augment Class files with Stack Map attributes

Step 2: Runtime Verification

Actual class verification done via Stack Map attrs. generated in Step 1
Execution only begins after runtime verification
Runtime verification guarantees type safety
Verification verifies that all bytecodes of class files are inlined.- makes verification faster.

Other CLDC Security features

Programmer cannot bypass standard class loading mechanisms on device while downloading
Programmer can use closed predefined Java API defined by J2ME and manufacturer specific classes
Programmer cannot download new native library functionality.
Programmer cannot override/modify system class packages(java.*, java.microedition.*), profile specific packages or class file lookup.
CLDC can load classes only from its jar file. - Java app cannot interfere or steal data from other apps. 3rd parties cannot gain access to private, protected classes that are provided by manufacturer.

Subscribe to: Posts (Atom)