Mobile Device APIs Survey

From MemberWiki

Jump to: navigation, search

This wiki page is one of several wiki pages for the Mobile TF work on Mobile Device APIs. Here are the pages:


About this wiki page

Below is an initial attempt at an outline for OpenAjax Alliance explorations and investigations in this area. (Initial version thanks to Krishna Sankar of Cisco.)

Current State Of Industry

Standards Initiatives Summary

A number of activities, concerned with accessing device capabilities, are under way in various standards organizations. The formal term for these capabilities is Delivery Context. This term recognizes that it is not simply the characteristics of the device that can be important in delivery of Web content to a device. The delivery context can include information associated with the network to which the device is connected, the preferences of the user and additional data, such as the location of the device.

The current standards activities are described in the following sections. Both server-side and client-side APIs are under development. Where groups are developing related API specifications, they are aware of each others work and are collaborating on development of the resources in which they have a shared interest. This is particularly true of the work at W3C and the OMA.

Other related work is underway in other standards bodies. For example, the JCP has been defining sets of APIs that can be used to access functions and systems installed in the device from JavaTM code.

A number of these activities is of direct relevance to the OAA Mobile Task Force. Each API specification is listed and discussed further in Device API - detailed analysis.

Use Cases

  • Discover info
  • Get current state
  • Change state



We certainly need to define requirements around security concerns. Access to device APIs potentially means going outside the sandbox that Web browsers provide to Web application and allow access to device features such as the PIM (where contact lists are stored), ability to interact with messaging services (e.g., ability to generate an SMS), or ability to get location information (which might allow sending an SMS or sending an HTTP message about your current location). We need to address security somehow, preferably in a lightweight but robust manner.


A view has been expressed that modularity of the interfaces is important to allow partial implementations.

APIs vs Markup

There is recognition that markup may be less brittle than programming APIs, particularly in the light of differences between implementations on different devices. At the recent F2F meeting at Microsoft in Mountain View, a view was expressed that it would be advantageous to have a markup-based way to access the information and that such a mechanism should be promoted to browser vendors for inclusion in the languages that they support directly.

Meta frameworks (to express, configure and deploy dependencies et al)

Device API - detailed analysis

(How and where the current interfaces and APIs fit in the mobility space)

W3C Activities and Relevance to OpenAJAX Mobile Device API

Four W3C groups are interested in accessing the delivery context. Work is underway to provide APIs for access from servers and from the device itself.

Work in the Web Application Formats Working Group and relevance to OpenAJAX Mobile Device API

Work Description Relevance
Widgets API An early and promising sub-activity of widgets lead by Marcos Caceres provides sandboxed Widget APIs which are effectively the same as device APIs. Directly relevant as widgets could be the paradigm of how Web applications work on mobiles.
Geolocation API API Public Geolocation archives already seems to show a lot of activity and interest. The most relevant forum for Geolocation standards work. Support from Gears, Opera, Apple and Mozilla, the key UA implementors.

Work in the Ubiquitous Web Applications Working Group and relevance to OpenAJAX Mobile Device API

Work Description Relevance
Delivery Context Ontology This specification defines a detailed ontology of the delivery context. It provides a formal model of the capabilities of devices and associated information, such as the properties of the networks to which they are attached. The plan is that other groups (W3C, OMA and others) can reference the relevant parts of the ontology in order to provide semantics for their individual vocabularies, and thereby provide a means of disambiguation and interoperability across several technologies. Indirectly relevant as the source from which vocabularies of characteristics, to be used in various APIs, are being created.
Delivery Context: Client Interfaces This specification defines a client-side API (DCCI) for access to the delivery context. Based on the W3C DOM (see for example DOM2 or DOM3) this API provides access to a hierarchy of properties. The specification does not itself provide a vocabulary, but work is planned based on the UWA Ontology and that of other groups using that ontology. Directly relevant. DCCI could provide the basis for the APIs needed by OAA for access to mobile device capabilities.

Work in the Mobile Web Initiative Device Description Working Group and relevance to OpenAJAX Mobile Device API

