Documentation | Airplay SDK

F.A.Q.

This document lists frequently asked questions, and answers, regarding the Airplay SDK.

Question List

Why does my application run in the Airplay Simulator but not on device?

When moving from Simulator development to testing the application on a device, there are sometimes discrepancies between the two environments that can cause errors.

By far the most common cause of failure on device with a build that works correctly in the Simulator is deploying the wrong data. Unlike the Airplay Simulator, only certain assets are deployed with the ARM build - those which are specified in the mkb "assets" block. See the MKB assets section of the tools reference.

It's a good idea to test the build in place using the ARM emulator by double clicking on the S3E file in the intermediate_files folder of the deployment. If this fails you can run your windows build with the exact same data using the mkb option s3e-data-dir to point to this directory.

If an application with the same data fails in the ARM emulator, but not in the Simulator you will need to debug the ARM executable using the ARM emulator. The most significant difference between x86 and ARM is that on ARM, pointers are always aligned, so casting a pointer to a type to a pointer to a larger type may cause a runtime exception. For example:

uint32 x[2] = { 0 };
uint8* p = (uint8*)&x;
uint32* p1 = (uint32*)p;
uint32* p2 = (uint32*)(p+1);
*p1 = 1; //will be safe, since p1 is 4-byte aligned.
*p2 = 1; //will work correctly on x86, but will raise an exception on ARM, because the pointer is not 4-byte aligned.

As with any change of compiler you may encounter other subtle issues with the compiler output. Debugging in the ARM emulator makes tracking down these issues easier.

Be particularly aware of any code that is #ifdeffed for architecture, platform or compiler.

It is sometimes useful to deploy a debug build to check for asserts etc. To do this, build the ARM debug configuration, then launch the deployment tool as normal by running the release build. You can select the debug build from the "build selection" step.

If the application runs in the emulator then it will normally run on device. If it doesn't, sanity check the tool chain by loading on an SDK example - ideally one which uses the same APIs. If the example doesn't work please contact Ideaworks - the examples should work. If the examples work but your application doesn't, it will probably be one of these issues (in rough order of likelihood):

Device configuration differences. Airplay is cross-platform, but it is still possible to write code that crashes on a particular device configuration. Try configuring the Simulator to match the screen size and other properties of the device. Also be aware of any code switched by the result of S3E_DEVICE_ID etc.
Hardware accelerated rendering is not available. If hardware accelerated rendering is not available Airplay Studio will fall back to software rendering. Since software rendering typically requires some configuration this will typically not work without fine tuning in the Simulator. You can simulate this case by setting the GLAPI to None in the Configuration->GL menu.
The application is not yielding enough. The application is not giving the device OS enough time to carry out its essential tasks. Solution: force the application to yield using the relevant functionality. For information on how to force an application to yield, see the S3E Device Interface section of the API Reference.
The device runs out of memory. Solution: reduce memory size in the application ICF file. The Airplay runtime will raise an error if there is not enough space to allocate the heaps, but devices sometimes behave badly as they approach out of memory.
APIs or functionality is not available. The vast majority of Airplay's APIs can be used in an entirely cross-platform fashion, but some things are not available everywhere. System Extension APIs (those starting with s3eExt) are typically not available on all platforms. Also, certain individual capabilities may not be available on some devices (For example, gl surfaces are irregularly supported at the HW level). Read API documentation for caveats regarding cross-platform functionality.
Windows Mobile compression is on but not supported. This option is only valid for Windows Mobile 6 and above, see here.

How will the profile setting on a device affect an application running on it?

Applications created using Airplay respect the Profile configuration selected on a handset. How this affects the application will vary to conform to the standard requirements for each given platform.

The most obvious effect of this is that if the Silent profile is selected on a handset, the Airplay application will produce no sound on start-up. On most platforms, using the functions contained in s3eAudio, s3eSound and s3eVideo to change the application volume while the Silent profile is selected will have no affect.

Other functionality such as the ability to vibrate using s3eVibra will also depend on whether the current profile allows these features to be used.

What is the best way to display non roman type fonts (for example: Japanese, Chinese, Korean,... characters)?

