MOBILE COMPUTING

UNIT-V

ULEMU MPONELA
DMI ST JOHN THE BAPTIST UNIVERSITY
Contents
WIRELESS DEVICES WITH SYMBIAN OS .......................................................................................... 5
SYMBIAN OS ARCHITECTURE........................................................................................................... 5
1. Kernel Layer ........................................................................................................................... 5
2. Base Services Layer ................................................................................................................ 5
3. OS Services Layer .................................................................................................................. 6
4. Application Services Layer.................................................................................................... 6
5. Java ME (Micro Edition) ...................................................................................................... 6
6. Application Layer .................................................................................................................. 6
7. UI Framework ....................................................................................................................... 7
Symbian OS Characteristics .......................................................................................................... 7
Applications of Symbian OS ........................................................................................................ 7
a) Productivity Applications ..................................................................................................... 7
b) Communication Applications .............................................................................................. 7
c) Multimedia Applications ...................................................................................................... 7
d) Navigation Applications ....................................................................................................... 8
e) Social Media Applications .................................................................................................... 8
f) Gaming Applications ............................................................................................................ 8
g) Utility Applications ............................................................................................................... 8
h) Photography and Video Applications ................................................................................ 8
i) Finance and Banking Applications ...................................................................................... 8
j) Health and Fitness Applications .......................................................................................... 9
k) Travel and Lifestyle Applications ........................................................................................ 9
l) Educational Applications ...................................................................................................... 9
CONTROLS AND COMPOUND CONTROLS .......................................................................... 9
Controls in Symbian OS ............................................................................................................... 9
Compound Controls in Symbian OS ........................................................................................ 10
Key Concepts of Active Objects ................................................................................................ 10
Structure of an Active Object .................................................................................................... 11
Constructor: ................................................................................................................................. 11
Destructor: ................................................................................................................................... 11
RunL():.......................................................................................................................................... 11
DoCancel():.................................................................................................................................. 11
SetActive(): ................................................................................................................................... 11
LOCALIZATION .......................................................................................................................... 11

P a g e 1 | 28
 Key Concepts of Localization in Symbian OS .......................................................................... 11
SECURITY ON SYMBIAN OS .................................................................................................... 12
Key Components of Symbian OS Security ............................................................................... 12
Platform Security Architecture ................................................................................................... 12
Capabilities................................................................................................................................... 12
Certificate-Based Signing ............................................................................................................ 13
Data Caging ................................................................................................................................. 13
Software Installer Security .......................................................................................................... 13
Trusted Computing Base (TCB) ................................................................................................. 13
ANDROID OPERATING SYSTEM ..................................................................................................... 14
Features of Android Operating System .................................................................................... 14
1. Near Field Communication (NFC) ................................................................................... 14
2. Infrared Transmission ......................................................................................................... 14
3. Automation.......................................................................................................................... 15
4. Wireless App Downloads ................................................................................................... 15
5. Storage and Battery Swap .................................................................................................. 15
Custom Home Screens................................................................................................................ 15
Widgets ........................................................................................................................................ 15
6. Custom ROMs ..................................................................................................................... 15
Architecture of Android OS ....................................................................................................... 15
a) Applications ......................................................................................................................... 16
b) Application framework ...................................................................................................... 16
c) Application runtime ............................................................................................................ 17
d) Platform libraries ................................................................................................................. 17
e) Linux Kernel ......................................................................................................................... 18
JAVA MICRO EDITION ..................................................................................................................... 18
How Java ME is organized ............................................................................................................ 18
Java ME architecture ...................................................................................................................... 19
Configurations in Java ME ............................................................................................................. 20
Meaning of Connected Limited Device Configuration .............................................................. 20
 Screen Size and Resolution Variability:............................................................................. 22
 Limited Graphics Capabilities: ........................................................................................... 22
 Input Methods and Navigation:. ...................................................................................... 22
 Limited Memory and Performance: ................................................................................. 22
 Cross-Device Compatibility: .............................................................................................. 23

P a g e 2 | 28
  Usability and Accessibility: ................................................................................................. 23
 Resource Management: ...................................................................................................... 23
MOBILE INFORMATION DEVICE PROFILE ................................................................................... 23
Key Takeaways ................................................................................................................................ 23
Importance....................................................................................................................................... 23
MIDP in Detail................................................................................................................................. 24
Examples of MIDP .......................................................................................................................... 24

P a g e 3 | 28
Unit V
Wireless Devices with SYMBIAN OS: Introduction – Symbian OS Architecture –
Applications for Symbian – Control and Compound Controls – Active Objects –
Localization – Security on the Symbian OS.
Programming for the Android OS: Introduction – Android Architecture – Application
Development.
J2ME: JAVA in the Handset – Three-Prong Approach to Java Everywhere, Java 2
Micro Edition (J2ME) – Programming for CLDC – GUI in MIDP – UI Design Issues –
Multimedia – Record Management System – Communication in MIDP – Security
Considerations in MIDP – Optional Packages

P a g e 4 | 28
 WIRELESS DEVICES WITH SYMBIAN OS
The Symbian OS was an operating system designed for mobile devices, primarily
smartphones. It was developed by Symbian Ltd., a consortium of mobile phonemodels,
including Nokia, Ericsson, and Motorola. Symbian OS was widely used in the early
2000s and offered a range of features and capabilities for mobile devices. The OS of
Symbian contains two components: microkernel and user interface. The Symbian OS
was written in C++ language.

SYMBIAN OS ARCHITECTURE

