Google TV platform notes

Google TV runs on Android, which means a lot of Android development knowledge transfers directly. But the TV form factor introduces constraints and patterns that do not exist on phones or tablets. These notes cover the practical details that matter when building and maintaining a Google TV streaming app.

Development environment

Google TV apps are Android apps built with the Leanback library (or Compose for TV, which is newer and still maturing). Your development setup includes:

• Android Studio with the TV emulator image. The emulator is useful for initial development but does not replicate real hardware performance or DRM behavior.
• A real Google TV device for testing. The Chromecast with Google TV is the most common target and the most resource-constrained.
• ADB (Android Debug Bridge) for installing builds, viewing logs, and profiling. This is your primary debugging interface.

Leanback versus Compose for TV

Leanback is the established UI framework for Android TV. It provides pre-built fragments for browsing content (BrowseSupportFragment), showing content details (DetailsSupportFragment), searching (SearchSupportFragment), and controlling playback (PlaybackSupportFragment). These fragments handle D-pad navigation, focus management, and the 10-foot UI layout out of the box.

Leanback works. It is battle-tested. But it is also opinionated about UI structure, and customizing it beyond the provided patterns requires working against the framework rather than with it.

Compose for TV is Google’s newer approach, built on Jetpack Compose with TV-specific components and focus handling. It offers more flexibility in UI design but is still relatively new. For a greenfield project with a long timeline, it is worth evaluating. For a project that needs to ship soon, Leanback is the safer choice.

Media3 and ExoPlayer

ExoPlayer has been absorbed into the Jetpack Media3 library. For new projects, use Media3 directly. For existing projects using standalone ExoPlayer, migration is straightforward but requires updating import paths and some API calls.

Key Media3 capabilities for TV apps:

• HLS and DASH with adaptive bitrate switching
• Widevine DRM with L1 and L3 support (depending on device)
• Subtitle rendering (WebVTT, TTML, SRT)
• Audio track selection and audio focus management
• Configurable buffer parameters

TV-specific considerations:

• Configure the buffer size to be appropriate for the device’s available memory. The default buffer settings work on phones but can consume too much memory on a low-end Chromecast.
• Handle audio focus correctly. Android’s audio focus system determines which app gets to play audio. Your app needs to request audio focus before playback and release it when paused or stopped.
• Test with HDMI-CEC. When the user turns off the TV via the remote, the Google TV device may receive a CEC command that suspends your app. Your player should handle this gracefully.

Performance on real hardware

The Chromecast with Google TV (4K, 2020 model) is the baseline device most teams target. Its constraints shape your app architecture:

• 2 GB RAM total, with significant OS overhead. Your app realistically has 300-500 MB of heap.
• Amlogic S905X3 SoC (quad-core ARM, 2 GHz). Adequate for standard UI and video decoding, but complex custom views or heavy computation will cause frame drops.
• 8 GB storage, much of it used by the OS and cached apps. Do not rely on large local storage.

Profiling tools:

• Android Studio Profiler for CPU, memory, and network monitoring over ADB
• dumpsys meminfo for detailed memory breakdown by component
• Systrace/Perfetto for frame timing analysis
• adb shell am memory-info for system-level memory pressure

Common performance issues:

• RecyclerView with complex item layouts causing frame drops during scrolling. Use simple layouts and avoid nested layouts.
• Bitmap memory not being recycled after images scroll off screen. Use Glide or Coil with appropriate memory cache limits.
• Background services competing for CPU. Defer background work when playback is active.
• Cold start time regression when new features add to the initialization path. Measure startup time in CI.

Watch Next and content integration

Google TV’s home screen shows personalized content recommendations. Integrating with Watch Next means your content appears alongside other apps’ content on the home screen.

To participate, your app needs to:

• Write “Continue Watching” entries to the Watch Next channel when a user pauses or stops mid-content
• Handle deep link launches from Watch Next cards (the user taps a recommendation and your app opens to that content)
• Provide content metadata in the format Google specifies (title, poster art, progress percentage, etc.)

Watch Next integration is not mandatory, but it significantly improves content discoverability. It also requires careful state management: you need to track watch progress, update the Watch Next row when the user finishes content, and clean up entries for content that is no longer available.

Certification and release

Google Play review for TV apps checks:

• D-pad navigation accessibility (every interactive element must be reachable without touch)
• TalkBack support for primary user flows
• Leanback launcher banner format and size
• Content rating declaration
• Target SDK level compliance

Review timeline: typically 1-3 days for updates, potentially longer for new apps. Use staged rollouts (1% -> 5% -> 25% -> 100%) to catch production issues before they affect all users.