Work Description Relevance
Device Description Repository API The group defined a W3C Recommendation specifying a simple API to allow server-side access to a repository of device characteristic information. This information is static and applies to every instance of each particular type of device.

The group also defined a core vocabulary containing several device characteristics. This vocabulary (and any others defined in the same manner) can be identified in calls via the repository API in order to specify the device properties being queried. The core vocabulary has contributed to the UWA Ontology. The needs of the repository API is a major source of the characteristics that are being added to the ontology.

Directly relevant as one example of an API that accesses delivery context. Also a source from which vocabularies of characteristics can be taken.

Work in the Mobile Web Initiative Best Practices Working Group and relevance to OpenAJAX Mobile Device API

Work Description Relevance
Properties important for mobile site authors The group is defining particular properties of the delivery context that are needed by authors trying to create web sites that can be used on mobile devices. Their results are being fed into the MWI DD process which will result in entries in the DD vocabulary and the UWA Ontology. Indirectly relevant as one source from which vocabularies of characteristics, to be used in various APIs, are being created.

OMA Activities and Relevance to OpenAJAX Mobile Device API

Work in the Device Capabilities Working Group and relevance to OpenAJAX Mobile Device API

Work Description Relevance
OMA WTAI Web Telephony Application Interface This 2000 specification covers WAP/JavaScript scripting access to caller, messaging, phone book, call logs, and logical indicators. A number of Web browsers already support these. However, WTAI is not very commonly known to the average Ajax developer. Would be a good idea to use the WTAI terminology rather than adopting a new one here.
Device Profile Evolution The working group is defining a follow on to its UAProf specification for device information profiles. The new work is an API and underlying enablers that allow information about the delivery context to be made available to server-side code. The difference between this specification and the Device Description Repository API, developed by MWI DD, is that DPE gives access to dynamically varying properties. The process may be more expensive, because it may require communications with the device, so it is complementary to rather than replacing the MWI DD work.

The DPE work also refers to the UWA Ontology. The OMA DCAP group is also collaborating on the development of the ontology.

Indirectly relevant as one source from which vocabularies of characteristics, to be used in various APIs, are being created.

JSR248: Mobile Service Architecture for JavaTM Platform, Micro Edition

This JSR creates a mobile service architecture and platform definition for the high volume wireless handsets continuing the work started in JSR-185:JavaTM Technology for the Wireless Industry. It enhances that specification with new technologies.

JSR248 defines two sets of APIs[1,2]. One is known as the Mobile Service Architecture. The other is the Mobile Service Architecture subset. It is a true subset of the Mobile Service Architecture. As well as defining the particular APIs involved, each of which is defined in another JSR, the specification gives additional details relevant to situations where the APIs are available together.

The questions we need to ask are :

  • What are the relevant JSRs for the Open AJAX Mobile domain
  • How would the interfaces and programming models look like ?
    • Should we simplify the interfaces and provide aggregate objects? OTOH, may be we should expose all the APIs the device has
      • If we map the Java APIs, we can leverage the work Java folks have done, without a lot of discussions
      • It should allow companies to author thin layer software that can be installed into a JS engine to map to underlying J2ME APIs
      • It should make it straightforward for device mfgrs to put an alternate thin layer (versus what they have had to develop to hook into J2ME) on top of the system APIs that can be installed into their JS engine.
    • How is the general JS domain? Is it same as Java or would folks prefer simpler, coarse grained objects ? Are developers OK with a large set of APIs ? One of the chief criticism of Java is that the libraries become complex with tons of APIs
    • Are we thinking of using the APIs independent of J2ME or with J2ME ? Reason being, if we abstract and have a simpler approach, would the device manufacturers need to develop new interface libraries ?
    • Do we have the required infrastructure capabilities required by the APIs ?
    • Should we implement only a subset to achieve certain "hairy" capabilities (like security thru JSR 177) ? This way we get the capability but are not adding accidental complexity to the domain.

Aplix's proposal WebVM