1. Kernel Layer
The Kernel Layer is the core of Symbian OS, responsible for low-level operations and
hardware interaction. It includes:

 Microkernel: Manages basic operations such as task scheduling, memory

management, and interrupt handling.
 Hardware Abstraction Layer (HAL): Provides a uniform interface to the
underlying hardware, making it easier for the OS to run on different devices.
 Device Drivers: Interfaces to control hardware components like display,
keyboard, network, and storage.
2. Base Services Layer
The Base Services Layer provides fundamental services required by higher layers of the
operating system. Key components include:

 File Server: Manages file operations and storage.

 User Library: Provides basic functions for application development, such as
string handling, error management, and process control.
 E32: The main library for kernel services, providing APIs for tasks like thread
management, inter-process communication (IPC), and active objects.
 Memory Management: Handles memory allocation, paging, and virtual
memory.
P a g e 5 | 28
 3. OS Services Layer
The OS Services Layer offers additional system services and APIs that extend the
functionality provided by the Base Services Layer. Components include:

 Multimedia Framework: Manages audio, video, and imaging services.

 Networking and Communication: Provides APIs for network communication,
including TCP/IP, Bluetooth, and telephony services.
 Telephony Services: Manages telephony functions and interfaces with the
underlying cellular hardware.
 Messaging Framework: Supports SMS, MMS, email, and other messaging
services.
 Location Services: Provides APIs for GPS and other location-based services.
4. Application Services Layer
The Application Services Layer provides services specifically aimed at supporting
applications. This includes:

 UI Framework: Includes libraries for building graphical user interfaces (GUIs),

such as the AVKON and Quartz frameworks.
 Application Engines: Engines for specific application types, like contacts,
calendar, and multimedia.
 PIM (Personal Information Management): Services for managing personal
information like contacts, appointments, and tasks.
 Data Synchronization: Supports synchronization of data between the device and
external services.
5. Java ME (Micro Edition)
Symbian OS includes support for Java ME, allowing applications written in Java to run
on the platform. This layer includes:

 Java Virtual Machine (JVM): Runs Java applications and provides a runtime
environment.
 Java APIs: Libraries and APIs specifically designed for mobile applications.
6. Application Layer
The Application Layer consists of the end-user applications and utilities that run on the
device. These include:

 Built-in Applications: Core applications such as phone, messaging, contacts,

calendar, web browser, and media player.
 Third-party Applications: Applications developed by third-party developers and
installed by users.

P a g e 6 | 28
 7. UI Framework
Symbian OS uses different UI frameworks depending on the device and manufacturer.
The main UI frameworks include:

 Series 60 (S60): Used primarily by Nokia devices, it provides a comprehensive

set of UI components and controls.
 UIQ: A UI platform used by Sony Ericsson and Motorola, featuring touch and
stylus-based input.
 MOAP: Used by Japanese manufacturers, primarily for NTT DoCoMo's FOMA
phones.

Symbian OS Characteristics
 Multitasking: Supports running multiple applications simultaneously.
 Memory Management: Efficient use of limited memory resources with advanced
memory management techniques.
 Power Management: Designed to optimize power usage and extend battery life.
 Security: Implements a robust security model, including application signing and
capabilities-based access control.

Applications of Symbian OS
There is a wide range of applications that were used for Symbian OS. It spanned a wide
range of areas as specified below;
a) Productivity Applications
 Quickoffice: Allowed users to view and edit Microsoft Office documents,
including Word, Excel, and PowerPoint files.
 Adobe Reader: Enabled viewing of PDF documents on mobile devices.
 Evernote: Provided note-taking capabilities, allowing users to organize notes,
photos, and voice memos.
 Nokia Communicator: Integrated email client supporting multiple accounts
and corporate email solutions.
 Calendar and Contacts: Core Symbian applications for managing
appointments, schedules, and contacts.
b) Communication Applications
 WhatsApp: Offered messaging and multimedia sharing.
 Skype: Provided VoIP calls, instant messaging, and video calls.
 Fring: Enabled multi-protocol instant messaging and VoIP.
 Gmail for Mobile: Allowed access to Gmail accounts with a mobile-optimized
interface.
 Nimbuzz: Combined instant messaging, voice calling, and social networking.
c) Multimedia Applications
 RealPlayer: A media player supporting various audio and video formats.
 YouTube: The official app for streaming YouTube videos.

P a g e 7 | 28
  Ovi Music Store: Nokia's music download service for purchasing and
downloading music tracks.
 CameraPro: An advanced camera app with professional features like burst
mode, time-lapse, and manual settings.
 CorePlayer: A versatile multimedia player supporting a wide range of media
formats.
d) Navigation Applications
 Nokia Maps (later HERE Maps): Provided comprehensive mapping,
navigation, and local search functionalities.
 Garmin Mobile XT: Offered GPS navigation with turn-by-turn directions.
 Google Maps: Enabled mapping, local search, and navigation features.
 Wayfinder Navigator: A turn-by-turn navigation app with global coverage.
e) Social Media Applications
 Facebook: Allowed users to access their Facebook accounts, update status,
and interact with friends.
 Twitter: Provided access to Twitter, enabling tweeting, following, and direct
messaging.
 LinkedIn: For professional networking, job searching, and connecting with
colleagues.
f) Gaming Applications
 Angry Birds: A highly popular puzzle game involving birds and pigs.
 Asphalt 5: A racing game with various cars and tracks.
 N.O.V.A.: A sci-fi first-person shooter game.
 Worms: A turn-based strategy game.
 Tetris: The classic puzzle game optimized for mobile play.
