App Requirements
- Print
App Requirements
- Print
Article summary
Did you find this summary helpful?
Thank you for your feedback
Below is a list of various App requirements which must be met. These requirements allow you to deliver the best App experience possible while also providing us with key information to ensure the quality your users expect is being met.
User stories are included within the requirements to help aid in the development of your App. Expand the user story sections for the user-story details, prerequisites, acceptance criteria, and additional notes.
Operational requirements
We use these metrics to monitor reliability and performance to ensure your user-expected quality of performance is met.
Metric | Definition | Methodology | Requirement |
|---|---|---|---|
Time To Minimally Useable (TTMU) | The time from when your App starts loading into the WPE runtime until your App calls the
|
| 95% of all launches must be less than 10s over a 24hr period, with a minimum of 1000 launches. |
Error Free Session Rate (EFSR) | The number of Error Free Sessions divided by the total number of sessions over a given 4hr time period. | Error-free session count | Greater than 95% over a 4hr period (min 1000 launches) |
Errors Per Content Minute (EPCM) | The total number of user-detectable errors per minute of content viewed by users. |
| Less than 0.05 over a 4hr period (min 1000 launches) |
Reporting requirements
As a Content Partner, it is your responsibility to resolve all issues related to your App reported by us or your users. Your users exist all around the world, so you must provide 24/7 support 365 days per year with no exceptions.
Metric | Definition | Requirement |
|---|---|---|
Launch completed | When your App has loaded and is able to handle user inputs. | App must call |
Error detected | The moment your App detects an error occurred which a user can discover | App must call |
User interaction | Whenever one of your users starts or stops interacting with content (playing a game, listening to music, watching a video, etc.) | The corresponding |
Incident response time | The time it takes to communicate to us indicating you have allocated resource to investigate or resolve an issue after being made aware of it (internally or externally). | You must respond to any issues within the priority level requirement listed in the Incident Priority Levels section below. |
Incident resolution time | The time it takes to fully resolve the issue after initially being made aware of it (internally or externally). | You must resolve any issues within the priority level requirement listed in the Incident Priority Levels section below. |
User Story
As a product lead, I want the App to provide various reporting metrics, so that I can monitor the App and provide relevant content in the UI.
Acceptance Criteria
GIVEN the App has onboarded onto the X1 App Platform, WHEN the App integrates as per the partner documentation, THEN the distributor can apply treatment accordingly in the X1 App Platform's UI.
For Example: GIVEN the App has onboarded onto the X1 App Platform, WHEN the App integrates it’s Consumption & Resume Point data, THEN this should reflect in the X1 App Platform UI (e.g. with content appearing in the “Play now” rail and resume points in X1 App Platform UI Show centres).
GIVEN the App has onboarded onto the X1 App Platform, WHEN the App integrates Entitlement data, THEN the App platform will be able to merchandise more accurately to users who are entitled to the App content.
GIVEN the has onboarded onto the X1 App Platform, WHEN the App integrates Quality of Service metrics (for monitoring and application reporting), THEN the distributor will be able to monitor the service and identify incidents.
Incident priority levels
Your users want to have the best experience possible, which is why you must respond and resolve issues quickly. The priority levels below outline the required response and resolution times based on the severity of the issue.
Priority | Response Time | Resolution Time | Priority Definition |
|---|---|---|---|
P0 - Critical | 30 minutes | 4 hours | App is completely unusable or essential features/functionalities do not work. |
P1 - Urgent | 1 hour | 8 hours | Non-essential features/functionalities are not fully functional, significantly hindering App usage; issues that could weaken system integrity over a period of time; problems that can be ‘worked’ around in the short term but cause significant operational disruption in the long term. |
P2 - Important | 1 Business Day | 2 Business Days | Assistance required for technical or functional features of your App. Problems that exist, that cause minor operational difficulties within the App. |
P3 - Monitor | 2 Business Days | One week | General queries. Undefined problems that may cause minor operational difficulties. Problems that require additional research and monitoring, collaborating with your team and the X1 App Program team to define and resolve the issue. |
P4 - Information | One week | When commercially feasible | Comments or suggestions on services, technical features, design or other topics. |
Functional requirements
These requirements are designed for your App to function properly on all devices and allow users to view your content.
Feature | Requirement |
|---|---|
Response time | The time it takes for your App to show a response to a user key-press must be less than 100ms. For example, the user selects 'play' and it either starts playing or a 'loading' icon appears within 100ms. |
App navigation | The current focus during navigation must be clearly identified on screen.
|
Search | When a user submits a search, the correct list of content options is presented to the user.
|
Playback start | The amount of time between a user requesting playback and the asset starting playback must be less than 3 seconds. |
Device support | Your App must support all X1 App Platform-compliant Remote Specifications.
|
Memory usage |
|
Local storage | Your App must be able to operate without local storage as a starting point. |
IP stack | All endpoints must be reachable by IPv4 & IPv6. Many X1 Devices are IPv6 only which means they cannot connect directly to any service that does not have an IPv6 address. Any services your App may use, including those used to monetize your advertising inventory, must be able to communicate with the X1 App Platform through both IPv6 & IPv4. |
HTTPS | HTTPS for all connections (including those related to data and content delivery). |
Web standards | Your App should follow W3C standards, see www.w3.org for more info |
Deep linking | Your App must support deep linking via the Lifecycle |
Screen saver | Your App must develop its own App screen saver that deploys within 15 minutes of inactivity. The screen saver must not deploy during active video playback. |
Search | The search results should match the search query. The asset selected from the search should play successfully.
|
Error messaging | When error messages are displayed, they are clearly displayed in the user's preferred language or local language. The error message must also include information on what the issue is and what the solution is.
|
Max no. of devices per account | Users must be presented with a message indicating the maximum number of devices has been reached and advised of action to take in order to use your App on their current device.
|
DIAL | If DIAL is supported, then the App must launch, play the asset, and then push the App to the device using the cast function on the user's mobile/tablet device.
|
App features | All available functionalities within the App are working correctly. |
Button mapping | Button mapping must not deviate from the X1 App Platform button map guide unless a rare exception is made with the X1 App Platform. It must remain intuitive to avoid user confusion. |
Audio/Video quality requirements
Item | Requirement |
|---|---|
Quality | • UI resolution must be a minimum of 1080p.
|
Screen resolution | Your App must support rendering at both 720p and 1080p screen resolutions. |
Dolby Digital+ and Dolby Audio | Your App must provide the best audio format when it exists and must not restrict this. If your App has Atmos Audio (or Dolby Digital+), it must be made available on the device.
|
Standard playback | There must not be any AV issues on playbable assets including advertisements.
|
Playback issues | If there is a streaming interuption due to technical or network connectivity, your App must gracefully handle the interruption and resume playback as expected. |
Extended playback | There may not be any playback issues when playing videos for an extended period of time.
|
Sign In | authentication requirements
Item | Requirement |
|---|---|
Sign-in via pairing code or DIAL (via Casting) | Customers with existing sign-in credentials should be able to sign-in successfully using a pairing code or casting from an alternative device.
|
Sign-in via keyboard | Users must be given the ability to enter their credentials (e.g. email address and password) using an on-screen keyboard.
|
App Sign-in response: Success & Fail | The app should successfully sign in quickly, or present a relevant invalid response.
|
Deep-linking requirements
The App Platform uses key intents when deep-links are selected from the App Platform experience and passed to an App to determine the right behavior for the user. Below are the intents used on the App Platform:
The Entity intent goes to an entity or Show page. When a user has yet to engage with a show, we pass the entity intent.
For more information, please see the technical documentation here
The Playback intent goes straight into the playback of the selected asset. When a user has engaged with a single asset or episode from a series, we pass the Playback intent for that asset.
For more information, please see the technical documentation here
Item | Requirement |
|---|---|
Direct playback deep linking from cold start | When your App is in the unloaded state and a user selects to watch content from a show center or a content tile, then your App needs to load first before the content starts playing.
|
Show page deep-linking from cold start | When your App is in the unloaded state, and a user selects your App content tile, then your App needs to load first before your App content show page displays (within your App).
|
Direct playback deep-linking from Inactive state | When your App is in the inactive state, and a user selects the 'watch' button from your App titles show center or your App content tile, then your App needs to start full screen playing. Your app should not reload.
|
Show page deep-linking from Inactive state | When your App is in the inactive state, and a user selects your App's content tile, then your App needs to full-screen display the show page within your App. Your app should not reload.
|
Direct playback deep-linking from Background Active state (mini-tv) | When your App is in the Background Active state and the 'watch' button is selected from your App's show center or content tile, then your App must be made visible in full screen and start playing the selected content.
|
Show page deep-linking from Background Active state (mini-tv) | When your App is in the Background Active state and the user selects your App content tile, then your App content displays in full screen.
|
Direct playback deep-linking from Foreground Active state | When your App is in Foreground Active state and the user selects your App content tile, then your App content will remain in full screen and the content will start playing.
|
Show page deep-linking from Foreground Active state | When your app is in the Foreground Active state and the user uses voice search for an App title, then your App will display the App content in-App in full screen.
|
App Launch | When a user selects your App's launch point, then your App should load and the intended screen should become visible.
|
Trickplay behavior requirements
Item | Requirement |
|---|---|
Play | Your content should play or resume as expected when the user selects to play content. This includes playing from the content tile, fast-forwarding / rewinding content, or when the content is paused.
|
Pause | Your content should pause when the user selects to pause content. This includes pausing while watching, fast forwarding, or rewinding content.
|
Fast-forward | Your content should fast-forward when the user selects to fast-forward content and present a visual indication of timeline progress. This includes increasing speed while fast forwarding (x2, x6, x12, and x30).
|
Rewind | Your content should rewind when the user selects to rewind content and present a visual indication of timeline progress. This includes increasing speed while rewinding (x2, x6, x12, and x30).
|
Scrubbing | When a user presses and holds the left or right button, a visual audio/video selector must slide across a visual timeline within the player UI of your App.
|
Playback requirements
Item | Requirement |
|---|---|
Initiating Playback from the Show Center UI - Hero zone | Your app content should play and resume as expected from the content tile, fast-forwarding / rewinding content, or when content was previously paused.
|
Initiating Playback from the Show Center UI - Available Now zone | Your App content should load and play the correct episode when the user presses 'Play' on a specific piece of content in the Show Center UI.
|
Initiating Playback a merchandised title (via show page) | When a user selects a piece of merchandised App content, then the X1 App Platform UI should display the correct editorialized App content within the UI show page.
|
Initiating Playback from an X1 App Platform show page (no consumption data) | The CTA must say 'Watch' within the hero zone if the user has not yet watched any content from your App.
|
Initiating Playback from an X1 App Platform show page (consumption data available) | The CTA must say 'Continue' within the hero zone if the user had previously started watching content from your App. The 'Continue' action must be based on the resume point of the content.
|
Resuming playback from X1 App Platform UI | Your app content should display the correct piece of content or episode in the X1 App Platform's Continue Watching rail or Show Page.
|
Initiating Playback from the X1 App Platform UI - Play Now / Continue Watching | Your app content should play the correct piece of content or episode from the X1 App Platform's Continue Watching or Play Now rail without additional user action when the user presses 'Play'.
|
UI Examples |
|
Ad break requirements
Item | Requirement |
|---|---|
Trickplay during advertisements | If a user initiates FFWD, RWD, scrub, or skip during an ad break, then your App must present a notification indicating which functions are unavailable during the ad break.
|
Visual timeline | When the user attempts to initiate trickplay, a visual timeline within the player's UI elements must be presented to indicate the progress for ads. |
Transitions | Black screens, error screens, or other visible transitions/ inconsistencies should not be presented at any point using trickplay between ads and content playback |
Dismiss button requirements
Item | Requirement | Note |
|---|---|---|
App exit behavior | When a user is on your App's homepage and the dismiss button is pressed, then your App must exit and return the user back to the same point they launched your App from within the X1 App Platform UI. Confirmation dialogues are not permitted for this action.
| Some remotes have a back button instead of dismiss, the same requirement applies to the back button on these remotes. |
Dismiss button during playback | If on-screen UI is visible, the dismiss button first applies to going back to full-screen playback.
| Some remotes have a back button instead of dismiss, the same requirement applies to the back button on these remotes. |
Ending content during playback | When a user is watching content, no on-screen UI is present, and the dismiss button is pressed, then your App must take the user to the in-App showpage for that show. Confirmation dialogues are not permitted for this action.
| Some remotes have a back button instead of dismiss, the same requirement applies to the back button on these remotes. |
Remote capability | A confirmation dialogue on App playback ending is not permitted. Your App should respond as expected when interacting with supported remotes (including touch dish and touch remotes) |
Accessibility requirements
Item | Requirement |
|---|---|
Accessibility | Your App must meet WCAG AAA compliance standards as well as the legal requirements for closed captioning, see Accessibility documentation for more info. |
Audio description | While watching video content, users must be able to turn on available audio description using the audio description menu. The audio description feature must be turned on/off respectively and activate immediately in the video playback.
|
Closed Captions / Subtitles | While watching video content, users must be able to turn on available closed captions / subtitles using the subtitle menu. The closed captions and subtitles must be turned on/off respectively and activate immediately in the video playback.
|
Localization requirements
Item | Requirement |
|---|---|
Price listing | All pricing must display in the user's local currency.
|
Language | All text including error messages, on-screen keyboard, and navigation must be displayed in the official language of the user's territory unless the user has changed their preferred language settings.
|
Localized advertising | All advertising displayed must be localized and relevant to the user.
|
Localized content | Content displayed within the App must be relevant to the user and users must not be able to view content outside of their regional licensing.
|
Audio Language | The content audio must default to the local language or the preferred language set by the user.
|
Localization content error | Users must be given an error message when trying to view content restricted by their territory.
|
Parental safety requirements
Item | Requirement |
|---|---|
App for everyone | If your App is accessible to children, then content within it should be appropriate or have the option to filter out or PIN protect adult content.
|
Apps for kids | If your App is targeted towards children, then all content must be suitable for children. |
Advertising | • If your App is aimed towards children or users of unknown age, then all advertisements displayed on your App must only contain content that is appropriate for children.
|
Data collection | If your App collects personal information from children (including APIs and SDKs), then the user must be aware of such data collection.
|
Explicit filtering | If your App has music or audio content that is tagged as 'explicit', then your App must provide a tool for a user to filter out explicit content.
|
Parental PIN | It is important that your App only allows authorized users to make purchases or watch mature content. When the device's Parental PIN setting is active, then your App should adhere to it and trigger a Parental PIN prompt when inappropriate content is accessed or a purchase is attempted. See the Parental Controls documentation for additional information regarding Content Ratings Approvals & Purchase Approvals. |
Youth protection | This is only applicable for apps in Germany & Austria: Your App must meet German Youth Protection regulations by having an approved Youth Protection Program.
|
Legal requirements
Item | Requirement |
|---|---|
Terms & Conditions | The Terms & Conditions must be available and relevant for each user's territory. Terms & Conditions can be a single T&Cs covering all applicable territories or can be territory-specific.
|
Privacy Policy | The Privacy Policy needs to describe, at a minimum, data collection and use of data. It must be available and relevant for each user's territory. The Privacy Policy can be a single Privacy Policy covering all applicable territories, or can be territory-specific.
|
Impressum | This is only applicable for users in Germany. Your App must contain the full text of Impressum indicating who is responsible for the content displayed. A user must be able to access the Impressum within 2 clicks of your App's landing page.
|
Open Source Software | If your App uses open source software, then your App must contain the Open Source software license information.
|
Player compatibility
These are the supported formats for multimedia content on all App Platform-compliant devices. The devices will not be able to play incompatible content.
Feature | Supported Formats |
|---|---|
DRM |
|
Audio codecs |
|
Video codecs |
|
Search and discovery integration
In order to have your App's content fully surfaced in aggregated experiences, Firebolt® Search and Discovery APIs must be integrated.
Feature | Description |
|---|---|
Enables your App's content to have a deeper and more prominent exposure in search and discovery experiences. | |
Enables your App to be launched or brought to the foreground with a specific entity, search, player, or other section already loaded. | |
Allows your users to speak to their remotes to navigate, search, and control their experience via voice.
|
Gaming requirements
To provide customers playing games a good experience, the following requirements
Item | Requirement |
|---|---|
Bluetooth pairing - Settings | Customers can pair a Bluetooth device.
|
Cloud Gaming App Navigation - Game controller | Customers can use a Bluetooth game controller.
|
Cloud Saves | Customers can save and resume progress within a game
|
Cloud Gaming App Responsiveness | Interactions by the customer with the Gaming App must not be delayed
|
Visual Playback Latency | The visual element of gaming content must not have lag
|
Audio Playback Latency | The audio element of gaming content must not lag behind the visual element.
|
Resuming games from EntOS UI | Customers can quickly resume playback directly from EntOS.
|
App UI requirements
Item | Requirement |
|---|---|
App Synopsis | You must have a clear description of your App up to 180 characters long.
|
Content Synopsis | You must have a clear description of your content up to 200 characters long. This appears alongside the the content hero image.
|
App artwork requirements
Please view the Art Guidelines documentation for more information on each asset type.
Asset Type | Ratio | Resolution | Format | Mode | File Size Limit |
|---|---|---|---|---|---|
App: tile small | 1:1 | 260 x 260 |
| RGB | 500k |
App: tile medium | 1:1 | 800 x 800 |
| RGB | 500k |
App: tile large | 16:9 | 1920 x 1080 |
| RGB | 500k |
App: tile extra large | 1:1 | 3840 x 3840 |
| RGB | 500k |
App: tile alternate | 107:69 | 214 x 138 |
| RGB | 500k |
App: background hero | 16:9 | 1920 x 1080 |
| RGB | 500k |
App: title art | 1800:1013 | 1800 x 1013 | Transparent | RGB | 500k |
Content: background hero | 16:9 | 1920 x 1080 |
| RGB | - |
Content: brand logo | 1:1 | 2000 x 2000 | Transparent | RGB | - |
Content: landscape show | 16:9 | 1920 x 1080 |
| RGB | 500k |
Content: landscape episode | 16:9 | 1920 x 1080 |
| RGB | 500k |
Content: portrait | 3:4 | 600 x 800 |
| RGB | 500k |
Firebolt® Lifecycle requirements
Firebolt® Lifecycle State Definitions
State | Description |
|---|---|
Unloaded or not running | Application is not running or loaded in memory. |
Inactive | Application is loaded but it not visible, does not receive any input events and cannot play any A/V content. It is considered to be in a low resource state and so should free any unrequired memory (e.g. A/V buffers) and minimize network and CPU usage (e.g. by disabling or reducing frequency of any timers, disabling any animations and closing any Web Sockets). If the app has been used within 60 seconds, where the user was must remain. If more than 60 seconds has passed, the app should transition to the in app homepage. This supports fast transitions into the Active state. |
Foreground Active | Application is visible full screen, receives input events and can play A/V content. |
Background Active | Application is visible and can play A/V content, but it will not receive input events except for Play/Pause commands. These commands apply when the mini-tv is in or out of focus. This happens in the switcher rail |
Quick start feature requirements
Item | Requirement |
|---|---|
Foreground Active to Background Active (when pressing 'home' on remote) | Your app must transition from the Foreground Active state to the Background Active state appropriately without issue when the user presses 'home' on the remote.
|
Background Active to Foreground Active | Your app must transition from the Background Active state to the Foreground Active state appropriately without issue.
|
Background Active to Inactive | Your app must transition from the Background Active state to the Inactive state appropriately without issue.
|
Inactive to Foreground Active (Quick start launch) | Your app must transition from the Inactive state to the Foreground Active state appropriately without issue.
|
Unloaded to Foreground Active (cold start launch) | Your app must transition from the Inactive state to the Foreground Active state appropriately without issue.
|
Foreground Active to Inactive (when pressing 'dismiss' on remote) | Your app must transition from the Foreground Active state to the Inactive state appropriately without issue when the user presses 'dismiss' on the remote.
|
Full System Reboot | Pre-requisite |
App Crash from Active Foreground / Background | Pre-requisites |
UK only: | If your App has been running with no activity from the user after 3 minutes while in the Foreground Active state, then Glance mode should not trigger. |
UK only: | If your App has been running with no activity from the user after 3 minutes while in the Unloaded, Inactive or Background Active state, then Glance mode should trigger. |
Germany/Italy (DE/IT) only: | If your app is on a XiOne device (DE/IT), then the lifecycle behavior must match the requirements outlined in |
Required API Implementations
API | Description |
|---|---|
| |
Note: There are use cases, such as during testing, where your app returns to the foreground before your app session is terminated, landing the user on the last seen UI (i.e., exit dialog). For better UX, your app should return to either your app’s homepage or the last screen prior to the exit dialog. | |
| |
| |
| |
Note: The Firebolt® metrics calls startContent() and stopContent() are not expected to capture every pause/unpause. The these API's are designed to estimate how much time a user is spending consuming content in the App (vs how much time is spend navigating/browsing an App). While an asset is paused, the media is still considered as being consumed. For capturing pause/unpause, use mediaPlay() and mediaPause() which are to specifically count the actual playback interactions a user takes within an App. | |
Manage App while in Inactive state | Your app is required to close video/audio playback session when going into the Inactive state. Playback continuing while your app is out of focus is both disruptive to the customer experience and other apps subsequently launched.
Inactive State Device Support The Inactive state is currently supported on the following device platforms:
|
Integration requirements
The following requirements are only required if your App uses the specific integrations.
Kids section
Item | Requirement |
|---|---|
Option 1a: Launching straight into a kids profile | Your App should open kid section deep links within kid profiles.
|
Option 1b: Changing profiles | Your App should present a form of parental control before accessing an adult profile.
|
Option 2a: Launching via profile screen | Your App should open kid section deep links within kid profiles.
|
Option 2b: Launching via profile screen while App is in Background Active mode | Your App should take the user to the app profile screen or return to the kids profile when selecting a deep link from a kids section while the app is in Background Active mode.
|
Partner page
The partner page relies on the use of RSS feeds. For more information on integrating partner page RSS feeds visit the Partner Page RSS documentation.
Item | Requirement |
|---|---|
Partner Page – Featured Rail | You must dictate which content should be displayed in your App's 'featured rail' within the X1 App Platform's Partner page UI.
|
Partner Page – Most Popular Rail | You must dictate which content should be displayed in your App's 'most popular rail' within the X1 App Platform's Partner page UI.
|
Advertising
Item | Requirement |
|---|---|
Fast forwarding / scrubbing within an advertising break (ad break) | Users should be able to fast forward and scrub through ad breaks and resume playback as expected.
|
Rewinding / scrubbing within an ad break | Users should be able to rewind and scrub through ad breaks and resume playback as expected.
|
Fast forwarding / scrubbing initiated in content and continues across mid-rolls | Users should be able to fast forward and scrub through ad breaks and resume playback as expected across mid-rolls.
|
Rewinding initiated in content and continues across mid-rolls | Users should be able to rewind and scrub through ad breaks and resume playback as expected across mid-rolls.
|
Ad Trickplay UI / Visual Cues | Users should be presented with black screens, error screens, or any visible transitions when resuming from fast forward, rewind, or scrub state.
|
Advert Quality | Advertisements should be in HD (high definition). |
Exiting playback session after ad-break | User should be returned to playback at the same point they left without ad-breaks when resuming.
|
Exiting playback session during ad-break | Playback must resume from the start of the ad-break when users exit playback session and then resumes playback.
|
Separate Premium Ad Skip Experience supersedes Ad Tier entitlement | Users with entitlements to skip advertisements should have the ability to Trickplay ads.
|
Ad Trickplay Experience must match a user's Ad Tier entitlement | The ability to Trickplay ads should reflect the user's Ad Tier entitlement.
|
No Trickplay restrictions during content playback | Trickplay should not be restricted over primary content playback.
|
Ad Markers for Non-FFWD | Ad markers should display in the playback bar and appear in the exact point which the Ad-break begins.
|
"Relax View" for subsequent views of Ad-breaks | Users should be able to use trickplay on ads which have been previously viewed fully at 1x speed.
|
UI Notifications for Trickplay supression | There should be a visible notification to indicate when Trickplay is not available and the user has attempted to use Trickplay.
|
High Speed scrub (jump) past multiple mid-rolls | Users must be presented with only the nearest mid-roll Ad-break position before resuming content from the jump/scrub point.
|
Unsubscribed Registered State | User should be able to Trickplay content and Ads according to your App's advertising product requirements.
|
Commerce Integration
Item | Requirement |
|---|---|
Referral to commerce integration CTA | Non-subscribed users must be given a "Get via X1 App Platform" CTA to subscribe to the App from the sign-in / sign-up screen.
|
Transition to commerce integration App for purchase | Users must be directed to the commerce integration App when they select the "Get via X1 App Platform" CTA.
|
Activation feedback | Your App must notify the X1 App Platform when a user has successfully purchased and activated a subscription to your App.
|
Silent Sign-In
Item | Requirement |
|---|---|
On Product sign in - apps without existing account credentials | When a user signs into an app on one device, it should allow the user to auto sign into all other devices in their household.
|
On Product sign in - apps with existing account credentials | When a user signs into an app on one device, it should not overwrite existing credentials on other devices in their household.
|
Silent sign in following signing out from previous credentials on additional devices | Users should be able to use silent sign in after signing out on other devices.
|
Sign in to 3rd party apps through commerce integration | Users using commerce integration should have their credentials available for auto sign in after creating an account. You must present a clear message to indicate all devices will be auto signed in using the provided account information.
|
Sharing device friendly names with partner sign out journey (optional behavior) | Users should be presented with device friendly names when signing out of a device through your App's website.
|
Sign out of 3rd party apps on devices within the product | Users which sign out of a 3rd party app on one device should only be signed out of the app on that device. Other devices should not be affected.
|
Sign out of 3rd party apps across all devices - With subscription token (commerce integration) | Users which sign out of a 3rd party app on one device should only be signed out of the app on that device. Other devices should not be affected and the X1 App Platform will retain the subscription token.
|
Sign out of 3rd party apps on all devices off product (optional behavior) | Users which use your App's website to "sign out of all devices" should be signed out of all devices that they are logged into and the authentication token should be cancelled.
|
Sign out of 3rd party apps on individual devices (optional behavior). | Users which use your App's website to "sign out of
|
Entitlement
Item | Requirement |
|---|---|
Signed-In / Authentication Status | Your App should inform the X1 App Platform when a user has successfully signed-in and signed-out.
|
Entitlement Status | Your App should inform the X1 App Platform when a user has modified their subscription for your App.
|
Thumbnail Trickplay recommendations
Item | Requirement |
|---|---|
Enabling Thumbnail Trickplay | • Users should be able to trigger thumbnail Trickplay from the D-Pad on the remote without navigating to any in-App button on the progress bar. |
Thumbnail Trickplay Speeds | Users should be able to fast-forward or rewind content at three incremental speeds. |
Thumbnail Trickplay UI | • The progress bar should remain at the point where Trickplay was initiated; and should remain visible during Trickplay. |
Was this article helpful?