The Aplix Corporation implements many of the JCP produced JSRs in the JBlend (J2ME) product. JSRs are standards of how device APIs should be accessed by Java mobile applications.

Aplix will offer a generic cross-platform NPAPI browser plugin named WebVM to be able to map Javascript to these Java APIs. Wrappers or libraries can be developed to map as many features as deemed useful to Web developers. When standards are developed, again the design will be flexible enough to conform. This is a practical approach to providing standardised and documented device APIs by leveraging the Java Community Process's work.

Linking Java and JavaScript with Common DOM

Sun has published a specification called Common DOM which allows Java to invoke JavaScript methods on the DOM of a page. Intended for use by Java Applets, this mechanism is actually back to front for the purposes of the APIs being considered by the task force. However, it raises the possibility that DOM-based interfaces might be appropriate. DOM-based interfaces, such as DCCI, are also being developed within the W3C UWA WG.

List of JSRs contained in JSR248 and relevance to OpenAJAX Mobile Device API

JSR Description Relevance
+JSR 75 (File & PIM) Consists of two sets of APIs - Personal Information Management (PIM) API and the File Connection API.
  • PIM functionalities include access to entries in an address book, calendar, to do list and access to all fields in native PIM databases. Supports import and export of address book entries in a vCard format and calendar and to do entries in a vCalendar format
  • The primary goal of the FileConnection APIs is to provide access to file systems on devices and/or mounted memory cards
Very relevant Should be straight forward
+JSR 82 (Bluetooth) A set of Java APIs to allow these Java-enabled devices to integrate into a Bluetooth environment Maybe has short-term relevance. Some early applications, such as exchanging biz cards, might use Bluetooth. Otherwise, treat this as a networking thing and assume for the short-term that Ajax developers only use the networking features provided by the browser.
+JSR 118 (MIDP) Enhanced mobile Device profile mainly as a common framework needs to be established on the phone to allow carriers/operators to design their backend systems Not relevant at present
+JSR 135 (Mobile Media) A high-level interface to sound and multimedia capabilities of a device. Not relevant at present
+JSR 139 (CLDC) Standardizes a highly portable, minimum-footprint Java™ application development platform for resource constrained, connected devices Not relevant at present
+JSR 184 (3D Graphics) A lightweight, interactive 3D graphics API Not relevant at present
+JSR 205 (Wireless Messaging) An interface for sending and receiving MMS. We certainly need basic ability to work with SMS and MMS.
+JSR 226 (Vector Graphics) API for rendering scalable 2D vector graphics, including image files in W3C Scalable Vector Graphics (SVG) format Not relevant at present
++JSR 172 (Web Services) API to access to remote SOAP / XML based web services; api to parse XML data Not relevant at present
++JSR 177 (Security & Trust) A collection of APIs that provides security and trust services by integrating a Security Element (SE). A SE can be in a variety of forms like smart cards, embedded chips in handsets et al. A SE provides the following benefits:
  • Secure storage to protect sensitive data such as the user’s privatekeys,publickey(root)certificates,service credentials, personal information, and so on.
  • Cryptographic operations to support payment protocols, data integrity, and data confidentiality.
  • A secure execution environment to deploy custom security features like user identification and authentication, banking, payment, loyalty applications, and so on.
The features from JSR 177 should serve as

input into our the security framework efforts, but we don't need to add any specific APIs that correspond to JSR 177.

++JSR 179 (Location) A compact and generic API that produces information about the present geographic location of the device Very Relevant. Should be straight forward
++JSR 180 (SIP) A general API, enabling devices to send and receive message using the SIP protocol defined in IETF and 3GPP. The Session Initiation Protocol (SIP) is used to establish and manage multimedia IP sessions. This same mechanism can also be used to provide instant messaging, presence and gaming services. With the advent of P2P SIP, there are some interesting opportunities ! But for the moment, we should treat SIP within the general category of networking, and assume that initially the Ajax world will have to get by with the networking features provided by the browser engine.
++JSR 211 (Content Handler) An API and associated model permitting the invocation of J2ME Applications to handle actions on Uniform Resource Identifiers (URI) based on the MIME-type or scheme. Not relevant. About asociating MIME types with particular handlers. Browser

