Android CTS/CDD changes

When I joined Google, I was intrigued to learn how such a large project, with so many stakeholders producing so many different devices, manage to “stay in sync” and deliver products with a common minimal quality level.

For this two tools are very important: The Compatibility Definition Document (CDD) is a document that describes what features are mandatory or highly recommended for a device to comply with Android, and the CTS tests are a series of automated and semi-automated tests to help manufacturers ensure their devices comply with at least the minimal quality levels.

Specifically, for Audio I was surprised to learn the way to do these external tests was called CTS Audio Test Suite (CAT) and involved using a very specific image of linux, and very specific usb sound card and microphones.  Although the spirit of this is good, back in 2014 this was already a challenge to maintain, and even big OEMs had only 1 or 2 dedicated machines with the old image of linux and the required hardware to test.  

I proposed a revamp of this with these goals:

  • The tests will run in Android, and will be part of the CTS Verifier. The logic behind this is that OEMs and developers testing these will easily have access to Android devices, and the code will be easy to maintain as part of the Android repository.
  • The hardware required will be more flexible: Instead of relying on calibrated speakers AND microphones, I pitched to use only a calibrated microphone (which are more affordable and easy to find), and use DSP to estimate and compensate for the frequency response of the speaker
  • The tests can be performed in a “quiet enough” room, instead of an anechoic chamber. This is possible because of using the microphones to assess a baseline for testing.

With these tenants in hand, I developed the new process and incorporated it into the CTS Verifier, created the official instructions, and modified the CDD to make this the new way of assessing Android audio quality standards.  The new tests democratized audio testing and instead of making assessments once or twice during the development of a product, Android engineers managed to perform tests as needed.

AOSP Contributions: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38

Thanks for reading!

-Ricardo (rago)