g) Utility Applications
 Opera Mini: A web browser optimized for mobile devices with data
compression technology.
 F-Secure Mobile Security: Provided antivirus and security features for
Symbian devices.
 File Manager: For managing files and folders on the device.
 Handy Taskman: A task manager for monitoring and controlling running
applications.
 SmartLight: An application to control the device's screen backlight.

h) Photography and Video Applications

 Vignette: An application for adding vintage effects to photos.
 Qik Video: For live video streaming and sharing.
 PhotoFunia: Allowed users to apply fun effects to photos.
 Panorama: An app for taking panoramic photos.
i) Finance and Banking Applications
 mBank: Mobile banking application for various financial institutions.
P a g e 8 | 28
  ExpenseManager: For tracking and managing personal expenses.
 Bloomberg: Provided financial news, stock market updates, and investment
tracking.
 XE Currency: For real-time currency exchange rate tracking.
j) Health and Fitness Applications
 Sports Tracker: For tracking workouts and fitness activities using GPS.
 Calorie Counter by FatSecret: For tracking diet, calories, and nutrition.
 Yoga Trainer Lite: Provided yoga training sessions and routines.
 Sleep Cycle: A sleep tracking app to monitor sleep patterns and wake up
users during light sleep.
k) Travel and Lifestyle Applications
 TripAdvisor: For finding travel recommendations, reviews, and planning
trips.
 WeatherBug: Provided weather forecasts, alerts, and updates.
 WorldMate: A travel organizer with flight, hotel, and itinerary management.
 [Link]: For booking hotels and accommodations.
l) Educational Applications
 Dictionary and Thesaurus: For looking up words, definitions, and synonyms.
 Duolingo: A language learning application offering courses in various
languages.
 Wikipedia: Access to Wikipedia articles in a mobile-friendly format.
 Khan Academy: Educational content including videos and exercises on
various subjects.

CONTROLS AND COMPOUND CONTROLS

In Symbian OS, the concept of controls and compound controls is essential for creating
graphical user interfaces (GUIs). These constructs allow developers to build interactive
and complex user interfaces by combining simple and more complex elements. Below
is a detailed explanation of both controls and compound controls in Symbian OS.

Controls in Symbian OS
Controls are the fundamental building blocks of the user interface in Symbian OS. A
control is an object that can display information to the user and respond to user input.
Key Characteristics of Controls:
 Display Information: Controls can display text, images, and other types of
content.
 Handle User Input: Controls can respond to user actions such as key presses,
touch inputs, and other events.
 Drawing: Each control is responsible for drawing itself on the screen.
 Focus: Controls can gain and lose focus, allowing them to handle input events
appropriately.

P a g e 9 | 28
Compound Controls in Symbian OS
Compound Controls are more complex controls that consist of multiple simpler
controls combined together. They allow developers to create sophisticated user
interface elements by aggregating several basic controls into a single, cohesive unit.
Characteristics of Compound Controls:
 Container Control: Acts as a parent that manages multiple child controls.
 Layout Management: Handles the positioning and size of child controls within
the parent control.
 Event Handling: Manages events and delegates them to the appropriate child
control when necessary.

ACTIVE OBJECTS
Active objects in Symbian OS are a programming construct that encapsulate a request
to an asynchronous service and the completion of that request. They are a fundamental
part of Symbian OS's event-driven operation and can be used to implement cooperative
multitasking and efficient multitasking within a single thread.

Features of Active Objects

Asynchronous requests: When a thread makes an asynchronous request, an active
object is incremented. When the request is completed, the active object is decremented.
Thread sleep: If there are no outstanding requests, the thread is put to sleep.
Interaction: Active objects can interact with each other and with active objects in other
threads by requesting things from them. They can even request things from themselves

Key Concepts of Active Objects

1. Active Scheduler:
 The active scheduler is responsible for managing active objects within a
thread.
 It maintains a list of active objects and schedules them based on their priority.
 Each thread can have only one active scheduler, and it must be installed using
CActiveScheduler::Install().

2. Active Object:
 An active object encapsulates an asynchronous operation.
 It is derived from the CActive class.
 An active object has a TRequestStatus member that indicates the status of
an asynchronous request.

3. Priority:
 Active objects have a priority level that determines the order in which they
are scheduled.

P a g e 10 | 28
  Higher priority active objects are executed before lower priority ones.

4. Request Status:
 TRequestStatus is used to indicate the completion status of an asynchronous
request.
 It is set by the asynchronous service provider when the request is completed.

Structure of an Active Object

An active object is composed of several key methods and members:
Constructor:
 Initializes the active object and sets its priority.
 Registers the active object with the active scheduler.
Destructor:
 Ensures that any outstanding requests are canceled.
 Cleans up resources.
RunL():
 Called by the active scheduler when an asynchronous request completes.
 Contains the code to handle the completion of the request.
DoCancel():
 Called by the active scheduler to cancel an outstanding asynchronous request.
 Ensures that any resources used by the request are properly released.
SetActive():
 Marks the active object as ready to receive an event.
 Must be called after issuing an asynchronous request.

LOCALIZATION
Localization in Symbian OS involves adapting the application to different languages and
regional settings to provide a more user-friendly and region-specific user experience.
This process ensures that the application can cater to a global audience by supporting
multiple languages, date formats, currency formats, and other locale-specific features.
Below, I'll explain the localization concept in Symbian OS in detail.
Key Concepts of Localization in Symbian OS

1. Locale: A locale in Symbian OS includes parameters such as language, country,

