Pragmatists suffer complexity. Geniuses remove it.

Android lifecycle management, Bouygues Telecom

Back in 2013 a digital TV (DTV) set was still quite a closed, proprietary and resource constrained device in both hardware and software. Creating a simple app for TV required a very peculiar profile of engineer, one who understood tweaks and tricks of the target platform (RTOS APIs, programming languages, firmware flashing, etc.), but was also skilled in UI/UX building. In the aftermath of digitalization, the industry was challenged to bring new improvements to the end users. As a veteran in DTV software development and a pioneer in mobile phone development (at the time the development on the new mobile OS Android), RT-RK appeared a good match for overcoming the issues in DTV software development (the same way it had previously done in the mobile phone software development). After a few prime demos, innovation awards, workshops with Google and successful projects, Bouygues Telecom decided to strategically introduce Android devices to the end users as their primary TV offer.

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

As a result of this strategy and a clear priority set by Bouygues Telecom to raise the quality of the delivery software, the deployed roadmap ended up being as below:

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

When the unified software delivery across the whole software architecture was accomplished, the maintenance effort and development strategy was redefined to represent a single device project. Testing remained the only doubled effort.

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

Additional complexity arises from the fact that the new devices are usually introduced either to accommodate new features or to provide a second source and de-risk the supply chain. The schematics below presents a usual life span of a STB device and expectations of feature alignment against the next generation products.

Figure 7. Feature alignment

Not only does this level of complexity bring challenges in management of the product, but also in keeping of its software architecture well defined and regularly updated so that the long-term benefits of being a part of the Android ecosystem do not go to waste. This is where the value of a strong partner like RT-RK lies; being able to prevent and solve these issues by employing its skilled engineering force. RT-RK has also regular synchronization meetings with the Google teams to discuss the evolution of the software architecture, lessons learned from vast variety of projects, and to evaluate tight-tracking of the latest efforts of all major partners in the ecosystem (SoC vendors, content providers, technology providers, etc.).

You may also like…