Xperia Panel certification requirements Sony Ericsson

Transcription

1 Specification April 2009 Xperia Panel certification requirements Sony Ericsson

2 Preface Sony Ericsson Developer World At developers find the latest technical documentation and development tools such as phone White papers, Developers guidelines for different technologies, Getting started tutorials, SDKs (Software Development Kits) and tool plugins. The Web site also features news articles, go-to-market advice, moderated discussion forums offering free technical support and a Wiki community sharing expertise and code examples. For more information about these professional services, go to the Sony Ericsson Developer World Web site. This Specification is published by: Sony Ericsson Mobile Communications AB, SE Lund, Sweden Sony Ericsson Mobile Communications AB, All rights reserved. You are hereby granted a license to download and/or print a copy of this document. Any rights not expressly granted herein are reserved. Fourth edition (April 2009) Publication number: This document is published by Sony Ericsson Mobile Communications AB, without any warranty*. Improvements and changes to this text necessitated by typographical errors, inaccuracies of current information or improvements to programs and/or equipment, may be made by Sony Ericsson Mobile Communications AB at any time and without notice. Such changes will, however, be incorporated into new editions of this document. Printed versions are to be regarded as temporary reference copies only. *All implied warranties, including without limitation the implied warranties of merchantability or fitness for a particular purpose, are excluded. In no event shall Sony Ericsson or its licensors be liable for incidental or consequential damages of any nature, including but not limited to lost profits or commercial loss, arising out of the use of the information in this document. 2 April 2009

3 Trademarks and acknowledgements Xperia is a trademark or registered trademark of Sony Ericsson Mobile Communications AB. Microsoft, Windows Mobile and ActiveSync are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners. Document history Change history Doc. no Document published on Developer World Doc. no Minor updates 3 April 2009

4 Contents Contents...4 Introduction...5 Supported device...5 Certification benefits...5 Test lab...6 Signing...6 Test cases for Xperia panels...7 General requirements for Xperia Panels...7 UI/shell support requirements...8 Functionality requirements...11 Display options...14 Special circumstances and additional requirements...14 MFC applications...14 SDI/file-based applications...14 Input methods (IMs)...14 Links April 2009

5 Introduction Xperia Panels are Microsoft Windows Mobile applications that extend the Today Screen API in order to provide a full screen immersive experience. Developers can create Xperia Panels for the Xperia X1 phone using the Sony Ericsson Xperia SDK. Xperia Panels should not use the regular path of the Microsoft Mobile2Market program for certification and application testing and signing. For certification of a Xperia Panel, the Panel should comply with the test cases and criteria listed in this document. The Panel should then be tested by an independent test house and signed with the same certificate as is used by the Mobile2Market program. Panels are signed for normal API access. There are two types of Xperia Panels with different testing requirements: Native Panels Web Panels Note: Panels tested and certified against the criteria in this document are not Mobile2Market logo certified. Information about Mobile2Market certification is found at: Supported device Sony Ericsson Xperia X1. Certification benefits Certifying your Panel through the Xperia Certification Program provides great marketing opportunities: Certifying your application allows you to use the "Certified for Xperia X1" logo in your marketing materials. The Certified for Xperia X1 certification is specifically targeted for the Xperia X1 phone and sets the highest quality bar for your applications. Xperia Certification and Signing is required for participation in Sony Ericsson promotional activities, including the Sony Ericsson distribution channels. 5 April 2009

6 Test lab Testing and certification of Xperia Panels is performed by the independent test house NSTL, Inc. NSTL is an authorized independent test lab for both Microsoft Windows Mobile based Pocket PCs and phones. Information about NSTL is found at Signing The next step, after a Panel has been certified by NSTL, is to have the Panel signed. Xperia Panel signing is performed by VeriSign, Inc., an authorized Certificate Authority (CA). VeriSign Authenticated Code Signing (ACS) enables Xperia Panel developers and publishers to secure their Panels for trusted delivery and execution on the Xperia X1 phone. The Sony Ericsson Xperia X1 phone is a Windows Mobile 6.1 professional device and it uses the onetier prompt security profile: Authentication Level Signed for Privileged Execution Signed for Normal Execution One-Tier prompt security profile Application is able to use normal and privileged APIs, modify secured registry locations and run preboot Application is able to use normal and privileged APIs and modify secured registry locations Unsigned Application may be prevented from executing An overview of the Verisign signing process, is found at 6 April 2009