date and time formats, currency, and other region-specific settings.
2. Resource Files (RSS Files):
o Resource files in Symbian OS are used to define user interface elements
such as text strings, dialogs, menus, and other resources.
o These files are written in a specialized resource script language and are
compiled into binary resource files (.rsc) that the application loads at
runtime.
3. String Tables:
o String tables in resource files manage text strings for different languages.
P a g e 11 | 28
 o Each string in a string table is associated with a unique identifier (UID),
allowing the application to reference the appropriate string based on the
current locale.

SECURITY ON SYMBIAN OS

Security on Symbian OS is a multifaceted system designed to protect both the device

and the user from malicious software and unauthorized access. Given its history as a
dominant mobile operating system, Symbian OS developed a comprehensive security
model to ensure safe application execution and data integrity.
Key Components of Symbian OS Security

1. Platform Security Architecture: A set of rules and mechanisms to control access

to system resources and sensitive APIs.
2. Capabilities: Permissions granted to applications, defining what system resources
and services an application can access.
3. Certificate-Based Signing: A process where applications are signed with digital
certificates to verify their authenticity and trustworthiness.
4. Data Caging: A mechanism that restricts access to application data to prevent
unauthorized access.
5. Software Installer Security: Ensures that only signed and verified applications can
be installed on the device.
6. Trusted Computing Base (TCB): A core part of the OS that is trusted to enforce
security policies.

Platform Security Architecture

Symbian OS employs a layered security architecture that includes:

1. Kernel-Level Security: Provides the foundation for enforcing security policies. It

includes mechanisms for managing capabilities and enforcing data caging.
2. User-Level Security: Implements additional security policies at the user
application level, including certificate checks and user prompts for sensitive
actions.

Capabilities
Capabilities in Symbian OS define what an application is allowed to do. There are
several levels of capabilities:

1. Basic Capabilities:
o Required for common functionalities.
o Examples include ReadUserData, WriteUserData, NetworkServices.
2. Extended Capabilities:
o Required for more sensitive operations.
o Examples include Location, PowerMgmt, SwEvent.
3. System Capabilities:
o Required for critical system operations.
o Examples include TCB, CommDD, DiskAdmin.
P a g e 12 | 28
Certificate-Based Signing
Applications in Symbian OS must be signed with a digital certificate to:

1. Verify Authenticity: Ensure the application comes from a trusted source.

2. Grant Capabilities: Assign the appropriate capabilities based on the level of trust.

The signing process involves:

1. Self-Signed Certificates: Suitable for testing and basic applications that require no
special capabilities.
2. Developer Certificates: Issued by Symbian Signed for development purposes,
allowing access to more capabilities.
3. Symbian Signed Certificates: Issued after a thorough verification process, granting
access to extended and system capabilities.

Data Caging
Data caging is a security mechanism that restricts access to application data. It ensures:

1. Isolation: Each application has its own private directory that other applications
cannot access.
2. Controlled Access: Only applications with the appropriate capabilities can access
certain system directories or data belonging to other applications.

Software Installer Security

The software installer in Symbian OS enforces several security checks:

1. Certificate Verification: Ensures that the application is signed with a valid

certificate.
2. Capability Checks: Verifies that the application has the required capabilities to
perform its intended functions.
3. User Prompts: Alerts the user when an application requests access to sensitive
capabilities or data.

Trusted Computing Base (TCB)

The TCB is a core component of the OS responsible for enforcing security policies. It
includes:

1. Kernel: The core part of the OS that enforces security policies at the lowest level.
2. File Server: Manages file system access and enforces data caging policies.
3. Window Server: Manages access to the display and enforces user interface-
related security policies.

P a g e 13 | 28
 ANDROID OPERATING SYSTEM
Android is a mobile operating system based on a modified version of the Linux kernel
and other open-source software, designed primarily for touchscreen mobile devices
such as smartphones and tablets. Android is developed by a partnership of developers
known as the Open Handset Alliance and commercially sponsored by Google. It was
disclosed in November 2007, with the first commercial Android device, the HTC
Dream, launched in September 2008.
It is free and open-source software. Its source code is Android Open Source Project
(AOSP), primarily licensed under the Apache License. However, most Android devices
dispatch with additional proprietary software pre-installed, mainly Google Mobile
Services (GMS), including core apps such as Google Chrome, the digital distribution
platform Google Play and the associated Google Play Services development platform.

Features of Android Operating System

Below are the following unique features and characteristics of the android operating
system, such as:

1. Near Field Communication (NFC)

Most Android devices support NFC, which allows electronic devices to interact across
short distances easily. The main goal here is to create a payment option that is simpler
than carrying cash or credit cards, and while the market hasn't exploded as many experts
had predicted, there may be an alternative in the works, in the form of Bluetooth Low
Energy (BLE).

2. Infrared Transmission
The Android operating system supports a built-in infrared transmitter that allows you
to use your phone or tablet as a remote control.

P a g e 14 | 28
 3. Automation
The Tasker app allows control of app permissions and also automates them.

4. Wireless App Downloads

You can download apps on your PC by using the Android Market or third-party options
like AppBrain. Then it automatically syncs them to your Droid, and no plugging is
required.

5. Storage and Battery Swap

Android phones also have unique hardware capabilities. Google's OS makes it possible
to upgrade, replace, and remove your battery that no longer holds a charge. In
addition, Android phones come with SD card slots for expandable storage.

Custom Home Screens

While it's possible to hack certain phones to customize the home screen, Android comes
with this capability from the get-go. Download a third-party launcher like Apex, Nova,
and you can add gestures, new shortcuts, or even performance enhancements for older-
model devices.