Displaying non-roman type fonts is easiest achieved by using the IwGxFont module, which supports rendering of texture based fonts and therefore supplies the potential to display localised text in virtually any character set. It uses specialised fonts which need to be created using the Airplay Studio Font Builder.

Note: Please be careful to save any text to be imported as a UTF-8 text file. (See the documentation of your editor on how to save files in this format)

Why do I get extra key events while debugging? Why can't I use print screen to take a screenshot?

The setting of "Use DirectInput in exclusive mode" in Preferences->Keyboard... determines the Simulator's style of interop with Windows.

In non-exclusive mode (the default) the Simulator places more nicely with the OS, and things like print screen and alt to use menus work. However, keys pressed during debugging are queued up and issued to the application when it resumes.

Exclusive mode has the opposite behaviour.

How can a "PTVert cache overflow" error be resolved?

This error occurs when IwGx runs out of post-transformed vertex cache. This is a hard limit on the number of vertices permitted within a single flush in SW transform. The limit can be increased using the "[GX] VertCacheSize" icf setting in the application icf file. The default will be too low for intensive IwGx applications.

The following [GX] icf settings also have an effect on the number of polygons which can be rendered at the same time: (all sizes mentioned are measured in bytes)

[GX] PolyBufferSize: Size of the buffer used for the draw-list. (SW renderer only)
[GX] DataCacheSize: Size of the global IwGx data cache.

Note: Obviously, increasing these values will require more memory.

Various IwGx functions will consume space in these caches.

They are only emptied by IwGxFlush() and IwGxReset(), so if you continue to run out of cache you may be calling IwGx functions but never calling IwGxFlush() or IwGxReset().

Note that the example framework makes some IwGx calls, so if you are using that framework you should flush even if you are not doing any rendering yourself.

For further reading please refer to the Airplay Performance Guidelines whitepaper.

How can an "s3e s3eMallocBase" or "Malloc" error be resolved?

Airplay applications run with a number of fixed heaps where all allocations (whether from malloc or new) come from. The runtime has a concept of the current heap. When a heap is exhausted a runtime error will fire reading "Heap x out of memory. Allocating n bytes but only n available..." The normal fix for this is to increase the size of heap x. This can be done using the corresponding [s3e] MemSize icf configuration. For example, if heap 1 is out of memory, [s3e] MemSize1 would need to be increased.

Additionally, Airplay Studio supports creating memory buckets inside these heaps via the IwMemory interface in IwUtil. If you are using any Airplay Studio modules the IwMemory subsystem will be active. By default, there are two buckets in use, the system bucket and the "SystemDebug" bucket. The "SystemDebug" bucket bucket is not present in release builds - it is used for debug features and resource building.

Out of memory errors from IwMemory will read "Malloc x from bucket "bucket" failed...". The size of the "SystemDebug" bucket can be changed using [s3e] MemSizeDebug. Applications can require very large amounts of debug space for building resources (especially compressing textures). On device, resource building is not enabled but a small amount of debug may still be required, so there is provision to provide a smaller sized bucket on device using [s3e] MemSizeDebugDevice.

What does "Bucket 0(System) is still in use (first allocation ID=n); deleting it is dangerous" mean?

This means that the application leaked some memory. Leaking memory is when allocations made using malloc or new are never freed or deleted before the heap is collapsed (this normally happens at shutdown).

The message mentions danger because collapsing a heap while allocations still exist in it will cause fatal errors if the program is still holding references into it.

Getting this message on shutdown is generally safe because the actual leaked memory itself (and any leaked system resources generally) will be harmlessly reclaimed by the Airplay runtime. However, leaks still normally indicate a formal problems with the application so it is best practise to fix them.

Note that when using Airplay Studio a custom memory allocator is installed by IwUtil. In Airplay Studio applications this warning will be raised by IwGxTerminate().

In Airplay Studio, the first allocation ID can be used to identify the leak as described here.

Be wary of classes which manage their own dynamic allocations. For example:

IwGxInit();
CIwArray arr;
arr.push_back(3);
arr.clear();
IwGxTerminate(); //error - arr still has memory allocated

CIwArrays can be forced to release their storage allocation using clear_optimised(). For STL containers there is not usually any way of freeing storage memory apart from deleting the container, for this reason static STL containers should be avoided.

