Linux ^TOP^

Figure 2.1 illustrates the basic architecture of the ACCESS Linux Platform.

Figure 2.1  ACCESS Linux Platform Architecture

As you can see, the bulk of the platform is made up of open source components. Only a small amount is ACCESS's own intellectual property.

Linux Kernel ^TOP^

• 2.6.14+ Kernel Reference Implementation
• Vendor/Distributor Agnostic
• x86 for Development
• ARM for Devices
• Support for More Device Hardware, Ongoing...
• Optimized for Fast Boot
• Minimizes Memory Footprint
• Changes Transparent–Full Patch Disclosure
• Implementation on Reference Hardware
• JFFS2 Journaling File System for NAND
• Dynamic Power Management
• Configurable Security Infrastructure (e.g., Secure APIs & Signed Code)

Other Linux Components ^TOP^

X Server

TinyX is the X server on the device. On the Simulator, the X server is Xephyr (http://www.freedesktop.org/wiki/Software/Xephyr). This is one of the few differences between the simulated environment and an actual device running ACCESS Linux Platform.

ACCESS Linux Platform uses the Matchbox window manager (http://matchbox-project.org/).

NetFront™ Web Browser ^TOP^

• HTTP/WAP, SSL/TLS, CSS/WCSS, HTML/xHTML (MP)/cHTML, WML 1.1/1.3
• JavaScript (ECMAScript MP)
• Embeddable in Applications (BrowserView)
• Carrier Provisioning

Synchronization ^TOP^

• HotSync^®
• Data Synchronization and Backup
• SyncML 1.2 for PIM Data
• Concurrent Synchronization
• IP Communications

Telephony Framework ^TOP^

Multi-mode Architecture Abstracting Telephony Services

Features:

• Access to network information and connection status
• Access to mobile device information
• Call management

Messaging Framework ^TOP^

• Manages the Messaging Capabilities–e.g., SMS, MMS, email, and IM
• Extensible Architecture Allows Integration of Additional Messaging Protocols
• Integrated with OTA Provisioning, Providing Access to Account Settings and Protocol Parameters

Data Storage ^TOP^

• POSIX File I/O
• SQL via SQLite3
• SQL Abstraction Layer Helper Functions
• PIM Data Abstractions
• SQL "File System"
• Global Settings

Application Server and Framework ^TOP^

• Global Services: Find, Clipboard, System Error Dialog, System Preference UI, etc.
• Default Behavior: Hard-key Handling, Clamshell Open/close, Power Management
• Framework for Application Execution
• Manages Application Lifecycle
• Provides Application Services

Application Packaging ^TOP^

Applications are shared libraries, not Linux executables. Each application relies upon a number of common shared libraries (such as GTK+). It is faster to have these common libraries be always loaded, and then just load the application as a shared library, as opposed to the normal method of loading the executable and all of the shared libraries that the executable needs.

Key Platform Components ^TOP^

Bundle Manager ^TOP^

The Bundle Manager provides a unified view of all applications on the system, regardless of their location (in internal memory, or on an inserted external memory card) or their type (GTK+, Java, ACCESS Linux Platform, Palm OS). The Bundle Manager transparently provides the appropriate resources for each. As a result, the user can populate a device with a broad mix of applications from a variety of sources without having to worry about specific resource requirements. The Bundle Manager also registers new applications and assigns them locale-specific resources. Finally, it validates security settings by validating an application's permissions.

More to the point, the Bundle Manager is the system component responsible for controlling how applications and supplemental application data (libraries, resources, etc.) are loaded, manipulated, transmitted, and removed.

The Bundle Manager is designed around the notion of bundles: concrete immutable lumps of information which are managed on an ACCESS Linux Platform device. Each bundle can contain an arbitrary amount of data in a format appropriate to that bundle. Bundle types have both an internal storage format and a "flattened" format suitable for transmission as a stream out of the device. (These formats may be the same, different, or overlap at various times).

As a mid-level library and server, the Bundle Manager gives developers easy access to application resources and maintains state for bundles present in the system. The server component is intended to be the only software on the device which has permission to access the bundle directory on the internal file system, requiring interaction with the Bundle Manager for installation or removal.

Although executables could conceivably be loaded onto a device through other means (say an FTP client dumping a file to the /tmp folder), the launcher and other system components would not provide any UI to launch that executable, nor provide any means to execute it with any significant authority.

Since all applications are stored in bundles, the Launcher can use the Bundle Manager to retrieve information about all available applications. This information spans all bundle types, permitting a single launcher to present the user with native ACCESS Linux Platform, GTK+, Java, and Palm OS applications.

Bundles are usable for more than applications: they can contain arbitrary data files. In particular, they can contain resources used for user interfaces, and shared libraries. Thus, common functionality can be distributed as a bundle containing a C shared library which has its own resource files. The Bundle Manager provides consistent mechanisms for retrieving both localized and unlocalized resources.

Bundles are considered to be immutable. The Bundle Manager doesn't provide any facilities for changing or modifying the contents of a bundle.

The Bundle Manager supports bundle namespaces. For example, all native bundles have a specified name: bundles can be referred to simply by such a specified name, and the Bundle Manager will be responsible for finding an appropriate bundle to match that name (the bundle with the specified name, with the latest version if there is more than one such bundle). This bundle namespace can be unified across different storage locations for bundles (say the internal file-system and external media cards).

The notion of a store is also defined by the Bundle Manager as a named location, somewhat corresponding to a path where bundles are stored on an underlying file system.

Some aspects of localization are aided by the Bundle Manager, which provides a consistent approach for searching for appropriately localized resource files within bundles.

A convenience for using URLs to retrieve resources across the system, using the unified namespaces, is also provided. One Bundle Manager function provides a generalized mechanism for calling code within plug-ins.

Security checks are integrated with appropriate bundle types to verify the integrity of signed code and to help the application server to grant additional authority to applications running from appropriately signed bundles.

The Bundle Manager provides support for:

• Finding bundles by name
• Finding bundles by a variety of other characteristics
• Obtaining information about a bundle
• Moving bundles between stores
• Determining which bundle code is running from
• Opening a bundle for direct access
• Retrieving files from a bundle
• Manipulating flattened bundle images, with streaming APIs
• Referring to any bundle, resource, or library on the system using a consistent URL format
• Retrieving localized icons and names for an application in a bundle

Note that the Bundle Manager does not provide any facilities for operating on files or applications that are not contained within bundles.

Bundle Manager Architecture

The Bundle Manager is implemented as a shared library intended for instantiation within a single server process and multiple client processes, making use of the ACCESS Linux Platform IPC mechanism communication between instantiations, and SQLite3 for semi-persistent data storage, general information management, and some degree of IPC (by using SQLite3 from both the server and client to retrieve information from database tables, taking advantage of database locking to provide synchronization).

The server side, instantiated within the Application Server, is needed to perform operations which need root permissions, such as mounting/unmounting loopbacks, or indeed any management of the internal bundle folders, which are explicitly limited so that only the Bundle Manager can write to them (preventing some other code from confusing the Bundle Manager, or modifying code after its signature has been verified.)

Native bundle management makes use of the Linux kernel support for the cramfs compressed read-only file system format, and the "loopback" mechanism of mounting a file containing a file system image.

To support Palm OS 68K applications, the Bundle Manager communicates with the Garnet VM; in part to manipulate the Garnet VM's database store, and in part to use Garnet VM routines to perform icon rasterization.

The Bundle Manager has several concepts used to track the different information and life-cycles in bundle management:

Bundle Image

A flattened file, sometimes called a "wire-format," indicates a data format which can easily be transmitted across a file-share or TCP/IP connection, and easily stored directly into a file. A flattened-file format may have a recommended form of name (particularly the extension) and/or mime-type, but these are usually not mandatory.

Bundle Schemes

Each type of bundle that the Bundle Manager supports has a different scheme to name it. The naming scheme is used directly in some URL forms and in some APIs.

Registered Bundles and Bundle Indexes

Once a bundle has been installed on an ACCESS Linux Platform device, it is registered with the Bundle Manager, and made visible through the Bundle Manager APIs. All registered bundles have a unique index value, regardless of their bundle name (or conflicts in the names).

Bundle Names

Some bundle types expose a name for each bundle. The Bundle Manager provides a unified namespace for these bundle names, making it easy for applications and bundles to refer to other bundles by a well-known name. Using the bundle name, you can retrieve the index of the bundle (if any) which has such a name. These names come in a basic URL form: bar:bundle.name.

Bundle Metadata

Metadata includes static information such as bundle type, data gleaned from the bundle manifest (name, version, type), as well as dynamic metadata (including current status of a bundle, reference count, file-system path, etc.).

Bundle Properties

At least for the ACCESS Linux Platform native bundle format (.bar), properties are a means of breaking up the bundle manifest in a modular fashion so it's easy to locate and process information about functionality in bundles.

Open Bundle

Some bundle types may not be accessible without additional work, which may involve limited resources. For example, opening native bundles on an external card involves a loopback file system mount. This should be done only when needed, so a bundle is considered "closed" until explicitly opened. The degree of access given to a bundle will differ with bundle type. (For instance, native bundles always support direct file-system access, while Garnet VM archives never do.)

Bundle References

A bundle reference is a handle to an open bundle. (Opening a bundle takes an index and gives you a handle). Each handle maintains a reference count on the bundle, and the Bundle Manager won't close the bundle until all handles are closed. The lifetime of handles is tracked: if an executable dies, any bundle handles it had are automatically closed.

Stores

Bundles may be stored in several locations on a device. For native bundles this is clearly separate folders, some of which might be on external media. For Garnet VM bundles, these might effectively be virtual proxies, actually referencing inside the Garnet VM storage heap. Store names are a way of distinguishing between the separate locations in which bundles can be stored.

Read-only Files

The Bundle Manager allows files to be retrieved from an open bundle. APIs allow material to be streamed from a channel, retrieved by pathname, or loaded directly into a data block. These routines support a search-path to automatically locate localized material. Generally, the APIs respect a rooted path ("/lib/somelib.so") as an unlocalized path within a bundle, while an unrooted path ("icon/duck.jpg") is retrieved via a bundle-specific lookup path.

Read/Write Files

The Bundle Manager tracks data folders on the ACCESS Linux Platform device's file-system so that an application running from a bundle is guaranteed a unique location to store its own data. (This is similar to the $HOME folder on a traditional UNIX system, except this is per-bundle). The read/write file API allows retrieving the location of such a data folder.

Bundle URLS

The bundle name format is already a simplistic URL ("bar:com.access.apps.ToDo"), and there are routines which support a richer URL syntax for locating read-only files within a bundle, or for loading a function pointer into a shared library (e.g. "bar:my.app/lib/mylib.so?SomeFunc"). This way data-driven references to files can easily be used by developers.

The ACCESS Linux Platform Native Format

For native ACCESS Linux Platform applications, the bundle format consists of a folder containing arbitrary files, somewhat similar in concept to the MacOS X bundle. There is a well-defined manifest file present in each bundle. A common namespace is used for all native bundles on all stores, so a reference to a particular bundle name will find the latest such bundle regardless of its location.

The flattened representation of this format is a compressed ROMFS image, such as a cramfs archive. This is intended to permit the data to be easily unpacked or repacked, and permit direct access to data, as files, without needing to unpack the entire contents.

Included in the ACCESS Linux Platform SDK is a short Perl script that packs and unpacks between folders and bundle bar files.

The Java Format

Java applications are supported in the existing .jar file format. This flat format (basically, .zip) supports transmission as well as execution (Java virtual machines support direct execution from .jar files).

The Garnet VM Format

The "Garnet VM" bundle format integrates Palm OS 68K databases and files representing those databases with ACCESS Linux Platform.

68K databases on external media cards are in .prc and .pdb files. These are tracked by the Bundle Manager and are not directly visible to the Garnet VM except as VFS files. 68K databases located in the internal storage, on the other hand, are directly installed into the Garnet VM's RAM store, and are not independent files. Accordingly, the Bundle Manager hold some 68K databases as proxies, communicating to the Garnet VM to manipulate them and retrieve their contents, while others (on media cards) are manipulated directly as files.

The contents of a Garnet VM bundle are not, strictly speaking, files, but a virtualization is provided so that resources and records can be retrieved as if they were. (No modification is possible via this API).

A namespace for Garnet VM bundles is provided so that a particular 68K database on the internal store can be referred to directly by type and creator, with separate names for databases on other stores.

Notification Manager ^TOP^

The Notification Manager is responsible for notifying applications of specific unsolicited events generated by the user, by the system, or by an application. These events include (but are by no means limited to):

• application installed or uninstalled
• card inserted or removed
• incoming call
• clam shell opened or closed
• time changed
• locale changed
• low power
• device going to sleep or waking up

Applications register to receive specific notifications. Whether or not the application is active, when the event occurs the application is notified. It is then up to the application to take whatever action it deems appropriate.

The Notification Manager is designed using a client/server architecture. The Notification Manager server is a persistent thread in a separate system process which keeps track of all registered notifications and broadcasts notifications to registered clients. The Notification Manager server also communicates with the Bundle Manager and Application Server.

Client processes call functions in the Notification Manager client library to register to receive notifications, unregister previously registered notifications, signal the completion of a notification, and broadcast notifications. The Notification Manger client library uses the ACCESS Linux Platform IPC framework to communicate to the Notification Manager server.

The Notification Manager is not intended for application-specific or directed notifications such as alarms or as might be used to implement find. The Notification Manager facilitates the sending and receiving of notifications but it does not itself broadcast notifications. Individual component owners are responsible for broadcasting their own notifications.

Multiple receivers may register for the same notification. Broadcasts occur sequentially: the notification is sent and handled and completed by one receiver before the notification is sent to the next receiver. When broadcasting a single notification to multiple receivers, the Notification Manager broadcasts based upon the priority given at registration time. If two or more receivers are registered with the same priority, then the broadcast is done in a first-registered, first-broadcast order.

Concurrent notifications to the same process are not supported because of the additional complexity (burden) on the application developer. When this condition occurs, the second notification waits for the first to complete.

Receiving Notifications

Applications and servers do not receive notifications by default. To receive a particular notification, the receiver must register for that notification. An application can register for "reset" and "install" notifications through its manifest file. All other notifications must be registered programmatically through the Notification Manager client library.

The Notification Manager operates in one of two modes, depending upon whether the code is a server or an application.

In a server, the Notification Manager client library creates a private thread in the running process which listens for notification messages from the Notification Manager server. When a notification message is received, the private thread calls the registered callback function. The callback occurs asynchronously; the callback function must be written to handle any concurrency issues with other threads in the process.

When an event occurs that an application has registered for, the Notification Manager calls the Application Server to launch (if the application is not running) or relaunch the application. The application must parse the argv parameters passed to its alp_main() function to get the notification type and any notification-specific data. Note that applications that register for notifications need to register a relaunch handler with the Application Server.

Handling Notifications

Notification handlers can set a handled flag to indicate that the notification has been handled. Setting this flag does not cancel the notification but rather informs subsequent handlers that the notification has already been handled. The value of this flag is simply sent to the subsequent notification handlers, who can act upon it or ignore it, as they choose.

The value of the handled flag is only valid for a single instance of the notification. That is, the value is not passed on to the next broadcast of the same notification.

One possible use of this flag would be to support two phone dialer applications.

As an example of how this flag might be used, suppose that the ACCESS Linux Platform device has two phone dialer applications installed. When a call comes in, one dialer would handle the call and set the flag. When the next dialer gets the notification, it would not handle the call but might update its call log and prevent the user from dialing while the call is in progress.

Although the handled flag cannot be used to cancel the notification, a notification handler can control whether the notification is passed on to other registered handlers or is canceled, through the value it returns from the notification handler.

Sending Notifications

In order to send a notification, the sender simply needs to tell the Notification Manager to broadcast a particular notification. The Notification Manager then broadcasts the notification to all registered receivers.

Notifications may have small amounts of data associated with them, packaged as a single buffer. The Notification Manager copies this data into the receiver's memory.

Multiple notifications (of the same or of differing types) can be broadcast concurrently or serially. The Notification Manager supports multiple broadcast queues (up to 32). Notifications in a single queue are serialized: the broadcast at the front of the queue must be completed (sent to all registered clients) before the next broadcast in the queue is started. Notifications in different broadcast queues are broadcast concurrently.

When sending a notification, you specify an individual queue using a single bit in an uint32 queue argument to the broadcast function. Broadcasts that need to be serialized across multiple queues can do a bitwise OR of the multiple broadcast queue bits. Synchronizing across multiple broadcast queues would be needed for wakeup/sleep broadcasts to ensure they are the last/first notifications received by clients. Serialization of broadcasts only exists within a broadcast queue; multiple broadcast queues are executed in parallel.

Broadcasts are added at the end of a broadcast queue by default. Broadcasters can however add their broadcast (with the ALP_NOTIFY_BROADCAST_IMMEDIATE flag) to the beginning of the queue to support nested broadcasts.

Exchange Manager ^TOP^

The Exchange Manager is the portion of the Hiker Application Framework that manages inter-application and inter-device communication. The Exchange Manager enables any application or system component to ask the system to perform some action on some data, without knowing which application or service will fulfill the request. The client can request that the action be performed either on the local device or on some specific other destination (phone, desktop PC, etc.), using any available transport. In these transactions the Exchange Manager acts as a central system broker in charge of the communication between different applications or servers: the ones requesting services and the ones that perform them.

An application that performs a service for others is known as a service provider. The service provider registers a handler for each specific action that it will perform on a specific type of data. The handler can also specify that it will accept only local requests, or that it will accept all requests. Each registered handler is valid for only one combination of action and data type. An action is defined by a verb, such as "store," "get," or "send." A data type is defined by its MIME type—for example, "text/vCard."

Transports carry the request from the source to the destination. When the request arrives at the destination (which may be on the local machine or on a remote machine), the transport hands it to the Exchange Manager which then invokes the corresponding action handler to do the actual work. If appropriate, a result can be sent back to the request initiator. This means that you can use the Exchange Manager not only to send data, but to retrieve data as well. Examples of this might include:

• Use your phone to look up a contact in your desktop PC's address book
• Retrieve a contact's photo and name, given their phone number

Handlers

You can register or unregister Exchange Manager handlers at any time. For instance, a game might register a "moveplayer" action (a handler to receive other players' moves) when it is launched. It would then send its own moves by requesting this action from another user's device. The game would unregister the handler when it quits.

An application cannot verify the availability and identity of a handler. If an application needs to authenticate a handler, it will have to use other means to look for a specific known handler. Then it can use, for example, data encryption to ensure only the person with the right key can understand the request.

Transports

Transports are independent modules that, like handlers, can be added or removed at any time. ACCESS Linux Platform includes a number of standard transports, including Local, IR (Infrared), Bluetooth, and TCP/IP.

The Exchange Manager isn't limited to communicating only with systems running ACCESS Linux Platform. Any computer or device that can run an Exchange Manager daemon and transports could potentially participate as well. The shared library, daemon, and transports only use standard Linux and GLib services. Thus, this code should run on any Linux platform; only the portion that invokes the handler would need to be rewritten.

The Exchange Manager provides a standard UI dialog to let the user select a transport and enter the relevant parameters. If needed transport information is missing in a request, the Exchange Manager will itself present this UI at the time it needs the information. If the transport determines that the destination address is missing, it will also display an address selection UI.

Parameters

Verbs can be accompanied by parameters. Parameters are passed as a tag/value pair (the value being of type int or string). Some parameters are mandatory, but most are optional and depend on the specific handler definition. Using parameters, the result of an action handler can be precisely customized to the client needs.

Parameters can be used by the action handler to find out how exactly it should perform its action, or by the transport module to get the destination address or other transport specific information.

APIs

Exchange Manager requests are encapsulated within an AlpExg2Request structure. This is an opaque data structure that contains all of the information characterizing the request: the verb, the parameters, the data reference, and the destination. There are public functions to set and get all of elements of the AlpExg2Request structure. The data itself can be specified either as a file descriptor (data will be read from this file descriptor by the transport) or by URL (the URL is sent, and the action handler accesses data through the URL).

Garnet VM ^TOP^

Garnet™ VM is an optional ACCESS Linux Platform component that executes applications written originally for Palm OS versions 1.0 through 5.4 (also known as "68K applications") from within ACCESS Linux Platform. It is designed to:

• Provide a high level of compatibility for the majority of such "well-behaved" applications. ("well-behaved" applications are those that adhere to documented APIs and programming guidelines.) Applications that include PACE Native Objects (PNOs) are supported.
• Improve overall system robustness by not allowing 68K applications to crash or otherwise negatively affect the system.
• Improve the developer story: the Garnet VM allows developers, if they so choose, to continue developing 68K applications that will run not only on the huge installed base of existing Palm Powered devices but on ACCESS Linux Platform devices with the Garnet VM.

From the perspective of the end user, 68K applications appear in the application launcher as do native ACCESS Linux Platform applications. Garnet VM relies upon the device's input mechanisms. 5-way navigation works in both ACCESS Linux Platform and in 68K applications running within the Garnet VM. Alerts and alarms are shared between Garnet VM and ACCESS Linux Platform. Finally, there is a shared clipboard that allows the user to cut-and-paste between the two operating environments.

Where they primarily differ, from an end-user perspective, is in how the applications look. ACCESS Linux Platform applications rely upon GTK+ and ACCESS Linux Platform widgets to display text, buttons, menus, and other graphic elements. 68K applications, on the other hand, rely upon the version of UILib that makes up a part of the Garnet VM, and therefore look like typical Palm OS Garnet applications.

The Garnet VM is started on demand, and is stopped when not needed. It shares the hardware (display, buttons, etc.) with other software components. It has been extended to support devices without a touchscreen.

The Garnet VM uses a modified version of the Palm OS Garnet 5.4 code base. This code base has an established set of APIs and developer tools, both of which are well documented and well known to thousands of developers (see http://www.access-company.com/developers/documents/palmos/palmos.html). Applications written for Palm OS Garnet often exhibit good performance, and are relatively simple in structure. They typically have a high degree of compatibility with a wide range of Palm Powered devices.

Although the Garnet VM provides a degree of integration with the host, it remains a separate running environment similar to the Classic environment in Apple's Mac OS^® X. Partly because the Garnet VM is not completely integrated, it retains many of the limitations of Palm OS Garnet, such as:

• The communications stacks are limited and not easily extensible.
• There is only a limited amount of protection against buggy software.
• The memory management system is somewhat outdated.
• The UI code is not reentrant.

Garnet VM is intended to provide compatibility for third-party applications, and is not intended to run system applications (PIMs, Camera, Dialer, Preferences, Security, etc.). ACCESS Linux Platform system applications are native and are fully integrated into the system.

Garnet VM is primarily a port of Palm OS Garnet to Linux with some major modifications and some added components for host integration. It consists of a bootstrap application, a set of libraries, and a ROM binary image. The Garnet VM ROM is a modified Palm OS 5.4 ROM.

Garnet VM is an optional platform component that will not necessarily be found on every ACCESS Linux Platform device. Its presence is up to the licensee. Garnet VM must be preinstalled; it cannot be installed after-the-fact, and it cannot be uninstalled.

Key Open-Source Components ^TOP^

There are over 70 open source components in the platform. The following are brief summaries of just a couple of the key components.

GTK+ ^TOP^

GTK+ is a portable and "free" (LGPL) toolkit for creating graphical user interfaces that runs on UNIX systems (X Window or frame-buffer based) as well as on Windows platforms. ACCESS Linux Platform uses GTK+ version 2.6, which is based on X11.

GTK+ is a popular open source framework and set of libraries for the creation of graphical user interfaces by both system and application developers. GTK+ contains a full-featured widget set that is designed for high performance and has good support for internationalization.

GTK+ is layered on top of GDK, which itself is layered on top of GLib. GLib provides various low-level system abstractions. GDK builds upon that and provides the graphical elements you see on screen. Finally, GTK+ provides a C-based "object-oriented" API that allows your applications to manipulate the display. All of these layers are accessible by ACCESS Linux Platform applications, as is the X server and the Matchbox window manager that underlie GLib—although applications generally shouldn't access the layers below GLib directly as those layers can be swapped out by a licensee and thus may be replaced by a different technology.

http://www.gtk.org/

User Interface Widgets

• GTK+ Defines Widget Set
• LiPS Forum Subset of GTK
• ACCESS Modifications to GTK
  • New Behavior (finger touch or 5-way)
  • Override Widget (Scrollbar)
  • Theming Extensions
• ACCESS Widgets
  • Time and Date Selector
  • Browser View
  • TitleBar and MenuBar

libglade ^TOP^

The libglade library enables a program to load its user interface at runtime from an XML-format description (the format of the XML file is that of the user interface builder GLADE). Libglade also provides a simple interface for connecting handlers to the various signals in the interface, and with a single function call you can connect all the handlers. Libglade is efficient in that once the interface has been instantiated, it adds no overhead.

http://www.jamesh.id.au/software/libglade/

GStreamer ^TOP^

GStreamer is a streaming-media (multimedia) framework with its type system based on GObject. GStreamer serves a host of multimedia applications, such as video editors, streaming media broadcasters, and media players. GStreamer is based on graphs of filters which operate on media data. Applications using this library can do anything from real-time sound processing to playing videos, and just about anything else media-related.

GStreamer uses a plug-in architecture. Its base functionality contains functions for registering and loading plug-ins and for providing the fundamentals of all classes in the form of base classes. Plug-in libraries are dynamically loaded to support a wide spectrum of codecs, container formats and input/output drivers.

http://sourceforge.net/projects/gstreamer/

OpenSSL ^TOP^

OpenSSL is a robust, commercial-grade, full-featured, open source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library.

http://www.openssl.org/

SQLite ^TOP^

SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine. Features include:

• Transactions are atomic, consistent, isolated, and durable (ACID) even after system crashes and power failures.
• Zero-configuration - no setup or administration needed.
• Implements most of SQL92.
• A complete database is stored in a single disk file.
• Supports databases up to 2 terabytes (241 bytes) in size.
• Strings and BLOBs up to 2 gigabytes (231 bytes) in size.
• Faster than popular client/server database engines for most common operations.
• Simple, easy to use API.

http://www.sqlite.org/

BlueZ ^TOP^

BlueZ is an implementation of the Bluetooth™ wireless standards specifications for Linux. It is the official Linux Bluetooth protocol stack.

http://www.bluez.org/

Hiker Application Framework ^TOP^

The Hiker Application Framework consists of several services, or "managers," designed to install and manage applications and enable applications to interact with each other and the user. These include:

Bundle Manager

provides a unified view of all applications on the system, whether these applications are in main memory or on an extension card. The Bundle Manager makes it possible to manage and launch different types of applications (Java, Linux, Palm OS^®) in an intuitive, easy-to-use manner. Bundle Manager hides the complexity and differences of these types of applications and presents the user an easy-to-use interface, common for all types.

Security Policy Framework

controls the security policy for the device. The policy used by the Framework is created by a licensee and is flexible, updateable, and separate from the mechanisms used to enforce it. The Security Policy Framework works in conjunction with a kernel-level enforcement component.

Exchange Manager

handles the exchange of data between applications and between devices. Developers can readily add new transport protocols simply by writing a new plug-in. Once the plug-in is installed, Exchange Manager makes the new transport available to all applications.

Notification Manager

informs applications of unsolicited events, including incoming calls, messaging, system sleep, and network signaling. Because messages are not "hard wired" to specific applications, developers can substitute and add new applications at any time simply by registering their application to the required notifications.

Application Server

manages an application's lifecycle: installation, launch, suspension, resumption, and termination.

Attention Manager

provides a central clearinghouse for application-generated events that are displayed to the user. Alerts include incoming calls, SMS, MMS, appointment, incoming email marked urgent, and low battery. Developers can easily customize these notifications for specific hardware, services, and applications.

Alarm Manager

notifies both active and inactive applications of real-time alarm events (managed by the Attention Manager). This service provides developers with a consistent way to request that an alarm be triggered at a particular time.

Global Settings Services

provides a common API for all applications and services to access user preferences, including fonts and font sizes, and system themes.