7 Test cases for Xperia panels General requirements for Xperia Panels Install Mandatory Native/web Panel applications should be submitted as CAB files. Optionally a setup package that works on the desktop through Microsoft ActiveSync may be distributed in addition to the required CAB file. Panels must be installed to the Windows Mobile Professional platform using the application installation mechanism. There should not be any errors or warnings during the installation. When installed, the new Xperia Panel should be possible to select via the Panel Manager. A Panel specific image should be visible in the Panel Manager Uninstall Mandatory Native/web When the user uninstalls the Panel, any Panel related data should be erased from files or the registry and leave as little as possible behind. If possible the application should use the Uninstall_Init() and Uninstall_Exit() functionalities to clean up data files and databases. It must be possible to uninstall the application by selecting Start - Settings - System - Remove Programs from the menu. After uninstall, the Panel must not be available in the Panel Manager Registry Optional Native Do not write in other registry keys than HKEY_CURRENT_USER (HKCU). Panels writing to the registry must only use a sub key under HKEY_CURRENT_USER. The other keys (HKLM and HKCR) are intended for system services and drivers 7 April 2009

8 UI/shell support requirements Consistency of the Menu Bar and NavBar is very important. The basic order, left to right, should be consistent with Pocket Word and support the left and right soft keys. The NavBar is located at the topmost part of the screen NavBar Mandatory Native Panels may not use NavBar for anything application specific. Other than the alert and notifications systems supplied through the API, Panels may not use the NavBar area for any additional functionality, such as subtitles of the current view, controls, tool bars, status icons, and so on. Fullscreen mode Mandatory Native System Support is used to implement full screen mode. Panels may only hide the NavBar with the shell API SHFullScreen(hwnd, SHFS_HIDETASKBAR). This API places the NavBar directly behind the calling Panel in the Z-order. This way, if the Panel goes away for some reason, the NavBar will be displayed immediately. In general, it is not recommended to hide the NavBar because the Start menu is the primary navigation mechanism on the phone. If a full screen Panel is sent to the background, the NavBar must be immediately displayed SIP button Mandatory Native The SIP button control should only be displayed in the standard locations. The SIP control should be displayed continuously in most Panels, and only be hidden in the rare case where no input of any kind is possible (for example in full screen mode of a game). Hiding/showing the SIP button should not be used excessively to avoid confusion of when it will be available it is far more confusing if it is hiding and showing repeatedly than if the SIP control is visible also in some views where no input is possible. The standard location of the SIP button control for Windows Mobile 6.0 is centred above the Menu bar Soft key support Mandatory Native The use of soft keys enables easy one-handed operation of the device. In addition to soft keys, the Panel may provide a command bar with bitmap buttons. The command bar is optional. It may be provided if necessary, but it cannot replace the soft keys 8 April 2009

9 Menu on right soft key Mandatory Native If the Panel uses a menu, the menu must be activated by the right soft key. The left soft key must be for quick (common) actions, such as New. If a second menu is used, it may be assigned to the left soft key Screenshot settings/information Mandatory Native/web The Panel must have a default Xperia Panel image, which is displayed in the Panel Manager and while the Panel is being loaded. The following default Panel image formats must be supported: Landscape 200x94, 24bpp Portrait 120x174, 24bpp Portrait Large 240x348, 24bpp Landscape Large 400x188, 24bpp Notification system not duplicated Mandatory Native Panels that display time or event based notifications must use the provided notification system for this purpose, that is, Panels may not create their own notification system Functionality duplication Mandatory Native No duplication of functionality provided by the Microsoft Pocket Outlook Object Model is allowed. Panels that use PIM-type data (appointments, contacts, tasks) must use the Microsoft Pocket Outlook Object Model. This is required to maximise available user storage space by preventing the storage of superfluous PIM data items. Additionally, use of the Microsoft Pocket Outlook Object Model provides a consistent user interface and simplifies communications MAPI functionality not duplicated Mandatory Native Microsoft Windows Mobile MAPI functionality may not be duplicated. Panels are required to use the universal Inbox provided by MAPI (Message API) where appropriate. For example, some communication applications (such as two-way paging applications) may require better functionality than MAPI provides, and are exempt from this requirement. All other Panels, however, are expected to use the provided universal Inbox Support for wait cursor Mandatory Native/web Panels must display a wait cursor (for example, the standard colour wheel) when asked to execute a command that renders the current window, or when the system as a whole is unresponsive to user input for more than 0.5 seconds. When the wait cursor is displayed only in the current window, the user may continue to interact with other windows, including the NavBar 9 April 2009