How can .RAW sound data (for usage by the s3e Sound module) be created?

For creation of raw sound data files, any general purpose sound conversion utility can be used.

The SoX - Sound eXchange application is one of them and can be found here.

Example command lines are:

sox originalsound.wav convertedsound.raw rate 8000

sox originalsound.wav convertedsound.raw channels 1 rate 8000

How can two or more sounds (music and sound effects) be played at the same time?

Included in the Airplay SDK are two modules which deal with playback of sounds:

S3E Audio plays an assortment of file types, is platform dependent and relies on the functionality of the underlying OS. S3E Audio uses the capabilities of the hardware to handle various compressed audio file formats and should only be used for simple sound file playback, whereas S3E Sound exposes a multi-channel software mixer to ensure hardware independent functionality. Usage of the S3E Sound Module is therefore the "correct" way to achieve multi-channel sound.

Note: Due to hardware restrictions, on some devices it is not possible to use S3E Audio and S3E Sound simultaneously.

For further help, please use any of the provided examples :

How can I fix my application to landscape or portrait aspect ratio?

The icf setting [s3e] FixScreenOrientation can be used to fix the screen in a given aspect ratio. "1" means portrait and "2" means landscape.

The landscape setting will allow either landscape setting based on the device's orientation. Future revisions will expand the options available here...

What is the correct way of dealing with an "Out of T-Pages" error?

When using the software renderer, uploading textures moves them into specially allocated texture pages (T-pages). Each texture page is 256 bytes wide and 256 bytes high. The above error indicates, that there is no more space for further texture uploading left.

The default number of texture pages used for storing textures is 16, however the number of T-pages can be increased via [GX] icf setting in the application's icf, such as:

[GX]
NumTPages=EnterNumberHere

Note: Increasing the number of T-pages also increases demand for memory.
Before increasing this value determine if the increased demand for T-Pages is warranted. Often texture pages run out because new textures are constantly being uploaded without old ones being released. Another possible solution would be to determine which textures need to be available at a certain time and manage the uploaded textures (for example, depending on game level). IwGxVRAMDump() can be used to see the current state of the texture pages.

How can the sizes of polygon buffer, vertex and data cache be optimised best?

All three values correspond to different aspects of the drawing pipeline and can be changed via [GX] icf settings in the application's icf:

[GX] PolyBufferSize: Size of the buffer used for the draw-list.
[GX] DataCacheSize: Size of the global IwGx data cache.
[GX] VertCacheSize: Size of the IwGx software vertex cache.

It is important to note, that the amount of polygon buffer, vertex- and data cache used by primitives depends on several factors, including:

Modulation mode
Colour space
Alpha mode
SW or GL rendering

In order to determine the exact amount of these buffers used, the Airplay Simulator's metrics system should be utilized. It can be accessed via the "Metrics" entry in the menu bar of the Airplay Simulator: Choose "Display Metrics" to open the metrics display window, then expand "Airplay Studio", followed by "IwGx" in the tree control. All three buffer sizes are represented by the following entries:

"Vert Cache Entries"
"Poly Buffer Bytes"
"Data Cache Bytes"

Note: The vertex cache is actually displaying the number of entries, not the actual number of bytes used. However, the value being set in the ICF file also corresponds to the number of entries, not bytes, therefore the metrics display is still useful.

Using this system along with the polygon throughput (entry "Polygons Rendered" in the GX metrics page), it is straightforward, to determine maximum usage and therefore easy to optimise memory requirements.

Example:
Using the above described method, the following values have been determined for a given application, per rendered quad:

32 bytes of DataCache
4 entries in the VertexCache
60 bytes of PolyBuffer

with icf settings configured as follows:

DataCacheSize=100000 //allows rendering of 3125 (=100000/32) quads
VertCacheSize=10000 //allows rendering of 2500 (=10000/4) quads
PolyBufferSize=200000 //allows rendering of 3333 (=200000/60) quads

a maximum of 2500 quads could be displayed, as the limiting factor in this case would be the vertex cache.

Note: These numbers are an average. Various factors affect consumption of the caches, including lighting state, number of materials in the scene, etc.

How can the material of a CIwModel be changed once it has been loaded from file?