engine takes care of this already.

++JSR 229 (Payment) Defines a generic optional API to initiate payment transactions and in addition the syntax for the description of the associated provisioning data, enabling API implementers to support different payment instruments. Not relevant at present
++JSR 234 (Multimedia Supplements) An API to access multimedia functionality, specifically, better support for camera, radio and advanced audio processing (like 3D audio). Not relevant at present
++JSR 238 (Internationalization A common API for the internationalization of MIDP applications viz:
  • The means to isolate localizable application resources from program source code and an API for accessing those resources at runtime
  • Selecting the correct resources for the user’s/device’s locale
  • An API for supporting cultural conventions in applications, e.g. for formatting dates, times, numbers, and currencies, and sorting text strings correctly for the user’s locale
Not relevant at present

Note : + = MSA subset, ++ = MSA

[Ref: [1] [2]]

Other JSRs and Relevance to OpenAJAX Mobile Device API

JSR Description Relevance
JSR188: CC/PP Processing JSR188 defines JavaTM interfaces for accessing device profiles written to the W3C CC/PP specification. This specification was the basis for the OMA UAProf specification by which static information about devices is commonly made available. More recent work at W3C and OMA will lead to alternative mechanisms for accessing device characteristics and newer APIs. Probably not directly relevant

Windows Mobile APIs

Microsoft's Windows Mobile OS offering provides a wide variety of public APIs that allow third party software developers to write software applications that target and utilize a number of different aspects of the device.

See: Windows Mobile 6 State & Notification for detail on the State and Notification Broker, a mechanism available to developers for accessing specific information about the device. Device properties are held in the registry. Code can access the values from the registry. Code can also register to be notified when values change. Information in the registry includes that from the device Personal Information Management application.

See: Windows Mobile 6 SDK for the Windows Mobile developer documentation, in general

See Windows Mobile 6 Managed Class Libraries, for examples on how the Windows Mobile team 'wrapped' native functionality in a managed class library, to provide acces to device specific functionality.

(if you have qustions on this content, please just let me know: [ Larry Lieberman]

Windows Vista System APIs for Gadgets

Windows Vista isn't a mobile OS, but nevertheless it is good to be aware of device APIs that are available to the Web Runtime in Vista Gadgets:

There are a number of APIs, including contact list, memory utilization, power status, and Outlook Express email boxes.

Opera Platform APIs

"Opera Platform", which is now Opera widgets, previously advertised device APIs. However currently Widget APIs don't seem to support an old Device API JavaScript interface.

Opera recently contributed a File I/O device API in the widget context to the W3C.

Arve Bersvendsen seems to be spear heading this work.

Orange APIs

The telco Orange has published several alpha APIs behind some sort of developer partnership programme.

Google Gears APIs

Loki API (skyhook/wifi client)

Series 60 (s60) Nokia device APIs

Noticed on a 3rd edition FP2 emulator:

Javascript Native Extensions

Native C++ implementation for NPAPI & ActiveX browser interfaces.

Apple iphone interfaces

Unfortunately may require an ADC account to read. :(

They introduce 'desiredAccuracy'

Location Aware

LocationAware's goal is to help drive the standardization of how a user's current location is exposed to a website through the browser.

Warning: their Wiki seems to suffer from spam

Motorola WebUI APIs

Motorola are developing device APIs under their WebUI framework. This is due for release early in year 2008 (anyone know where it is?), though they announced some details about WebUI at the MOTODEV Summit in London.

  • File system
  • Application launching
  • Event subsystem
  • Internationalisation
  • Soft key management (seperate XML file for this)
  • Addressbook contacts
  • Calendar
  • System (status, settings, battery)
  • Location
  • Media finder

Mozilla mobile

NTT Docomo i-mode

i-mode presents two ways of getting location via an Anchor tag.

Via a pos: protocol

The pos: protocol (like mailto: I assume) presents the user with a dialog to choose between:

  1. i-appli - Anyone knows what this is?
  2. a map (assuming embedded, like the Nokia maps thing)
  3. attach to a mail (or SMS more so in the Western context)

Via a keyword "lcs" which gets expanded to "?lat=latitude&lon=longitude&geo=geodetic system&x-acc=accuracy level"

Very interesting when the user selects this, a dialog is presented (see bottom of the page's Notes) to:

  1. attach current location
  2. refer to location history
  3. refer to location from the phonebook/addressbook

Besides the choice between these useful options, the user might have better window of control about how or when the location is discovered by the device.

KDDI au location APIs

Mike Smith pointed out a location scheme used in Japan on an Openwave v6 based browser.

This device: protocol scheme seems to be used on KDDI au networks on Japan, as opposed to NTT Docomo.

It might work like this:

  1. User clicks on device:location?url=http://server/location.cgi link
  2. Protocol "device:" is re-written by some service (perhaps not the browser, think "mailto:")
  3. Use is redirected to location populated request to http://server/location.cgi?datum=AAA&unit=BBB&lat=XXX&lon=YYY

Unsure if the "pos:" from i-mode behaves in a similar manner.

Vodafone's MobileScript

Vodafone Group R&D has done extensive work around both a draft specification (aimed at demonstrating and prototyping) and open source for a technology called MobileScript that provides JavaScript access to many different device-resident services, including location, mail, messaging (SMS and MMS), connection status, phone dialer, and more.

Here is the MobileScript 2.0 spec, uploaded to the OpenAjax wiki. Note that Vodafone MobileScript is a strawman specification created by Group R&D for demonstration and prototyping purposes:

Link to the project in Betavine:

Link to the project in Betavine Forge:

Link to the installers and documentation:

Link to a video of an standalone console using MobileScript:

Links to some videos of widgets using MobileScript + Opera Mobile:

Same videos but embedded within a device:


During 2007 and 2008, it became increasingly apparent to mobile industry leaders that the future direction and success of the mobile web could be harmed without a concerted effort to drive a standardized approach to how web applications access the key local capabilities on the mobile device. If web applications had to use different APIs (for the same capability) on different devices and platforms, then development of web applications which work on any mobile device would not happen. On top of this, the risk of malicious web applications having free access to local mobile capabilities is unacceptable. Therefore, a need to create some form of security layer to protect the user from harm was essential.

It is with this background that the OMTP launched its BONDI project with the aim of acting as a catalyst to drive the standardization of a small set of key interfaces from web services to mobile devices and also to put in place a well understood and user controlled security policy with which to protect the user.

BONDI consists of several activities, each of which interacts and as a whole builds towards the aim defined above.

Interface Requirements – A high level definition of the BONDI interfaces which include a dynamic API which is remotely updateable once the device is in the field

Security and Architecture requirements – Requirements for BONDI architectural constraints and for the security policy which protects the user from harm

API specifications – A set of Doxygen generated HTML pages that define the syntax and semantics of the BONDI APIs

Security Policy DTD – An interoperable XML description of the security policy which defines the access that a particular web application and widget will have to the BONDI APIs.

Reference Implementation (RI) – The RI is a real concrete example (using Windows Mobile as the platform) of how the interfaces and security specifications should be implemented. The RI SDK contains API documentation and example code – the initial alpha release is available here.

Compliance Criteria – A set of criteria which may be used to judge compliance of implementation against the defined standard and RI.

The BONDI Reference Implementation has been created as an Open Source project. This enables both OMTP Members and Participants as well as non members to collaborate on the creation of a rapidly iterating and testable implementation in a public arena. The use of real code in a RI ensures that other implementations for different devices and platforms can be tested and declared compliant against well defined criteria.

W3C Device APIs WG

In 2009, the W3C formally charted a W3C Device APIs WG that will tackle many of the same issues as the OMTP's BONDI project. In fact, the OMTP specs will be considered as starting points for W3C standardization and committee members from the BONDI effort are participating in the W3C efforts.

Personal tools