Extending Stadia's app architecture to more devices
With Stadia’s expansion to new living room devices, such as LG Smart TVs and Samsung Smart TVs, we wanted to provide a brief update on our living room app architecture. Let’s jump in!
Similar to our architecture on Android TV, we’ve re-used and adapted many of the components gamers have been interacting with for years. This includes:
Stadia TV web app - a web application built using technologies like Dart, HTML, and CSS designed for living room devices.
Cobalt - a “high-performance, small-footprint platform that implements a subset of HTML5/CSS/JS to run applications, including the YouTube TV app”.
Starboard - “Cobalt's porting layer and OS abstraction”.
Stadia streaming client - the native streaming stack that integrates with high-performance video, audio, and data transport APIs to deliver high-quality gameplay.
Here is a view of what the architecture looks like when these pieces are put together:
Challenges and opportunities
As a result of this unique tech stack, the Stadia team encountered some unique challenges and opportunities along the way. Here are a few examples:
Each TV operating system and environment we work on has unique characteristics and capabilities. Living room devices are a form of embedded device, where the operation and usage is quite different from mobile phones or desktop web browsers. As a result, the Stadia team must partner closely with each platform operator to understand the capabilities of the platform.
The Stadia streaming client uses unique video and audio playback capabilities. Not only are these capabilities exposed differently on each operating system, but the capabilities may also have platform-specific limitations. For instance, fine-grained control over video decoding varies by platform, as do audio mixing capabilities.
Adapting to each unique platform requires strong partnerships with internal and external collaborators.
Depending on the platform, different teams–or even different companies–may be responsible for implementing parts of the stack.
Stadia streaming client - Google
Stadia TV web app - Google
TV operating systems - various third parties
Starboard implementations - various third parties
That means coordinating across different multi-quarter and multi-year timelines to ensure that each component is ready to go and supports the requirements for the parts in the stack above it.
New Stadia TV web app releases must be tested on all of our supported platforms to ensure a high quality experience and prevent regressions.
Additionally, new releases of lower-level components (e.g., Stadia streaming client, Cobalt) must be validated with a public version of the Stadia TV web app to prevent regressions. Depending on the platform, this can take many forms. For example, this would be a new Android app (APK) release on Android TV and other packaging formats on third-party platforms.
Reusability and what’s next
Reusability of parts of our tech stack has been key in our ability to expand to new living room devices. We continue to use Dart to share critical parts of our gameplay state logic between all living room platforms and Stadia for Android. Our shared investment in Cobalt and solid partnerships with other Google teams, such as YouTube, have resulted in an ability to scale to new platforms.
As mentioned in our prior post, scale is a large driving force in many of these architectural decisions. Our technical approach for Android TV ultimately paved the way for expanding to two further platforms, and it is with that same approach to scale and portability that we continue our efforts in expanding the number of places that Stadia can run in the future.
This work is conducted in collaboration with many people across Stadia and Google teams, and with many individuals at other companies.
-- Matt Joseph, Engineering Manager