10 Input Panel Mandatory Native Panels must handle the Input Panel appearing and disappearing. From the UI perspective, the Panel must be designed to account for the fact that an 80-pixel tall Soft Input Panel (SIP) may be docked in the area immediately above the command bar at any time, requiring the application to be resized out of the way. The specific requirements are: All text entry fields must be accessible with the SIP visible. This can be accomplished either by placing all edit fields high enough on the screen so that they will not be obscured by an 80 pixel tall SIP, or/and by having a scroll bar when the SIP is displayed. Panels must resize in response to docked input methods. This includes resizing and/or shifting things like dialog tabs, status bars, and other elements as needed, and/or resizing or drawing scroll bars to ensure that all UI is accessible while an 80-pixel tall SIP is visible. Note that a docked input method may be as tall as 140 pixels, but applications are not expected to be optimised for a SIP height greater than 80 pixels Avoid controls on bottom 80 pixels Optional Native/web In some cases where landscape orientation may be used, it is recommended that Panels avoid putting controls on the bottom 80 pixels. Dynamic scrollbars in dialogs and prop sheets will be added if the controls fall below the 240x240 screen area. However, relying on dynamic scrollbars is discouraged. It is strongly recommended that Panels are designed to resize controls to fit the available screen size Help and About Optional Native/web Help systems integrated with System TOC. Panels should include a help file containing application information and about information. About information shall include application vendor, application title and application version. Applications that provide on-device help files are required to register their help system with the Windows Mobile Professional Help System Table of Contents, so that users have one entry point for help on all installed applications. This requires that all help content is authored in HTML format. Because general application and context-sensitive help is accessed via the Start Menu (for the current window), applications must not provide another access point, in order to ensure consistency across the platform User settings Mandatory Native/web The Panel must preserve user settings, including regional settings, theme colours, and so on. Panels may alter connectivity settings if required, but must notify the user before making the change 10 April 2009

11 Hard coding colours of dialog boxes Mandatory Native/web Colours should not be hard coded into the Panel. For example, to use the default system colours, the Panel should use GetSysColor() or the SystemColors class. The Panel should display properly in any theme Functionality requirements Application stability Mandatory Native/web Xperia Panels must be fully functional and stable on Xperia phones. All functionality must be in place when the panel is submitted for testing. The panel should not adversely affect the overall stability or performance of the device environment. The panel must recover from standby/suspend situations on the phone. The panel must also be well behaved with Shell and system features, such as not compromising hardware button functionality or overriding other Shell or system features, unless it is required for the proper functioning of the panel Hopper test Mandatory Native The Panel shall pass 25 hours of the Microsoft Hopper test. The Hopper utility is included in the Windows Mobile Professional and Standard SDKs available for download at: 3D48091A390B&displaylang=en Rapistart from Windows Mobile Power Toys can be used to run Hopper on a particular Panel as follows: rapistart.exe hopper /agames\solitaire.lnk In this example, Hopper clicks the Start menu, then Games and then clicks on Solitaire. The command line version does not support spaces. The Windows Mobile Power Toys are available for download from: Once installed, a shortcut to the directory of files is placed in the Start menu under All Programs. It is easiest to start a command prompt and type: cd "\Program Files\Windows Mobile Developer Power Toys\RAPI_Start" The rapistart.exe command is then executed from there. Place the hopper.exe file in the root of the file system on the phone 11 April 2009

12 Application verifier Optional Native The Microsoft AppVerifier test is used to evaluate memory leak performance of the Panel. This test is bundled with the Microsoft CETK tests and verifies that there are no memory leaks in the Panel. It can also detect some forms of heap corruption. Exceptions: AppVerifier will not run on managed code, that is,.net applications. Any errors associated with the Load/Free Library. Any leaks associated with the menu bar. Errors associated with pimstore.dll and mscoree2.dll. Error linked to DefWindowProc, the API used to invoke default window processing for any window messages not explicitly handled by the Panel Antivirus screening Mandatory Native/web The Panel shall be free of viruses and malware. Note: The ISV is not required to perform this testing but should be aware that the ITL (Independent Test Lab) will be screening the Panel for viruses and malware Help must be functional Mandatory Native/web Any online help included with Panels must be fully functional at the time of testing. At minimum, the help system for the device must be activated via Start/Help from anywhere within the application Must not assume external storage Mandatory Native Panels must not crash, hang, or exhibit adverse behaviour if no external memory card is installed Graceful Panel shutdown Mandatory Native Because Panels will be shut down by the Shell without the user taking any explicit action, Panels must shut down gracefully. This means not displaying any dialog boxes or other UI, not consuming excessive CPU time, and not consuming significant additional memory while closing Restoration of state when starting Mandatory Native Because the phone user will not have any concept of which applications are and are not running, Panels must restore critical state when launched. Note that this requirement does not mean that the complete state must be restored, although this would be ideal. The goal is for the user to feel comfortable returning to the application, whether or not it was shut down since last used. For example, Panels should restore the user to the previously selected view and scroll state, if applicable 12 April 2009

13 Non-full screen dialog boxes displayed out of the way of the input panel Mandatory Native Any non full-screen dialog box should be vertically centred in the area above the standard, 80-pixel high Input Panel when it is displayed. It must be placed in this space even if the Input Panel is not currently displayed, since if the user displays the Input Panel, no part of the dialog box will be hidden by the Input Panel. If the dialog box is taller than the space available when the Input Panel is displayed, the dialog box must be butted against the top of the screen. Message box text should be informative but brief to avoid part of the message box potentially being hidden behind the SIP No underlined accelerators in menus or dialog boxes without alternative selection methods Mandatory Native Underlined accelerators are allowed, however no functionality must depend on the use of accelerators. There must always be a way to access the functionality with a stylus tap No shortcut sequences Mandatory Native Because the presence of a physical keyboard is not guaranteed, shortcuts such as Ctrl+N for New must not appear on toolbars, ToolTips, PopUp help, or other controls such as menus. Note: Support for the Ctrl+Q, Power User, shortcut, which exits the current application, is recommended, but this shortcut item may not be visible on screen Long file name support Mandatory Native Panels must: support long file names as described below use long file names for displaying all documents and data file names in the Shell, in dialog boxes and controls, and with icons hide the.xxx extensions in the Panel itself (strongly recommended) use the common dialog boxes to save and load files (recommended). Panels that save files that are exposed to the user must support long filenames (LFNs) with all the following required features: Users must be able to enter file names of 128 characters, including all uppercase and lowercase standard characters, embedded spaces, embedded periods, and so on. Leading and trailing spaces must be stripped by the Save As command. It is not necessary to allow leading and trailing periods. These may be stripped by the Panel. Question marks anywhere in the file name must prevent the file from being saved. No error message needs to be displayed. The plus sign (+), comma (,), semicolon (;), equals sign (=), left square bracket ([), and right square bracket (]) must be supported anywhere in the file name, including leading and trailing. Embedded periods must also be supported. These should not cause any error conditions 13 April 2009

14 Display options Screen agnostic Mandatory Native Dialog box controls such as text boxes, group boxes, listview controls, and so on, must dynamically size to fill available space regardless of the screen orientation. To obtain the available screen size at runtime, APIs like GetSystemMetrics or GetClientRect should be used. Dialog box controls should be positioned or stretched based on the screen size queried at runtime Special circumstances and additional requirements MFC applications Panels that use MFC classes must link statically to the MFC runtime. Distribution of dynamically linked MFC DLLs is not allowed. SDI/file-based applications These are applications with the primary purpose of opening, creating, and editing documents. Word processors, spreadsheets, and so on, are all considered file-based applications. Examples of non filebased applications include PIMs and games. File-based applications are subject to the following additional requirements. Mandatory: Support for common dialog boxes. File-based and/or Single Document Interface applications must support common dialog boxes on Xperia phones, such as dialog boxes for naming and saving files, and dialog boxes for not using proprietary interfaces for these functions. Input methods (IMs) Any application or component whose primary purpose is to input text into the device is defined as an Input Method. 14 April 2009

15 Note that an IM must be docked. Docked IMs act like a docking toolbar, taking ownership of the area immediately above the command bar. When an IM is implemented as docked, applications resize upwards and out of the way of the IM. Mandatory: 80-pixel docked IMs. It is required that Input Methods (IMs) are designed at 80-pixel maximum height and docked. Mandatory: Input Methods use input panel architecture. All Input Methods must plug into the input panel architecture. This includes using the SIP button on the command bar to activate/hide the Input Method, using the Input Method arrow button on the taskbar to select the Input Method, and having options (if any) in the Input control panel applet. In addition, the Input Method must unload when it is not the currently selected Input Method. Note: Since an Input Method is not an application, IMs are not subject to all application requirements. For example, unlike an application, an IM is allowed to have its own help button, since the system level method of Start Help will not give context help for an IM. Other requirements will be reviewed on a caseby-case basis considering the details of the IM in question. Mandatory: Keyboard based devices Applications that install and uninstall a keyboard driver are required to set/unset the proper registry key located under HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\SHELL\HasKeyboard={0=false;1=true} 15 April 2009

16 Links Information about the Sony Ericsson Xperia panel certification program Xperia Panel Certification Program Enrollment Process with NSTL VeriSign Code Signing Account Enrollment Process VeriSign Authenticated Code Signing Microsoft Windows Mobile certification information Sony Ericsson Xperia SDK 16 April 2009