There are three different ways in which this can be achieved:

First use CIwModel::CloneWithNewMaterials. This function creates a new model, which points to the original model-blocks, except the standard primitive model-blocks, which are copied and pointed at by the newly created model. Once this is done, it is possible to modify the new model's m_Materials list, which is a public member of CIwModel, directly.

The second way to achieve this, is to set a different list of materials using IwGetGraphicsState()->m_OverrideMaterials, whereas m_OverrideMaterials is a pointer to the new materials to use by CIwModel's Render() function instead of its own material array.
Note: The overriding list must be the same length as the model's material array.

Pseudo-code:

CIwManagedList myMaterials1, myMaterials2; //contain alternative materials
IwGetGraphicsState()->m_OverrideMaterials = &myMaterials1;
pModel->Render(); //render with myMaterials1
IwGetGraphicsState()->m_OverrideMaterials = &myMaterials2;
pModel->Render(); //render with myMaterials2
IwGetGraphicsState()->m_OverrideMaterials = NULL;
pModel->Render(); //render with original materials

Finally, it is also possible to use IwGxSetMaterialFixed() if the model has only one material.

How can hardware supported floating point processing be taken advantage of?

Internally Airplay uses 1.3.12 fixed-point only in all the IwGx, IwGraphics and IwAnim pipelines (positions, normals, colours, UVs). This approach is often preferable to floating point even if an FPU is available. For example, on the iPhone GPU the use of 16-bits per component is half the bandwidth compared to 32-bits per component used by float. It is however planned to include an optional floating-point pipeline in future Airplay SDK versions.

If the application code itself makes heavy use of C++ float types, it is possible to create builds which assume hardware enabled float support via the arm-fpu icf setting, which is to be set as an MKB option. Note that a build prepared in this way will not run on devices with no FPU.

How can the function of "IwGxSetPerspMul" be interpreted correctly?

The IwGxSetPerspMul function sets the "perspective multiple", which is a way for the user to set the frustum's field-of-view. The "perspective multiple" represents the distance from the camera (the "eye point") to the viewing plane, whereas the viewing plane can be seen as the conceptual 2D plane onto which a 3D world is being projected on;
Note: The viewing plane is not the same as the near plane.

Example:
In order to obtain a horizontal field-of-view of 90 degrees, the perspective multiple would have to be set to equal to half the screen width:

IwGxSetPerspMul(IwGxGetScreenWidth() / 2);

What is the concept of pitch (e.g. S3E_SURFACE_DEVICE_PITCH)?

Even though a display surface is represented by a contiguous range of addresses, it is not safe to assume that the last pixel on one row exists at an address one byte below the address of the first pixel on the next row. The actual difference between two rows is called "pitch" and will be different on display adapters from different manufacturers.

Example:
The Basic Example contains a function fillScreen, in which the addresses of single pixels of the display surface are calculated by the following formula: y * pitch/2 + x. As this example is written using 16 bit colour information per pixel, the pitch which is usually calculated in bytes needs to be processed as 16 bits as well and therefore halved (=divided by 2).

In which order are valid s3e files executed?

First the application's icf file and the s3e.icf file in the same directory as the loader are checked for the "[S3E] gameExecutable" icf setting . Using this setting, an alternative pathname to the .s3e application executable to load can be specified in the following way:

[S3E]
gameExecutable="FileName.s3e"

Note: The alternative s3e files path needs to being specified as a path relative to the loader.

In case multiple "[S3E] gameExecutable" settings are encountered, an error is thrown, otherwise, the s3e file specified is loaded and executed. If unspecified, the loader scans the current directory for s3e files. If a single s3e file is found, it is executed. If multiple or no s3e files are found, an error is thrown.

How does command line input correlate to icf file settings?

S3E loaders on Windows and Linux platforms parse the command line options as follows:

"-myvar:myval" as a command line option is equivalent to the following line in the application's icf file:

[Commandline] myvar=myval

,while "-mysection:myvar=myval" as a command line option translates to the following icf setting:

[mysection] myvar=myval

How are paths handled in Airplay?

Paths in s3e are similar to those seen on other platforms. They are made up of an optional drive, a list of directories separated by either forward-slashes '/' or back-slashes '\' and usually a filename.

