The scope
Even today with Android TV on its way to become a primary TV platform, one can see that the telecom operators introduce it very carefully (small volume and OTT offering, weak hardware), but not Bouygues Telecom. From the day one, the bar was set as high as possible: to make all the imaginable TV signal formats (FTA DVB-T,FTA DVB-C, Verimatrix protected IPTV, Verimatrix protected OTT, Local recorder PVR, Canal+ IPTV, Bytel VOD , TF1 Catchup) work perfectly in conjunction with all attractive Android applications (Netflix, YouTube, Canal+, etc.); and all that needed to be integrated into an absolutely seamless user experience with the highest quality requirements.
The launch
For the target hardware the following was selected:
- OEM Arcadyan
- Marvell Armada 1500 Pro BG2Q
- Quad-core 1.2 GHz
- Vivante GC4000
- RAM 2GB
- Storage 16GB
RT-RK embarked on the project as a key partner in several critical topics:
- Drive software architecture in a manner that guarantees a full Android compatibility
- Design and develop all TV related software components
- Provide remote configuration of the devices through a TR069 client
- Perform software integration of all the software components (Bytel UI, TV binaries, 3rd party application)
The diagram below shows complexity of the target system.
Figure 1. The complexity of the target system
Besides the software architecture definition and software development RT-RK was driving some of the critical certification procedures for the device. The Android based devices face significantly more comprehensive sets of certifications compared to non-Android STB (Set-Top box) devices:
- CAS related certification – a classic procedure in RTOS/Linux based STB devices, but usually with additional challenges in an Android based OS
- Google CTS – a Google-demanded compatibility test suite that validates interoperability of the device with the framework-based expectation of the Android application
- Google GTS – Google services-oriented test suite ensures smooth run of Google provided services (Play Store, YouTube, Movies, Music, etc.)
The key tasks in these processes involved:
- Execution of pre-certification tests
- Analysis of all certification issues
- Fixing the certification issues
- Driving 3rd party partners to fix issues on their side
- Driving delivery and communication with certification laboratories
The project was successful, resulting in the first device offered by Bouygues telecom early 2015 as one of the first Android based STBs in the world.
The upgrade
After the launch, the device quickly proved to be a successful and attractive product for the end users, which reaffirmed our partner position, strongly aligned the Bouygues STB evolution strategy with Android television – also reinforced by the Google’s stronger commitment to push Android more strongly into the TV market with dedicated partnership program dubbed Android TV.
This situation meant that the product continuation was granted, but it brought new technical challenges to the table:
- Android OS upgrade (Android L) was a request from Google – the aim was to bring new features and better user experience developed by Google to the user
- Bouygues Telecom needed the new features, and the product roadmap was growing (remote configuration, seamless timeshift, DASH Widevine support, new monitoring parameters, etc.)
- The field quality of the product could be improved
Each of these demands had these, often conflicting properties:
Criticality | Controllability | Impact on others | |
Android upgrade | Time frames for upgrade by Google allow strategic leniency | Software changes come in a huge bulk from many provides making them hard to efficiently track on per component of commit basis | Highly impacts other components because of the architectural or API changes, different configuration, or security conflicts |
New features | Directly linked to marketing and revenue bringing strategies | Changes affect significantly but only specific and targeted components | Usually bring modification on several components |
Field issue correction | Directly impact the end users on the filed | Usually involve single software change per issue, easily reversible and trackable | Self-contained and covering single part of software component |
Figure 2. Software branching strategies
Figure 3. Miami roadmap in the first 3 years
The new device
With a significant rise of the 4K TV technology and a clear signal from content providers about readiness to deliver content in 4K, it became obvious that the current device would lack the competitive edge in the upcoming years. This fact interleaved with the Android L emerging and the clear guidelines from Google on deployment of TV oriented apps, which was highly increasing the number of apps in the Play store. The new device needed to address these new demands. A new project was kicked off to deploy the current software solution on a new device: Miami 4K. To minimize overhead the same OEM (Arcadyan) and SoC vendor (Synaptic) were selected but with a new family of chipset bringing better graphical performance and 4k support (Armada 1500 Ultra BG4CT).
While not immune to all the technical challenges existing in the previously deployed device, the new device introduced another level in the definition of the efficient product roadmap:
- Achieve the same level of quality on both devices
- Achieve timely alignment between two devices’ features
- Employ an efficient team and make the software reusable
In the early stages of the new device’s development a parallel maintenance structure was undergoing but it was soon clear that this was quite inefficient and created a significant overhead in the team resources.
This situation pushed towards a single software delivery that would achieve and anticipate the same operability across different hardware and Android versions. This was in part possible thanks to Google’s strong requirements for compatibility across the whole Android ecosystem.
Figure 4. Optimization software strategy
Figure 5. Product roadmap through several years
The latest phase of our cooperation with Bouygues Telecom presented the biggest challenge we had faced on a project with the operator. The idea in 2009 was to introduce a new device in a much more complex context; the OEM and SoC were to be changed, and a better feature set was to target a premium user. Despite the broad scope our team enforced the same strategies applied in the previous years:
- Clear separation of maintenance, features, and Android upgrades
- Unification and reusability of software on all layers
- Release and test latest and greatest across all platforms
Our strategies are therefore market proven and backed up by the results of today’s successful (and ongoing) Bouygues Telecom project that has produced over 40 official software upgrades across 6 versions of Android (4 -> 9), and 3 different devices with numerous additions of features.
Conclusion
We will look back and summarize some critical lessons learned throughout the execution of this project which can and should be applied on any complex Android based project.
Soon into the planning and initial development it was concluded that addressing all three types of issues in a single software release would have jeopardized the quality of the software. As a result, the execution and the release strategy were put in place to address these three types of developments in three separate processes, keeping them carefully synchronized and monitored to achieve the end goal.
Google’s effort to enforce a strong TV and entertainment-oriented architecture resulting in constant (yearly) evolution of new features, security enhancement, and exciting partners while enabling a seamless integration for all Android TV devices, produces heavy technical challenges:
- Android walks a long-term TV oriented feature roadmap – because of this more TV related features have migrated from the proprietary context to standardized Android frameworks. Obvious examples are TV playback API, TV database, EPG database, handling of CEC, etc.
- More attractive partners introduce Android TV as supported platforms. Some prominent examples are Spotify, HBO, Amazon, Google Assistant. The gaming offer from the Play Store has also become interesting to the end users – all this combined introduces a demand for better hardware both in context of performance (more app needing more RAM and CPU) and features (4k, Dolby Atmos, HDR, etc.) – not fully controlled by the telco operator.
To be able to provide consistent and manageable ecosystem that brings the beforementioned benefits, Google is requesting from the operators/OEM to provide at least three version upgrades to the end user during the lifecycle of the products.
Finally, the telecom operator also maintains their own feature roadmap with a goal to improve customer offering, features, and quality.
All these elements force the telecom operators to significantly increase the amount and timing of major software update and new devices deployments. The diagram below shows all the pressure steering a sole product roadmap in the Android TV ecosystem.
Figure 6. Sole product roadmap pressures
Figure 7. Feature alignment