Widgets
Apps are versatile, but sometimes you want information at a glance instead of having
to open an app and wait for it to load. Android widgets let you display just about any
feature you choose on the home screen, including weather apps, music widgets, or
productivity tools that helpfully remind you of upcoming meetings or approaching
deadlines.

6. Custom ROMs
Because the Android operating system is open-source, developers can twist the current
OS and build their versions, which users can download and install in place of the stock
OS. Some are filled with features, while others change the look and feel of a device.
Chances are, if there's a feature you want, someone has already built a custom ROM
for it.

Architecture of Android OS
The android architecture contains a different number of components to support any
android device needs. Android software contains an open-source Linux Kernel with
many C/C++ libraries exposed through application framework services.
Among all the components, Linux Kernel provides the main operating system functions
to Smartphone and Dalvik Virtual Machine (DVM) to provide a platform for running
an android application. An android operating system is a stack of software components
roughly divided into five sections and four main layers, as shown in the below
architecture diagram.

 Applications
 Application Framework
 Android Runtime
 Platform Libraries
P a g e 15 | 28
  Linux Kernel

a) Applications
An application is the top layer of the android architecture. The pre-installed applications
like camera, gallery, home, contacts, etc., and third-party applications downloaded
from the play store like games, chat applications, etc., will be installed on this layer.
It runs within the Android run time with the help of the classes and services provided
by the application framework.

b) Application framework
Application Framework provides several important classes used to create an Android
application. It provides a generic abstraction for hardware access and helps in managing
the user interface with application resources. Generally, it provides the services with the
help of which we can create a particular class and make that class helpful for the
Applications creation.
It includes different types of services, such as activity manager, notification manager,
view system, package manager etc., which are helpful for the development of our
application according to the prerequisite.
The Application Framework layer provides many higher-level services to applications
in the form of Java classes. Application developers are allowed to make use of these
services in their applications. The Android framework includes the following key
services:

 Activity Manager: Controls all aspects of the application lifecycle and activity
stack.
 Content Providers: Allows applications to publish and share data with other
applications.
P a g e 16 | 28
  Resource Manager: Provides access to non-code embedded resources such as
strings, colour settings and user interface layouts.
 Notifications Manager: Allows applications to display alerts and notifications to
the user.
 View System: An extensible set of views used to create application user
interfaces.

c) Application runtime
Android Runtime environment contains components like core libraries and the Dalvik
virtual machine (DVM). It provides the base for the application framework and powers
our application with the help of the core libraries.
Like Java Virtual Machine (JVM), Dalvik Virtual Machine (DVM) is a register-based
virtual machine designed and optimized for Android to ensure that a device can run
multiple instances efficiently.
It depends on the layer Linux kernel for threading and low-level memory management.
The core libraries enable us to implement android applications using the
standard JAVA or Kotlin programming languages.

d) Platform libraries
The Platform Libraries include various C/C++ core libraries and Java-based libraries such
as Media, Graphics, Surface Manager, OpenGL, etc., to support Android development.

o app: Provides access to the application model and is the cornerstone of all
Android applications.
o content: Facilitates content access, publishing and messaging between
applications and application components.
o database: Used to access data published by content providers and includes
SQLite database, management classes.
o OpenGL: A Java interface to the OpenGL ES 3D graphics rendering API.
o os: Provides applications with access to standard operating system services,
including messages, system services and inter-process communication.
o text: Used to render and manipulate text on a device display.
o view: The fundamental building blocks of application user interfaces.
o widget: A rich collection of pre-built user interface components such as buttons,
labels, list views, layout managers, radio buttons etc.
o WebKit: A set of classes intended to allow web-browsing capabilities to be built
into applications.

P a g e 17 | 28
 o media: Media library provides support to play and record an audio and video
format.
o surface manager: It is responsible for managing access to the display subsystem.
o SQLite: It provides database support, and FreeType provides font support.
o SSL: Secure Sockets Layer is a security technology to establish an encrypted link
between a web server and a web browser.

e) Linux Kernel
Linux Kernel is the heart of the android architecture. It manages all the available drivers
such as display, camera, Bluetooth, audio, memory, etc., required during the runtime.
The Linux Kernel will provide an abstraction layer between the device hardware and
the other android architecture components. It is responsible for the management of
memory, power, devices etc. The features of the Linux kernel are:

o Security: The Linux kernel handles the security between the application and the
system.
o Memory Management: It efficiently handles memory management, thereby
providing the freedom to develop our apps.
o Process Management: It manages the process well, allocates resources to
processes whenever they need them.
o Network Stack: It effectively handles network communication.
o Driver Model: It ensures that the application works properly on the device and
hardware manufacturers responsible for building their drivers into the Linux
build.

JAVA MICRO EDITION

The Java ME stands for Java Micro Edition. It is a development and deployment
platform of portable code for embedded and mobile devices (sensors, gateways, mobile
phones, printers, TV set-top boxes). It is based on object-oriented Java. The Java ME
has a robust user interface, great security, built-in network protocols, and support for
applications that can be downloaded dynamically. Applications which are developed
on Java ME are portable and can run across various devices and can also leverage the
native capabilities of the device.

How Java ME is organized

The generic computing devices usually consist of hardware such as display, permanent
storage, keyboard, etc. but the small computing devices are not like this. Some of them
don't have permanent storage, and some don't even have a permanent display. As Java

P a g e 18 | 28
ME target a variety of small computing devices, this problem is handled by it by using
a two-fold approach.

 Firstly, there is a Java Run-time Environment and other core classes that are