The drive specified is of the form '<drive>://' where <drive> is one of:-

'rom' : for the read-only portion of the s3e data area
'ram' : for the writable portion of the s3e data area
'raw' : for paths that will be passed directly to the underlying operating system without modification. These paths are for debugging only and are not supported in release loaders.

Paths can be up to a maximum of S3E_FILE_MAX_PATH (=128 bytes) long, including the NULL terminator. Longer Paths will cause an "S3E_FILE_ERR_INVALID_PATH" error to be thrown.

Paths in s3e are not case sensitive. Any slashes at the beginning of the path will be ignored. Duplicate separators (mydir//myfile) are automatically reduced to a single separator (mydir/myfile). The use of the previous directory '..' is permitted in paths, provided that the path does not resolve to one that is higher than the root.

Examples of valid paths are:

myfile
rom://myfile
mydirectory/myfile
MYDIRECTORY\myfile (same as mydirectory/myfile)
/MYDIRECTORY\myfile (same as mydirectory/myfile)
/MYDIRECTORY\\myfile (same as mydirectory/myfile)
mydirectory/ignored/../myfile (same as mydirectory/myfile)
raw://c:\temp\myoutputfile (for debugging only!)

The concept of different S3E Drives (ram, rom, and raw), is very powerful and explained in detail in the Airplay concept's data section. This section also explains, why using explicit drives in paths is a discouraged practice.

What does the error message "System malloc failed allocating x bytes" upon application startup mean?

Airplay applications can only allocate memory from a number of separate heaps through the S3E Memory API. These heaps are created using native operating system memory on application startup. If the asked for heapsize is bigger than the available memory on target device, the above error message is being displayed.

This means that the application needs to reduce the amount of memory it uses before it can run on this device.

Which icf settings can be used to manipulate the memory heap?

The ICF file settings for game heap configuration, which are part of the [S3E] group, are as follows:

The user can create up to S3E_MEMORY_MAX_HEAPS (=8) different memory heaps for use. Most of the times one or two heaps are sufficient though.

The size of each heap is specified by specifying MemSize<x> = <size> Where x is the heap number (1-8) and <size> is the desired size of that heap:
Example:

[s3e]
MemSize5=100000

Creates heap 5 of size 100000 bytes.

If MemSize<x> is not present for a heap or <size> is zero then the heap is not created. The only exception is heap 0 (the main application memory heap), which will be created with a default size of 4Mb on Device or 10Mb on Windows/Linux if no size is specified.

Switching between different heaps in the user application is done by the function s3eMemorySetInt(S3E_MEMORY_HEAP, x). Subsequent allocations will be done from the selected heap. There is no need to switch back to the correct heap to free or reallocate a memory block, because s3eFree/s3eRealloc will always free/realloc from the appropriate heap.

MemSize=<size> (without a heap specified), behaves as an alias for MemSize0=<size>

There are several options for configuring each heap. These options are specified in the following manner:

MemFlags<x>=<flag1>,<flag2>,...,<flagn> where <x> is the number of the heap and <flag1>, <flag2>,... are one or more of the following:

NO_MSG_ON_FAIL : prevents s3e from displaying out-of-memory dialogs if allocations fail on the specified heap
USE_STACK_ALLOCATOR : uses a simple stack based allocator for the heap instead of the usual memory allocator. This can minimise memory wastage if the heap is to be used in a purely stack based fashion (first allocated is last freed)
INACTIVE : prevents the heap from being initially created (and therefore prevents it consuming OS memory). The heap can then be instantiated later with a call to s3eMemoryHeapCreate. Likewise calling s3eMemoryHeapDestroy on any heap will free all OS memory used by the heap and put it in an inactive state. All attempts to allocate from an inactive heap will fail immediately.

How can I use native platform code in my application?

Unfortunately the short answer is that you can't. Airplay's cross-platform binary works because it contains no platform specific code.

However, we recognise that there is an interest in allowing this and we are evaluating possibilities...

When will feature x be included in the SDK?

Airplay's roadmap is governed by internal requirements and the requirements of Pro and Premium licensees. Forum requests and feedback are still very welcome, but please add a "me too" to an existing thread rather than starting a new one.

Pro and Premium licensees can approach us directly through their bespoke support sites to discuss new features.

Releases are on a roughly 3 monthly basis, and we should be able to tell you whether a feature is to be included in the next release (or the one after that).

How to configure the BREW 3.1.x Simulator to be able to test socket functionality?

Upon Simulator startup, an image of a device, defined in the device configuration file (.qsc), is opened up. Included in this file is the following line

SOCKETS 1 0 0 0 1472

Whereas: SOCKETS <nSocketLimit> <bListenAccept> <bShutdown> <bLoopback> <nMaxSendTo>

nSocketLimit: maximum number of sockets. Default: 1
bListenAccept: the device supports Listen/Accept(). Default: 0
bShutdown: the device supports Shutdown(). Default: 0
bLoopback: the device supports a loopback interface (i.e. 127.0.0.1). Default: 0
nMaxSendTo: the maximum payload size for UDP datagrams sent via OEM_SendTo(). Default: 1472 bytes

Correct socket functionality can be tested, by increasing the number of sockets and at the same time turning the Listen/Accept flag to "on", resulting in the following:

SOCKETS 2 1 0 0 1472

Note: It is possible, for device images running on the BREW 3.1.x Simulator, that the SOCKETS parameter may not work. In this case the IDS_DD_DATA_MAX_UDP and/or IDS_DD_DATA_MAX_TCP values need to be configured in the .dsd file.

The behaviour does not occur on the BREW 2.1.x Emulator.

How are BREW "Debug Key Sequences" activated and what is their effect?

Debug key sequences are intended for use by developers to assist in troubleshooting BREW application errors. Unfortunately, phone behavior may be adversely impacted when debug sequences are active ? including crashing the device. As such, BREW applications should be designed in such a way that the user is not likely to inadvertently enter a debug sequence while interacting with the application. This is primarily a concern on BREW 2.0 devices, as later BREW versions incorporate protections to prevent unintentional debug mode activation. If there is a large potential within a BREW application for accidental debug mode activation during typical use cases, NSTL may fail the application.

Debug sequences may be activated at any time while BREW is active ? including within the BREW applications manager.

Behaviour in the different BREW versions, is as follows:

BREW 2.0: The debug sequences are enabled by default - regardless of whether the phone has been test-enabled. To activate the debug sequence, enter ###
BREW 2.1, 3.0: Debug sequences are enabled only if the phone is in test-enabled state. To activate the debug sequence, enter ###
BREW 3.1+: The debug key sequence has been lengthened, reducing the likelihood of accidental activation. To activate the debug sequence, enter ###BREWDEBUG#, then ###[debug type]#

The initial ### sequence before the debug type is OEM-configurable. For example, LGE has opted to use ********** (10 * keys) rather than ###. Most OEMs use the default sequence. However: The LG VX6000/4500/4600 line, for example uses **********X as the sequence. The LG VX7000/8000, on the other hand, uses #######X and On other VX8000's it's *******X ( '*' 7 times ). This information is typically documented on the known issues page for each device.

The different debug types are listed below:
0: Turn Debugging off. This debug key sequence resets/toggles off all debug states.

1: Memory validation on every heap access. BREW walks the heap to determine if the pointer is in valid range and will not over-write/over-read a heap node. An exception will be thrown if the heap access will cause corruption of a heap node.

2: Net Debug Tool: The "Net Debug Tool" can be used to view the device's network (socket and PPP) states while your application is running. When the Net Debug Tool is turned on, a box will appear in the right hand corner and will display a series of codes that can be used to determine the state of your application's data call. The codes vary depending on BREW version and are shown below:

Network State Codes:
BREW 1.0:

c : Socket Connecting
C : Socket Connected
x : Socket Closing
X : Socket Closed
I : Socket Idle
R : Socket Read
W : Socket Write
d : PPP Opening
D : PPP Open
- : PPP Closing
O : PPP Closed

BREW 1.1:

c : Socket Connecting
C : Socket Connected
x : Socket Closing
X : Socket Closed
I : Socket Idle
R : Socket Read
W : Socket Write
r : Socket RecvFrom
w : Socket SendTo
d : PPP Opening
D : PPP Open
z : PPP Closing
Z : PPP Closed

BREW 2.0:

c : Socket Connecting
C : Socket Connected
x : Socket Closing
X : Socket Closed
I : Socket Idle
b : Socket Bind
B : Socket Bound
R : Socket Read
W : Socket Write
r : Socket RecvFrom
w : Socket SendTo
v : PPP Opening
= : PPP Open
v : PPP Closing
# : PPP Closed
< : PPP Sleeping
& : PPP Asleep
> : PPP Waking

3: "Largest Available Heap Block": Displays the maximum size block that can be allocated on the heap in the upper left corner of the screen.

4: "Debug Privileges": This debug sequence is not yet implemented.

5: "Debug Malloc": Throws an exception on malloc failure.

6: "Debug Null": When this debug sequence is turned on, every Nth MALLOC will fail, even if RAM is available. Currently, N is set to 100.

7: "Sync/Async DBGPRINTF": This debug sequence toggles between two modes: synchronous DBGPRINTF and asynchronous DBFPRINTF. In synchronous DBGPRINTF mode, BREW waits for certain duration before returning from a DBGPRINTF statement in order to allow time for the DBGPRINTF message to be sent on the serial port. In the default, asynchronous mode, the DBGPRINTF returns immediately.

8: "Debug Dump Modules": This debug sequence is not yet implemented.

9: "Debug Dump Heap": Every time this sequence is pressed, heap and resource usage information is dumped on the emulator debug window or onto the Serial port. The heap info consists of the number of bytes, the system that allocates it, an internally used index, the file name and line number, and whether the memory is locked (L) or unlocked(U). Additional information is displayed on Allocated and Free RAM, and resource usage.

How can the APN (Access Point Name) setting be changed on BREW WCDMA handsets?

Changing of the APN setting can be achieved by using any modem control application, like HyperTerminal (which is part of Windows) or minicom (for Linux users). The first step is to connect the modem control application to the handset. The actual settings change is done using an AT command. AT commands are instructions used to control a modem, whereas AT is the abbreviation of ATtention.

In order to change the APN, the following line should be used, where "newAPN" represents the new Access Point Name:

AT +CGDCONT=1, "IP", "newAPN"

How can handset signature files (.sig) using MEIDs rather than ESNs be created?

Signature files can be created using either ESN, IMEI or MEID, whereas:

ESN (Electronic Serial Number): Are control numbers used for cell phone activation in wireless carrier networks. ESN-DEC are 12 numeric digits long and ESN-HEX are 8 numeric digits long.
IMEI (International Mobile Equipment Identity): Are numbers unique to every GSM and UMTS mobile phone used to identify valid devices. IMEI are 15 digits long.
MEID (Mobile Equipment Identifiers): Are unique numbers found on CDMA mobile phones. MEID are 15 alpha-numeric digits long followed by six zeros and a serial number.

On BREW handsets, the MEID printed on the back is only 14 digits long. Attempting to generate a sig file using only 14 digits will fail, because the form of an MEID is:

First 8 digits from the manufacturer's code
Next 6 digits from the serial number
The last digit (0 to 9) is the check digit

Therefore, if the handset MEID are only 14 digits long, correct length for the Qualcomm signature generation site can by accomplished by simply suffixing the MEID with an additional digit; Which in effect creates an arbitrary check digit.

How can PCM streaming be disabled in the Brew 3.x Simulator?

Since PCM streaming is a very expensive functionality, it is sometimes useful to disable PCM streaming in the Brew 3.x Simulator, in order to run applications at a sensible speed:

To disable it, open the ".dsd" xml file from the device pack, using a text editor and change the IDS_AEECLSID_MEDIAPCM section accordingly:

Example:

The original entry:

<String Id="8219" Name="IDS_AEECLSID_MEDIAPCM">

<Text>16798993,1,65536,65537,65538,65539,65540,65541,4,5</Text>

</String>

The second argument in the comma delimited list needs to be set to "0":

<String Id="8219" Name="IDS_AEECLSID_MEDIAPCM">

<Text>16798993,0,65536,65537,65538,65539,65540,65541,4,5</Text>

</String>

How does Airplay support pinch-in/pinch-out gestures on multi-touch devices?

The Airplay SDK (as well as the Apple iPhone SDK) handles gesture detection explicitly based on touch information. The s3ePointer Module -which supports multi-touch- provides the functionality to retrieve and set pointer state information;

Pinch-in/pinch-out gesture detection can be implemented in the following way: On receiving either an s3ePointerTouchEvent or s3ePointerTouchMotionEvent, query the m_TouchID member, which is being uniquely, generated by the system for every active touch point. As the user touches and drags, all the events associated with that touch point will retain the same ID. Therefore when a 'pinch action' is being performed, you will receive events with two distinct IDs, which can be easily identified and processed.

Testing can be done using the Airplay Simulator. Make sure though that multi touch simulation is enabled by checking the "Report multi touch available"-checkbox from the Configuration->Pointer... entry in the menu bar. Use the middle mouse button to add, drag and remove touches.

Why does my iOS application - that was successfully signed using the Deployment Tool/iPhone Re-Signer - fail to get through submission on iTunes Connect?

A message similar to: "The binary you uploaded was invalid. The signature was invalid, or it was not signed with an Apple submission certificate." will be displayed. The likely cause is that the .mobileprovisioning file specified during deployment was not valid. For Distribution builds, a .mobileprovisioning file must be specified but an application can successfully be signed without it being valid since it is only used for checking validity when installing to devices, not during the signing process. A common error is to include a profile that is linked to a Developer certificate rather than a Distribution one. Check the details of the profile in XCode or the iPhone Developer portal.

Why is the Windows Mobile CAB compression option disabled by default?

Cab (installation) files support a compression option which can be set through the 'Compress cab' deployment option (see Windows Mobile Configuration Settings) or corresponding winmobile-cab-compress MKB Setting (see MKB Deployment Options).

This is only supported by devices running the Windows Mobile operating system at version 6 or newer. When attempting to install a compressed cab on an older device - e.g. a smartphone running Windows Mobile 5 - the application will fail to install, and usually without providing useful feedback to the user. For this reason, this option is disabled by default and should not be used if you intend the application to be deployed to any devices running a Windows Mobile version older than version 6.

Why does my Windows Mobile application CAB file fail to install?

Windows Mobile builds can fail to install for various reasons, however the OS will in many cases just display a generic "Installation of <app name>.cab was unsuccessful".

Likely reasons for installation failure:

Invalid security settings: The device may not have the correct security certificates or profile setting to allow unsigned/development applications to be installed. See Windows Mobile Platform Security. If you can run the application on the device but not install it via a CAB file (by doing "package Install and Run" from the Deployment Tool or just copying the exe to the device, then it is more likely to be that the CAB is broken (see below) than to be a security issue.
Lack of disk space: Check the amount of free memory from the devices options menu. If the memory is close to full, free-up some space or install to a memory card. If the CAB file itself is large, a sensible idea is to place the CAB on a memory card but install to the main drive, or vice-versa.
Compression not supported: Compressed CAB files are not supported on Windows Mobile 5.x devices (see here).
Broken CAB file: The CAB creation process will allow files to be built even if some settings are invalid. For example, invalid filenames are generated if the application name contains characters that are not valid in windows file paths. The Airplay Deployment Tool aims to avoid these issues by performing additional checks. If the device has the correct security settings and enough memory to install, then it is likely the CAB is broken. Please visit the airplaysdk.com for assistance.

Why does the Nokia N95 report s3eAccelerometer as unavailable despite having accelerometer hardware?

The N95 is available in various versions, with different version offering differing levels of accelerometer support. Some early models have no accelerometer hardware at all. Later models include the hardware but accessing it through normal Symbian APIs is disabled. Nokia R&D Labs released an update for these devices, in the form of a .sis file the user must install to the device, that will enable accelerometer access. This should be easy to find with a web-search for "n95 accelerometer plug-in". Note that on some devices the plugin may still not have any effect due to a limitation imposed by the firmware.

F.A.Q.

Question List

Airplay in the Simulator:

Airplay on device:

Airplay Concepts:

Airplay Features:

General SDK Questions:

BREW Related Questions:

iOS Related Questions:

Windows Mobile Related Questions:

Symbian Related Questions: