December 3, 2013
In order for an application to be considered for pre-load the developer must agree to resolve bugs/fixes in a timely manner as defined in Section 1 and the app must fulfill the technical requirements defined in Section 2.
Fixes/defects found by Mozilla, Operators or handset manufacturers will be reported to the developer via Bugzilla. The developer agrees to fix these bugs in a timely manner as defined here:
Priority | Description | Time to Resolve |
---|---|---|
P1 = Critical | Critical bugs are the bugs we need to fix immediately or the app will not be pre-loaded by one or more Operators. These are bugs that prevent basic use cases of the App from working if it were released in that state. | Fix to be submitted to Marketplace within 3 business days of assignment to 3rd party Developer via Bugzilla. |
P2 = Major | Major bugs are still bugs, but the basic use cases of the app are in tact. Major bugs may not result in an app being pulled from pre-load status but need to be fixed asap. Typically there is an end-user workaround or a quick fix that can be applied post-release. | Fix to be submitted to Marketplace within 5 business days of assignment to 3rd party Developer via Bugzilla. |
P3 = Minor | Cosmetic and minor issues such as button size, misspelled word, etc. | Fix to be submitted to Marketplace within 10 business days of assignment to 3rd party Developer via Bugzilla. |
P4 = Enhancement | Reserved for enhancements or "nice to haves". | Developer to provide date for new version of app if the item is accepted on their roadmap. |
For 3rd Party Apps, Bugs Severity Levels are designated using the Priority Field in Bugzilla.
3rd Party apps will not block a device from shipping; however the final decision is with the OEM/Carrier. Instead of blocking Terminal Acceptance (TA), the expectation is that the app would be pulled from pre-load.
Area | Technical Requirement | Consumer Experience Benefit |
---|---|---|
Startup Time | If an operation will take more than a few seconds, a progress indicator should be used. | Progress indicators are an interactive system's way of keeping its side of the expected conversational protocol: "I'm working on the problem. Here's how much progress I've made and an indication of how much more time it will take." |
Fully Offline Apps | Apps that do not require internet connectivity should be fully packaged and 100% available offline (i.e. no internet connection required to use). This normally applies to apps such as Games, Utilities. | Ensures that apps that do not need internet connectivity run as Consumers expect and are similar to comparative platforms. |
Offline Operation | All static components (logos, menu text etc) should be stored locally to enable offline operation Apps that have NO live data should operate 100% offline (e.g. Games, Utilities) | Consumer is able to see the application framework, without requiring a network connection/while waiting for live data components to pre-load. Consumer is also able to see the application framework at unboxing without a network connection. In addition to caching, an app will be fully viewable when no network connection exists. |
Caching |
App should support appcache caching as minimum so previous pages
viewed are cached. Ideally indexedDB (local storage) should be used to store
information.
The previous session's app data should be cached and displayed when
there is no internet access and if:
|
Consumer is able to see the last set of data when no internet connectivity is available/slow to load refreshed data. |
Language | App must support local language of the country where the app is pre-loaded across all static/non-live app assets (e.g. menu items, Terms and Conditions, instructions etc). App must detect language based on device setting. | Consumers can utilize apps in local languages in target countries. |
Sound | Apps should support sound, where applicable (e.g. Games). | |
UI | App needs to support a full-touch UI environment and provide sufficient quality (e.g. menus, buttons, elements are correct size). |