defined to target specifically the device on which it is operating. This is referred
to as configurations.
 Secondly, a profile is defined as a set of similar small computing devices. A profile
has several classes within it which are made to implement features found on a
related group of small computing devices.

Java ME architecture
The Java ME architecture helps in scaling an application based on the constraints
provided by the small computing device. Java ME does not simply replace the operating
system, rather it stacks up layers on the native operating system and makes an
environment for the application to run. These layers are collectively named
as Connected Limited Device Configuration (CLDC).
The first layer is the configuration layer that includes the Java Virtual Machine. This
layer interacts directly with the native operating system and builds the connection
between the profile and the JVM.
The second layer is the profile which contains the minimum set of APIs for the small
computing device. The profile contains a set of classes which are made to implement
the features of a related group of small computing devices.
The third layer is the Mobile Information Device Profile (MIDP). The MIDP layer
consists of APIs which are for user network connections, persistence storage, and the
user interface. It also has access to Connected Language Device Configuration (CLDC)
and Mobile Information Device Profile (MIDP) libraries.
A small computing device has two components supplied by the Original Equipment
Manufacturer (OEM). They are, namely OEM apps and OEM classes. The MIDP
communicates with the OEM classes to gain access to features like sending and receiving
messages and accessing device-specific persistent data. OEM applications are small
programs such as address book etc.

P a g e 19 | 28
Configurations in Java ME
There are two main configurations in Java ME: Connected Limited Device
Configuration (CLDC). For devices with limited resources, such as mobile phones and
entry-level PDAs. Connected Device Configuration (CDC).

Meaning of Connected Limited Device Configuration

Connected Limited Device Configuration (CLDC) is a set of standards, libraries, and
virtual-machine features that serve as the basis for APIs targeted at devices with very
limited resources. A large number of feature phones, as well as some embedded systems,
fall under this category of devices.
CLDC is one of two configurations under the Java Platform Micro Edition (Java ME).
Compared to the devices supported by another configuration (called Connected Device
Configuration), CLDC-supported devices have more constrained hardware resources,
including RAM, screen size and resolution, and CPU.
CLDC can work with devices that are driven by 16-bit or 32-bit
microprocessors/controllers. These microprocessors/controllers should have clock
speeds of at least 16 MHz and available non-volatile memory of at least 160 KB for the
CLDC libraries and the virtual machine, as well as 192 KB for the Java platform. In most
cases, these devices are powered by batteries and support wireless connectivity.
CLDC supports the Mobile Information Device Profile, Information Module Profile,
Digital Set Top Box Profile, and the Doja Profile. The Mobile Information Device Profile
(MIDP) is the profile designed for cell phones. Applications written using MIDP are
known as midlets. These tiny apps comprise the majority of the apps found on feature
phones worldwide.
The Information Module Profile is targeted at vending machines, routers, telephone
boxes, network cards, and other similar embedded systems. Such systems have very
P a g e 20 | 28
simple displays or none at all. The Digital Set Top Box Profile is tailor made for the
cable TV industry. This profile is based on Open Cable Application Platform (OCAP),
an OS for devices that connect to cable TV systems.
Optional packages that work with the CLDC include the Personal Information
Management and FileConnection packages.

The CLDC Specification

Like all J2ME technology, the CLDC is defined by a specification that has passed through
the Java Community Process (JCP). At this time, there are two versions of the CLDC.
Version 1.0, released in May of 2000, is known as Java Specification Request (JSR) 30.
Version 1.1, currently in public review, is JSR 139. Because version 1.0 is the one that is
currently shipping in devices, we’ll concentrate on it.
The CLDC specification defines three things:

 The capabilities of the Java virtual machine (VM), which is not a full-featured
Java VM.
 A very small subset of the J2SE 1.3 classes.
 A new set of APIs (application programming interfaces) for input/output called
the Generic Connection Framework.
It’s also important to understand what the CLDC does not define. The CLDC does not
define any APIs related to user interfaces. The CLDC does not define how applications
are loaded onto a device or how they are activated or deactivated.
These and other things are defined by the J2ME profiles that use
the CLDC as their base. So while it’s true that the CLDC does define
a complete Java runtime environment, the additional APIs defined
by a profile or supplied by the vendor are really necessary
to build useful applications.

The Virtual Machine

The Java VM used in the CLDC is restricted in certain important
ways when compared to a full-featured J2SE VM. These restrictions
allow the VM to fit the memory and power constraints of the small
devices that the CLDC target: the CLDC VM and classes can fit
in 128K of memory.
The primary restrictions on the VM are:

 No floating point types.

 No object finalization or weak references.
 No JNI or reflection (hence no object serialization).
 No thread groups or daemon threads (note that threads are
supported, just not thread groups).
P a g e 21 | 28
  No application-defined class loaders.
In addition to the above restrictions, the CLDC also requires class verification to be
done differently. Class files are processed by an off-device class verifier,
a process called preverification. At runtime, the VM uses information inserted into the
class files by the preverifier to perform the final verification steps. Files that have not
been processed by the preverifier are not loaded since they cannot be verified.

THE MIDP GUI PROGRAMMING MODEL

The Mobile Internet Device Profile (MIDP) Graphical User Interface (GUI) is a digital
interface that uses graphical components like icons, buttons, and menus to communicate
with a computer application or operating system. The MIDP GUI consists of both high-
level and low-level APIs, each with their own set of events. All MIDP GUI classes are
contained in the [Link] package.
The MIDP GUI Programming ModelThe central abstraction of the MIDP UI is a screen,
which is an object that encapsulates device-specific graphics rendering user input. Only
one screen can be visible at a time, and the user can traverse only through the items on
that screen.
There are three types of screens in the MIDP GUI:

 Screens with complex user interface components: These screens encapsulate a

component that involves a List or TextBox component, and have a predefined
structure. The application cannot add other components to these screens.
 Generic screens with Form components: The application can add text, images,
and a simple set of related UI components to the form.
 Screens used within the context of the low-level API: These screens are a subclass
of the Canvas class.

USER INTERFACE DESIGN ISSUES

Designing user interfaces (UIs) for J2ME (Java 2 Platform, Micro Edition) applications
comes with a unique set of challenges due to the constraints and diversity of mobile
devices. The main UI design issues in J2ME:

 Screen Size and Resolution Variability: Mobile devices have a wide range of
screen sizes and resolutions.
 Limited Graphics Capabilities: Mobile devices often have restricted graphics
processing power.
 Input Methods and Navigation: Different devices use various input methods like
keypads, touchscreens, and styluses.
 Limited Memory and Performance: J2ME applications must operate within strict
memory and performance constraints.
 Responsive UI Design: Users expect responsive UIs that provide immediate
feedback.

P a g e 22 | 28
  Cross-Device Compatibility: Ensuring consistent UI behavior across various
J2ME-enabled devices.
 Usability and Accessibility: Creating UIs that are intuitive and accessible to all
users.
 Resource Management: Efficiently managing resources like images, sounds, and
data.
MOBILE INFORMATION DEVICE PROFILE
Mobile Information Device Profile (MIDP) is a set of Java APIs and specifications
designed for developing applications on mobile devices, particularly those that support
Java ME (Micro Edition). MIDP focuses on providing functionality for user interfaces,
networking, and storage on devices with limited processing power and memory. This
profile enables developers to create portable, feature-rich applications for a wide range
of mobile devices, including smartphones and feature phones.

Key Takeaways
 Mobile Information Device Profile (MIDP) is a specification developed for Java
Micro Edition (Java ME) platform, enabling the development of applications for
mobile devices like cell phones, smartphones, and PDAs.
 MIDP, built on top of the Connected Limited Device Configuration (CLDC),
provides a runtime environment, user interface APIs, and network protocols
specifically designed and optimized for resource-constrained devices.
 With MIDP, developers can create portable and interactive applications, known
as MIDlets, which can run on a wide range of mobile devices, facilitating cross-
platform compatibility and improving the user experience.

Importance
The technology term Mobile Information Device Profile (MIDP) is important because
it plays a vital role in allowing developers to create applications and services specifically
for mobile devices.
MIDP is a part of the Java 2 Platform, Micro Edition (J2ME) framework, which provides
a standardized environment for mobile application development.
By offering a consistent and flexible platform, MIDP enables developers to build and
deploy applications that can run seamlessly across various mobile devices, such as
smartphones, tablets, and other portable gadgets.
This is crucial in today’s ever-evolving technology landscape, as it helps to ensure a
unified user experience, irrespective of the specific device or operating system being
used.
Consequently, MIDP contributes significantly to the growth and widespread adoption
of mobile applications, resulting in enhanced user engagement and enriched overall
functionality for mobile devices.

P a g e 23 | 28
MIDP in Detail
Mobile Information Device Profile (MIDP) serves as a crucial component in the
development of mobile applications, particularly for Java-enabled devices like
smartphones and tablets. It operates in conjunction with the Connected Limited Device
Configuration (CLDC), which specifies the minimum Java runtime requirements for low-
powered devices.
MIDP’s primary purpose is to provide a standard set of APIs, libraries, and user interface
components tailored for mobile devices, ensuring seamless functionality across a variety
of platforms. By delivering a streamlined development process, MIDP empowers
developers to create efficient, secure, and portable applications that cater to the unique
needs of mobile users.
Moreover, MIDP guarantees a consistent user experience, regardless of the underlying
hardware or operating system discrepancies among mobile devices. Its efficient memory
management and optimization capabilities allow for rapid application response times,
while a robust security framework safeguards sensitive data.
To facilitate the dynamic capabilities of mobile devices, MIDP provides support for
features like location-based services, messaging, and multimedia content handling.
Overall, the Mobile Information Device Profile serves as an instrumental factor in
realizing the full potential of mobile applications by simplifying the development
process and fostering optimal usability across diverse ecosystems.

Examples of MIDP
The Mobile Information Device Profile (MIDP) is a Java specification that defines a
platform for Java applications on mobile devices, such as smartphones and feature
phones. MIDP was an earlier technology under the Java ME (Java Platform, Micro
Edition) framework for developing applications on resource-constrained devices. Here
are three real-world examples of MIDP:
 Gaming Applications:
In the early 2000s, MIDP became popular for developing mobile games. A well-known
example is the mobile game Snake, which was pre-installed on many Nokia devices.
This game and others like it were developed using the MIDP platform, enabling them
to run on a wide range of mobile devices with limited resources.
 Messaging Applications:
MIDP-enabled applications brought messaging capabilities to mobile devices, such as
SMS (Short Message Service) and MMS (Multimedia Messaging Service). An example of
a messaging application using MIDP is the early version of WhatsApp, which was
developed using Java ME and MIDP. This allowed WhatsApp to run on various mobile
platforms, including Nokia’s Symbian OS and BlackBerry devices.
 Mobile Browsers and Email Clients:

