The following lists the Device Profiler tests you need to complete to determine the settings for a device.

On loading the Device Profiler, you are asked to perform the keypress test to define the keys the device has and also to define the keys being used for navigation in the Device Profiler application itself. This test checks for:

When asked to press a key:

You might need to perform the keypress test again after you have configured the correct canvas in order to detect the key code values for the soft keys.

If you find that different firmware for the same device returns different keypress values, when you add the device profile using the +Add-Update-Handset Ant task, you can enter a comma-delimited list of values so that mobile applications that use this device will work on all versions of the device.

Although there is no specific touchscreen test, the Device Profiler should automatically enable touchscreen support if it determines touchscreen support is needed. Alternatively, simply tap the screen, and if the particular device is touchscreen enabled, the Device Profiler should detect the touchscreen functionality. When touchscreen is enabled, the Device Profiler displays a 3x3 grid in the background of each screen. Tapping in the top, bottom, left and right squares emulates up, down, left and right keys being pressed in the Device Profiler, while tapping in the center square emulates the fire key being pressed.

The Canvas test sets the screen area for an application. For the Canvas test you choose the canvas that provides the most-usable screen area. Additionally, on some devices, you can manually alter the screen size beyond what the device returns to enable drawing outside of the indicated screen region.

The System Font test allows you to detect the best font to use on the device, and any adjustments that need to be applied when using it. Use Up and Down to cycle through the various options that you can change, with Left and Right changing the settings for each one.

The Gfx Speed test does not require user interaction. However, it is best to tap one of the device keys or the screen every few seconds to keep the phone from entering the screen saver mode because the screen saver mode might compromise the metrics that the Device Profiler is recording.

Sometimes a device needs an application to regularly call a threading sleep or wait so that the device can perform its other activities in the background. A normal indication that a device is not calling a threading sleep or wait when it needs to is that the application might run slow or keypresses might seem to lag. Use the Keypress2 test to adjust the sleep time per update to achieve the best keypress response time and frame rate.

The Sprite Width test allows you to indicate whether transparent images with odd pixel widths display properly. For this test, the Device Profiler displays two images. You indicate whether the two images are the same.

The Interrupts test defines how to detect interrupts for the device. For this test, the Device Profiler prompts you to perform various interrupts.

Press the Fire key to initiate an interrupt test. The Device Profiler will not detect the interrupt if you do not press the Fire key. For each interrupt:

If you find a device does not detect a particularly intrusive interrupt through these tests, it might be worth trying some tests in the run-time code of the Device Profiler to determine whether other detection methods might work instead. If you find something new that works, contact Software AG can be applied to all other devices.

The LCDUI Softkeys test defines LCDUI soft key functionality for the device. The Device Profiler application switches to MIDP1.0 canvas mode for this test. If the soft keys are not displaying as expected, you can alter the LCDUI soft key parameters. By using the soft keys themselves, you should be able to test the following soft key scenarios:

The RotCanvas test determines whether a user of the device can rotate the screen and whether the rotation is detected at run time. If the user can rotate the screen, the Mobile Designer run-time code detects the screen size for this device on each update cycle. The Resource Handler uses the information about the standard screen dimensions.

The Softkeys2 test determines whether the device detects LCDUI soft keys with the selected canvas. If the device does detect the soft keys, applications can use the soft keys to minimize screen intrusion.

The Vibrate test determines whether the device has a vibration feature. The Device Profiler attempts to execute the vibration feature and then prompts you to indicate whether the device physically vibrated or not (basically we don't want to assume that just because the device API claimed it worked that it actually did).

The Backlight test determines whether the backlight can be kept on continuously. The Device Profiler requires you to provide input to adjust and confirm the backlight timing.

The Transforms test determines whether the run-time image transforms work as expected. The transforms are displayed in the repeating order, as shown in the following image:

The Device Profiler prompts you to compare the images it displays to the reference image shown above.

The Browser Launch test determines whether the device can launch its Web Application Protocol (WAP) or Web browser successfully.

The SMS test determines whether the device can send an SMS message.

The Audio test performs several audio checks that prompt for user feedback to determine the best format on the device, whether a piece of sound plays, and whether the volume is configurable. The test also determines the best volume at which to play a sound, as well as a few other minor tests.

In the Mobile Media API for J2ME, there are audio parameters that Mobile Designer cannot identify by running the Device Profiler. If the audio does not work properly, you need to manually set these parameters in Mobile Designer for the device using the procedure described in Updating an Existing Device Profile in the Device Database. The following are the parameters to update: