Android TV Launch Checklist for Live Sports Streaming Apps

Introduction

Submitting a live sports streaming app to Android TV is a different process from submitting a standard Android mobile app. The form factor has its own requirements, its own review criteria, and its own set of failure modes. Apps that pass mobile review can still be rejected for Android TV if the TV-specific requirements are not met.

This checklist is drawn from VIP's experience submitting and managing live sports streaming apps across multiple Android TV and Google TV deployments. It is organized by phase — from initial setup through post-launch monitoring — and is intended as a practical working reference, not a marketing document.

Phase 1: Google Play Console Setup

• ☐Developer account verified. Ensure your Google Play developer account is in good standing and has completed identity verification. Account issues discovered during submission cause significant delays.
• ☐App created with correct package name. The package name is permanent. For a new Android TV app, decide whether you are submitting a single APK/AAB that targets both mobile and TV, or a separate TV-only package. Both approaches are valid; the choice affects how you manage updates and store listings going forward.
• ☐Android TV declared in the manifest. The app manifest must include the android.software.leanback feature declaration and the android.intent.category.LEANBACK_LAUNCHER intent filter. Without these, Google Play will not recognize the app as an Android TV app.
• ☐Touchscreen declared as not required. The manifest must include android.hardware.touchscreen with required="false". TV devices do not have touchscreens; failing to declare this will cause the app to be filtered out of TV device results.
• ☐Target SDK version current. Google Play enforces minimum target SDK requirements. Confirm the current minimum before submission.

Phase 2: Store Listing Requirements

• ☐TV banner (1280 × 720 px). Android TV requires a dedicated TV banner image at exactly 1280 × 720 pixels. This is separate from the app icon. The banner appears on the Android TV home screen launcher. It must be a PNG with no transparency. Missing or incorrectly sized banners are a common rejection reason.
• ☐TV screenshots provided. The Play Console requires screenshots taken on a TV form factor. These must show the actual TV UI — not mobile screenshots. Reviewers check that the UI is appropriate for a 10-foot viewing experience.
• ☐App description accurate and complete. The store description should accurately describe what the app does, what content is available, and any subscription or authentication requirements. Vague descriptions increase review friction.
• ☐Content rating completed. The content rating questionnaire must be completed for the TV form factor. Sports streaming apps typically receive a general audience rating, but the questionnaire must be completed regardless.
• ☐Privacy policy URL provided. A valid, accessible privacy policy URL is required. The policy must be reachable without authentication.

Phase 3: Production vs. Testing Tracks

Google Play offers internal testing, closed testing (alpha), open testing (beta), and production tracks. For a live sports streaming app, the track strategy matters because live content is time-sensitive and testing windows may be limited.

• ☐Internal testing track used for initial submission. Submit to internal testing first to catch any immediate rejection issues before committing to a broader track. Internal review is faster.
• ☐Closed testing used for device and content validation. Use a closed testing track to distribute to a defined set of test devices before production. This is where live-stream testing should occur.
• ☐Production review timeline accounted for. Production review typically takes several days but can take longer. Do not plan a launch for the same day as production submission. Build in buffer time, particularly around major events.
• ☐Staged rollout considered. For a new app, a staged rollout to a percentage of users can limit the blast radius of issues discovered post-launch. For a live sports app with a hard event date, a full rollout is usually preferable — staged rollouts mean some users cannot access the app on launch day.

Phase 4: Remote Control Navigation and 10-Foot UI

This is the area where sports streaming apps most commonly fail Android TV review. The reviewer will navigate the app using only a D-pad remote control. If any screen cannot be fully navigated with a remote, the app will be rejected.

• ☐Every interactive element is reachable by D-pad. Test every screen, every modal, every dialog, and every overlay with a physical remote or D-pad emulator. Pay particular attention to authentication screens, subscription flows, and error states.
• ☐Focus states are visible. Every focusable element must have a clearly visible focus indicator. The default Android focus highlight is often insufficient for a 10-foot viewing distance. Custom focus states should be tested on an actual television, not just an emulator.
• ☐No touch-only interactions. Any interaction that requires a swipe, pinch, or tap gesture must have a D-pad equivalent. This includes carousels, sliders, and any custom gesture-based navigation.
• ☐Text is readable at 10 feet. Minimum body text size for TV is generally 18sp or larger. Test on an actual television at normal viewing distance. Text that is readable on a monitor may be illegible on a television across a room.
• ☐Safe zone margins respected. Content should not extend to the edges of the screen. Maintain safe zone margins (typically 5–10% on each side) to account for overscan on older televisions.
• ☐Back button behavior correct. The back button must navigate logically through the app. Pressing back from the top-level screen should prompt to exit or return to the launcher, not crash or loop.

Phase 5: Video Playback and Live Stream Testing

• ☐Playback tested on actual Android TV hardware. Emulators do not accurately reproduce the video decoding behavior of real devices. Test on at least one actual Android TV or Google TV device before submission.
• ☐Live stream tested end-to-end. If the app delivers live content, test a live stream — not just VOD — before submission. Live stream delivery has different latency, buffering, and error characteristics than on-demand content.
• ☐Playback controls navigable by remote. Play, pause, seek, and volume controls must all be operable with a D-pad remote. Test that the playback overlay appears and dismisses correctly.
• ☐Error states handled gracefully. Test what happens when a stream fails, when the network drops, and when content is unavailable. Error messages must be readable and actionable from a television.
• ☐DRM tested if applicable. If the app uses DRM-protected content, test DRM license acquisition and playback on actual TV hardware. DRM behavior can differ between mobile and TV implementations of the same player library.

Phase 6: Authentication

• ☐Authentication flow navigable by remote. If the app requires login, the entire authentication flow — including username/password entry, error states, and account creation if offered — must be completable with a D-pad remote.
• ☐Device activation / QR code flow implemented if appropriate. For TV apps that require authentication, a device activation flow (where the user visits a URL on a second screen to authenticate) significantly reduces friction compared to entering credentials with a remote. If this flow is implemented, test it end-to-end.
• ☐Session persistence tested. Test that authentication sessions persist across app restarts and device reboots. Users should not be required to log in every time they open the app.
• ☐Unauthenticated state handled. Test what the app shows to a user who is not logged in. The unauthenticated state should be navigable and should clearly communicate what is required to access content.

Phase 7: Advertising and Advertising ID Declarations

• ☐Advertising ID usage declared. If the app uses the Android Advertising ID (AAID) for any purpose — including advertising, analytics, or attribution — this must be declared in the Play Console data safety section.
• ☐Data safety section completed accurately. The data safety questionnaire must accurately reflect what data the app collects, how it is used, and whether it is shared with third parties. Inaccurate declarations are a policy violation.
• ☐Ad SDK versions current. Outdated ad SDKs can cause policy violations. Confirm that all advertising SDKs are at versions that comply with current Google Play policies.
• ☐Ad behavior tested on TV. If the app serves ads, test ad playback on actual TV hardware. Ad rendering, skip controls, and ad break transitions must all work correctly with a remote control.

Phase 8: Privacy and Data Disclosures

• ☐Privacy policy accessible from within the app. The app must provide a link to the privacy policy that is accessible without authentication. This is typically in the settings or about section.
• ☐Privacy policy covers TV-specific data collection. If the app collects device identifiers, viewing behavior, or other data specific to the TV context, the privacy policy must address this.
• ☐COPPA compliance confirmed if applicable. If the app is directed at children or is likely to be used by children, COPPA requirements apply. Sports apps are generally not directed at children, but confirm this with legal counsel if there is any ambiguity.

Phase 9: Production Submission

• ☐AAB (Android App Bundle) used. Google Play requires AAB format for new apps. APK submission is no longer accepted for new app submissions.
• ☐Release notes written. Write clear release notes for the production submission. For a new app, describe what the app does. For updates, describe what changed.
• ☐Review timeline communicated to stakeholders. Production review typically takes several business days. Communicate this timeline to anyone who has a dependency on the launch date.
• ☐Rollout plan confirmed. Decide whether to do a full rollout or a staged rollout, and confirm this decision with stakeholders before submission.

Phase 10: Post-Launch Monitoring

• ☐Play Console vitals monitored. Android Vitals in the Play Console tracks crash rates, ANR rates, and other stability metrics. Monitor these in the days following launch, particularly after the first major live event.
• ☐User reviews monitored. Early user reviews often surface issues that were not caught in testing. Assign someone to monitor and respond to reviews in the first weeks after launch.
• ☐Crash reporting active. Ensure crash reporting is active and that alerts are configured for significant crash rate increases. A crash spike during a live event requires immediate response.
• ☐Update process documented. Document the process for submitting updates, including who has Play Console access, how long review typically takes, and what the escalation path is if an urgent fix is needed.

Conclusion

Android TV submission is manageable when the requirements are understood in advance. The most common failure modes — missing TV banners, incomplete D-pad navigation, undeclared data collection, and inadequate live-stream testing — are all preventable with a systematic pre-submission review.

The investment in getting the submission right the first time pays off in reduced review cycles and a cleaner launch. For a live sports streaming app, where the launch window is often tied to a specific event date, avoiding a rejection cycle is not just a convenience — it is an operational necessity.