P a g e 24 | 28
MIDP was also used for developing email clients and mobile browsers, such as Opera
Mini. Opera Mini was a Java-based mobile browser optimized for low-bandwidth and
resource-constrained devices. The browser used MIDP to compress and render web
pages, enabling faster browsing on mobile devices, especially older models with limited
hardware capabilities.

MIDP SECURITY
1) MIDP 1.0 Security
Application security in MIDP 1.0 is based on a Java sandbox model which was explained
earlier. It is also important to note that in MIDP 1.0, MIDlet suites are allowed to save
data in persistent storage files (called record stores). However, sharing of record stores
between MIDlet suites is not allowed. With respect to end-to-end security, MIDP 1.0
specification does not include any cryptographic functionality. The only network
protocol provided in MIDP 1.0 is the HTTP protocol.
2) MIDP 2.0 Security
The difference between MIDP 1.0 security and MIDP 2.0 security is that, in MIDP 2.0,
accessing sensitive resources (APIs and functions) is not totally prohibited. Instead, MIDP
2.0 controls access to protected APIs by granting permissions to protection domains
and binding each MIDlet on the device to one protection domain. Thus, a MIDlet will
be granted all permissions provided to the protection domain that has been bound to
it.
A MIDlet is bound to one protection domain according to a well-defined procedure
that allows the AMS to authenticate the origin of a MIDlet: If one MIDlet can be
authenticated, then it is qualified as trusted, otherwise, it will be qualified as untrusted.
In addition, MIDP 2.0 introduces the ability to share record stores between MIDlet
suites. The protection of record stores is discussed later in this section. Also, an
important difference between the security of MIDP 1.0 and MIDP 2.0 is that MIDP 2.0
provides end-to-end security by allowing secure networking using HTTPS protocol.

Sensitive APIs
In MIDP 2.0, some capabilities of the device are exposed to MIDlets through a set of
APIs that are identified as sensitive and therefore should be protected. The sensitive
APIs in MIDP 2.0 are the ones related to connectivity and the PushRegistry class.

Permissions and Protection Domains

Access to sensitive APIs is protected by permissions. A protection domain defines a set

of permissions, and for each permission, the protection domain defines the level of
access to the API protected by the permission. The level of access can be
either Allowed or User. For the Allowed level, the permission is granted without
involving the user. As for the User level, access to the protected API requires explicit
authorization from the user. This authorization can be in one the following modes.

 Blanket: The permission is valid for every invocation of the protected API.
 Session: The permission is valid during one execution of the MIDlet.
P a g e 25 | 28
  Oneshot: The user must be prompted for each invocation of the protected API.
By default, four protection domains are provided by MIDP 2.0:
 Minimum: This domain contains no permissions. Access is denied for all sensitive
APIs.
 Untrusted: Requires that sensitive APIs can only be accessed through user
permissions.
 Trusted: All permissions are granted.
 Maximum: Same as trusted.
Protection domains are defined in a policy file. An example of the policy file is given in
figure 1 which is the policy file provided with the RI. The procedure for determining
whether a MIDlet suite is trusted is devicespecific. Some devices might trust only MIDlet
suites obtained from certain servers. Other devices might support only untrusted MIDlet
suites. Others authenticate MIDlet suites using the Public Key Infrastructure (PKI), which
is the case shown in figure 1. This authentication includes certificate path validation,
signature checks and expiration checks for the certificates.

Signing a MIDlet suite

In order to sign a MIDlet suite, the signer needs to have a private and public key pair,
and a certificate for his public key. If this certificate is not a certificate authority (a
certificate that is stored in the device), there should be another certificate that vouches
that the first one is valid. If this second certificate is still not a certificate authority, it
requires a third certificate vouching for it, and so on until a root certificate is reached.
The procedure of signing the MIDlet consists of the execution of the following steps:
 The signer computes a digital fingerprint of the JAR file by applying a hash
function (SHA-1).
 They then sign the digital fingerprint by encrypting it with the private Key.
 The signed fingerprint is placed in the JAD file.
 The certificate of the public key is placed in the JAD (except if the certificate is
the root certificate, which resides on the device), as well as the other certificates,
if any.

P a g e 26 | 28
Persistent Storage Security
In MIDP 2.0 a MIDlet suite can save data in a persistent storage area. The storage unit
in J2ME CLDC is the record store. Each MIDlet suite can have one or more record
stores, these are stored on the persistent storage of the device. Record stores are
identified by a unique full name, which is a concatenation of the vendor name, the
MIDlet suite name, and the record store name. Within the same MIDlet, two record
stores cannot have the same name. However, if they belong to two different MIDlet
suites, they can have the same name since their full names will be unique.
The actual structure of the record store on the device storage consists of a header and
a body. The header contains information about the record store while the body consists
of a number of byte arrays called records, these contain the actual data to be stored.
Figure 2 shows the structure of the storage system. The part of the Java platform
responsible for manipulating the storage is called the Record Management System
(RMS).
P a g e 27 | 28
For MIDP 1.0, record stores were not allowed to be shared among MIDlet suites. In
MIDP 2.0, sharing of record stores is allowed; the MIDlet suite that created the record
store can choose to make it shared or not. Moreover, the sharing mode can be set
to read-only or read/write. Sharing information is stored in the header of each record
store, and the default mode of sharing is private (no sharing).

End-to-end Security
MIDP 2.0 specification mandates that HTTPS be implemented to allow secure
connection with remote sites. HTTPS implementations must provide server
authentication. The Certificate authorities present in the device are used to authenticate
sites by verifying certificate chain provided by a server.

P a g e 28 | 28