OTA Application Provisioning implementation on Android. I am trying to implement OTA settings update for my app. Didn't find any tutorial regarding this issue. The settings file would be an XML file.
Over-the-Air programming (OTA) refers to various methods of distributing new software, configuration settings, and even updating encryption keys to devices like mobile phones, set-top boxes or secure voice communication equipment (encrypted 2-way radios). One important feature of OTA is that one central location can send an update to all the users, who are unable to refuse, defeat, or alter that update, and that the update applies immediately to everyone on the channel. A user could 'refuse' OTA but the 'channel manager' could also 'kick them off' the channel automatically.
In the context of the mobile content world these include over-the-air service provisioning (OTASP), over-the-air provisioning (OTAP) or over-the-air parameter administration (OTAPA), or provisioning handsets with the necessary settings with which to access services such as WAP or MMS.
As mobile phones accumulate new applications and become more advanced, OTA configuration has become increasingly important as new updates and services come on stream. OTA via SMS optimizes the configuration data updates in SIM cards and handsets and enables the distribution of new software updates to mobile phones or provisioning handsets with the necessary settings with which to access services such as WAP or MMS. OTA messaging provides remote control of mobile phones for service and subscription activation, personalization and programming of a new service for mobile operators and telco third parties.[1]
Various standardization bodies were established to help develop, oversee, and manage OTA. One of them is the Open Mobile Alliance (OMA).
More recently, with the new concepts of Wireless Sensor Networks and the Internet of Things, where the networks consist of hundreds or thousands of nodes, OTA is taken to a new direction: for the first time OTA is applied using unlicensed frequency bands (868 MHz, 900 MHz, 2400 MHz) and with low consumption and low data rate transmission using protocols such as 802.15.4 and ZigBee.[2]
Motes are often located in places that are either remote or difficult to access. As an example, Libelium has implemented a smart and easy-to-use OTA programming system for ZigBee WSN devices. This system enables firmware upgrades without the need of physical access, saving time and money if the nodes must be re-programmed.[3]
Smartphones[edit]
On modern mobile devices such as smartphones, an over-the-air update may refer simply to a software update that is distributed over Wi-Fi or mobile broadband using a function built into the operating system, with the 'over-the-air' aspect referring to its use of wireless internet instead of requiring the user to connect the device to a computer via USB to perform the update.
Firmware updates are available for download from the [4] OTA service.
Mechanism[edit]
The OTA mechanism requires the existing software and hardware of the target device to support the feature, namely the receipt and installation of new software received via the wireless network from the provider.
New software is transferred to the phone, installed, and put into use. It is often necessary to turn the phone off and back on for the new programming to take effect, though many phones will automatically perform this action.
Methods[edit]
Depending on implementation, OTA software delivery can be initiated upon action, such as a call to the provider's customer support system or other dialable service, or can be performed automatically. Typically it is done via the former method to avoid service disruption at an inconvenient time, but this requires subscribers to manually call the provider. Often, a carrier will send a broadcast SMS text message to all subscribers (or those using a particular model of phone) asking them to dial a service number to receive a software update.
Verizon Wireless in the U.S. provides a number of OTA functions to its subscribers via the *228 service code. Option 1 updates phone configuration, option 2 updates the PRL. Similarly Voitel Wireless and StraightTalk, which both use Verizon network, use *22890 service code to program Verizon based wireless phones. Interop Technologies provides a number of nationwide wireless operators in the US with an SS7 Based Over-the-Air device management solution.[5] This solution allows operators to manage wireless device functionality including renumbering handsets, updating phone settings, applications and subscriber data and adjusting PRL to manage cost structures.
To provision parameters in a mobile device OTA, the device needs to have a provisioning client capable of receiving, processing and setting the parameters. For example, a Device Management client in a device may be capable of receiving and provisioning applications, or connectivity parameters.
In general, the term OTA implies the use of wireless mechanisms to send provisioning data or update packages for firmware or software updates to a mobile device — this is so that the user does not have to go to a store or a service center to have applications provisioned, parameters changed or firmware or software updated. Non-OTA options for a user are a) to go to a store and seek help b) use a PC and a cable to connect to the device and change settings on a device, add software to device, etc.
OTA standards[edit]
There are a number of standards that describe OTA functions. One of the first was the GSM 03.48 series.The ZigBee suite of standards includes the ZigBee Over-the-Air Upgrading Cluster which is part of the ZigBee Smart Energy Profile and provides an interoperable (vendor-independent) way of updating device firmware.
Similarities[edit]
OTA is similar to firmware distribution methods used by other mass-produced consumer electronics, such as cable modems, which use TFTP as a way to remotely receive new programming, thus reducing the amount of time spent by both the owner and the user of the device on maintenance.
Over-the-air provisioning (OTAP) is also available in wireless environments (though it is disabled by default for security reasons). It allows an access point (AP) to discover the IP address of its controller. When enabled, the controller tells the other APs to include additional information in the Radio Resource Management Packets (RRM) that would assist a new access point in learning of the controller. It is sent in plain text however, which would make it vulnerable to sniffing. That's why it is disabled by default.
See also[edit]
References[edit]
- ^'Mobile Phones — Mobile Explorer'. Microsoft. 2001. Archived from the original on 11 August 2001. Retrieved 19 April 2011.
- ^Gascón, David; Alberto Bielsa; Félix Genicio; Marcos Yarza (9 May 2011). 'Over the Air Programming with 802.15.4 and ZigBee - OTA'. Libelium. Libelium. Retrieved 28 May 2012.
- ^'Libelium.com 50 Sensor applications for a Smarter World. Get Inspired!'. Libelium.com. Libelium.com. 2 May 2012. Retrieved 28 May 2012.
- ^http://www.prestigio.com/news/firmware_updates/New_firmware_MultiPhone_4055_DUO
- ^'Alaska DigiTel Buys OTA Pgramming Solution from Interop Technologies'. Tmcnet.com. 2008-04-01. Retrieved 2012-02-02.
Retrieved from 'https://en.wikipedia.org/w/index.php?title=Over-the-air_programming&oldid=929018450'
C H A P T E R 11 |
Developing an Over-the-Air Test Package |
This chapter describes how to create an over-the-air (OTA) provisioning test package. It contains the following sections:
Test pack development is an iterative, non-linear process that varies according to local practices and preferences. As you read the following sections, remember that when developing tests you might perform some steps many times, and you might perform the steps in a different sequence than they are described in this chapter. You might also choose to build and test your developing test pack more frequently than this chapter suggests. If you use a source code control system, you might have to modify some instructions, such as “make the file writable.”
OTA Test Pack Development
OTA test pack development is quite different from runtime or benchmark test pack development. OTA test source files are essentially empty except for Javadoc tool class and case documentation and other markup (see Chapter 4). The Java Device Test Suite provides all OTA test code, which is driven by properties you specify. The test code does not run on a test device. It runs on the Relay.
In OTA tests, the Relay acts as a provisioning server. It performs these services:
- Upon test device request, sends HTML or WML with a link to a JAD file specifying a MIDlet.
- Upon test device request, sends the JAD file.
- Upon test device request, sends JAR file.
- Receives the installation status code sent by the test device after installation; for semi-automated OTA tests: compares this code vs. expected one and forms the result.
- Receives the result sent by test MIDlet (this is another specific mechanism: the installed MIDlet sends a result string to specific address on the relay, relay compares this string against the expected, and returns the test result.)
- Communicates with the test harness. It sends results, knows the current test ID and its properties, sends commands to display the test description, and so forth.
Each test has at least one associated MIDlet that the user downloads to the test device. You write these test MIDlets.
Program logic is different in OTA tests compared to other test types (where the test logic runs predominately within the test device). In OTA tests, the program logic is an interplay between the following.
1. The test MIDlet, installed successfully (or not) onto the test device, and executed in the device.
2. The installation procedure. The tester reads test instructions and interacts with the test device and the MIDlet.
3. The AMS, a part of the test device that manages the installation and launching of the MIDlet. For example, the AMS sends an installation status report to the relay after MIDlet installation.
To develop an OTA test pack, you must also know how to modify Ant build scripts.
Note - Compared to earlier releases of JDTS, OTA test development is different after JDTS version 2.0. However tests, written for earlier releases can run on a 2.0 harness with minor modifications. Follow the instructions in this chapter to develop new OTA tests after JDTS version 2.0. |
Writing an OTA Test
An OTA test has two sets of files:
- The test package files document the test, provide user instructions, and direct the execution of the generic OTA servlet. These files must be created in a subdirectory named by the testsuite.info file’s TestSourcesDir property. The sample test files are in devKitHome/ota/src/client/.
- The application files implement a MIDP application (MIDlet) that the user downloads to the test device when running the test. These files must be created in the directory named by the testsuite.info file’s MIDletSourcesDir property. The sample application files are in devKitHome/ota/src/apps/. Multiple tests can share the same test MIDlet.
See the property MIDletSourcesDir in the file devKitHome/ota/testsuite.info for an example of good paths to MIDlet source files. It is important to structure the paths to avoid namespace conflicts, and this is reflected in the directory structure of the OTA examples.
You can create the file sets in any order. This section describes how to write the files in a test package. Writing Application Files describes how to write application files.
Writing OTA Source Files
An OTA test source file is only a container for online test documentation and properties. It has no executable statements. The OTA servlet and, for some tests, the associated test MIDlet, do the work of the test. For a sample interactive test, see devKitHome/tests/ota/src/client/com/sun/samples/interactive/Interactive.java. Interactive and semi-automated test source files have the same format.
Security Certificates for a Test Class
Tests that use protected APIs must be granted permission to call methods in those interfaces. This is done by digital certificates in the test device which are associated with protection domains.
OTA test developers must specify the protection domain for the users of applications that use protected APIs. The available domains are specified in the MIDP specification.
Use the following syntax in a source file comment (see Test Class and Case Comment Blocks) to make a domain available to testers:
* @card.property SecurityDomain=DomainID
The SecurityDomain property value is the domain name (DomainID).
The DomainID is one of four OTA pre-defined domains or a custom domain (described later in this section):
- Untrusted
- Manufacturer
- ThirdPartyTrusted
- OperatorTrusted.
For example:
The preceding example means the OTA MIDlet packs associated with this test case are signed with a key setup user interface (using the Manage Keystores command and corresponding Configuration Editor pane) for the specified protection domain, so that the MIDlet suite are associated with this protection domain in the device where the MIDlet is installed.
In addition to the pre-defined domains previously mentioned, you can create custom domains. Custom domains map to specific certificates in their respective keystores. Custom domains as well as the default domains must be made apparent to the tester. The tester enters the domains in the harness Configuration Editor in the left pane under Over The Air Test MIDlets. Custom domain names have the following restrictions:
- Valid character entries are Latin letters, decimal digits, hyphens (-), underscores (_) or blank spaces ( ).
- Custom names must not start or end with blank character space.
For more information about protection domains, certificates, and keystores, see the Java Device Test Suite Test Notes and the administrator harness online help.
Writing Application Files
Every OTA test case has an associated application (MIDlet, technically a MIDlet suite). The test case’s evaluation file typically instructs the user to download the associated MIDlet to the test device.
Directory Structure
FIGURE 11-1 shows, on the left, a directory containing one test class that has two test cases. On the right, the figure shows the application files you must create for this example in which both test cases use the same application (MIDlet.java).
FIGURE 11-1 Test and Application File Correspondence
An application source file is a MIDlet, as defined by the MIDP 1.0 and 2.0 specifications. For an example used with an interactive OTA test, see devKitHome/tests/ota/src/apps/samples/interactive/PropExample.java. Multiple tests can use the same application if their source file comments name the shared application’s JAD file and JAR file (which are created by the build script). If a test requires its associated application to perform an operation on the test device, make sure that the application displays information that tells the user to click Passed or Failed in the evaluation window, and that the evaluation window instructs the user to launch the application.
In the same directory as the application, create a build.xml file. This file is application specific. See the samples in the subdirectories of devKitHome/tests/ota/src/apps/samples/ for examples. By default, all MIDlet JAD and JAR files are created in the directory specified by TestMIDletDir. You can have a MIDlet’s JAD file and JAR file created in a subdirectory by specifying a value for subDir in the following build.xml line:
Correspondingly, add subDir to all build.xml lines that contain MIDlet.dest.dir.
The @card.property tags in the source file must name the same directory. Here is a hypothetical example line from a build.xml file:
The corresponding source file lines are as follows:
In the same directory as the application, create a manifest file named manifest. The MIDP 1.0 and MIDP 2.0 specifications define the manifest file format and contents. See devKitHome/tests/ota/src/apps/samples/interactive/color/manifest for an example.
For MIDlets that use protected APIs, code the permission requests in the MIDlet JAD file and JAR file manifest. To see how these files are built, inspect devKitHome/tests/ota/src/apps/samples/signed/build.xml.
Application Logging
An application can send timestamped log messages by HTTP. In the test results, these messages are identical to those that runtime tests can create as described in Logging. To generate a log message, add the following line to the application’s JAD file:
CODE EXAMPLE 11-1 shows how to send a log message to the Relay. The class JdtsLogLevel defines the available log level constants, such as TRACE and DEBUG.
Additional Facilities for Interactive OTA Tests
The example in devKitHome/tests/ota/src/client/com/sun/samples/interactive/Interactive.java has test cases that illustrate several optional features of the interactive OTA test infrastructure:
- Basic MIDlet installation -t01BasicInstallation()
- Multiple MIDlets -t02InstallMoreThanOneMIDletSuite()
- JAR file without a JAD file -t03DownloadJarWithoutJad()
- Dynamic JAD file attributes -t04SetJADPropertyValuesOnRuntime()
- Per-test JAD file attributes -t05addSpecialJADAttribute()
- Advanced facilities of property expansion mechanism -t06multilayerPropertyExpansion()
- Custom MIME types for JAD files and JAR files -t07SetCustomMimeType()
- Static custom HTML/WML pages usage - t08InstallFromCustomHtmlWmlPage()
- Accessing the provisioning server URL from a MIDlet -t09getAnotherMIDletSuiteURL()