Early experience: Automating UI tests for Android Automotive OS

Apr 12, 2021 / by Joona Sinisalo

In 2020, Joona Sinisalo Product Specialist at Qentinel was working on a test automation proof-of-concept project for an automotive software platform. During the project, he heard about Android Automotive and became interested. Is this something where Qentinel's test automation platform and libraries could be utilized? 

Introduction

Android Automotive is an OS running the in-car infotainment system. In addition to infotainment, it can handle vehicle-specific functions. Android Automotive was introduced by Google in 2017 and its APIs were opened for development in 2019. It is basically a base Android with automotive-specific extensions.

Qentinel has been developing UI test automation solution for Android for some time now. It would be interesting to see how easy it is to adopt for the automotive version.

Where to start

I was not familiar with Android development and had to start somewhere. There were a couple of good posts online that explained how to set up a development environment. Google's Android developer pages are also well put together and informative.

Installing Android Studio was the first step. There are requirements for the Android SDK version and Android Studio itself to enable automotive extensions. Android Studio had to be installed from an unstable (Canary) channel to get the system images for automotive. Supported SDK was version 10 at the time. Currently, there is version 11 released for automotive.

Android Studio comes with a built-in emulator and different emulator setups are easy to configure using the studio's AVD manager. There's also an emulator available from car manufacturer Polestar (Volvo) that simulates the infotainment screen of their electric vehicle Polestar 2. I tried both and they worked straight out of the box. One observation though, emulators are very resource-intensive and can lead to problems if you try to demo something with an emulator during a Teams meeting.

I also used an example Android Automotive application project from GitHub to verify that building and installing packages was working in this setup. The example app was installed and launched in the emulator without trouble so the setup was ready for trying out automation.

First steps with automation

Ok, now I had Android Studio set up and the emulator running. The next target was to do a simple UI test automation project: a Robot Framework script using Qentinel's mobile library to launch the emulator, open an app, do some verification and button clicking, and close the emulator.

To be able to connect to an Android device and launch an application Qentinel's mobile library is using yaml-files to configure test setups. The file includes definitions about the device, session, platform, app capabilities, and connection. This information is used by Appium to provide a connection to the device. Android apps have the concept of activities where the main activity defines the view in which the app starts. This means that the app's main activity needs to be defined in the yaml-file for the app to start correctly.

The UI on Android Automotive has some differences from base Android since it has been designed to run on car infotainment screens. I wasn't sure if the existing test automation library for mobile would work with the buttons and elements. After writing a simple test script and finishing the configuration file I started a test run and was surprised. Emulator startup, connection, and shutdown worked. Test framework was able to install and launch the app that was previously built. UI automation was (mainly) working, great!

Moving to cloud

The objective of this trial project was to see how Qentinel's cloud-based test automation platform and mobile testing tools bring value to Android Automotive testing. Mobile test automation libraries were already proven useful, but the test run control was still on local setup and should be moved to the cloud, to Qentinel Pace.

This project would require a hybrid setup. Meaning that run control, test scripts, and reporting from the cloud, where the device under test is connected to a host machine. For this setup, I created a project in Qentinel Pace and assigned a PaceConnect agent for it. PaceConnect is a tool that enables a hybrid setup: it installs required software to host machine and initializes an agent that handles the connection between Qentinel Pace cloud and the DUT, an Android Automotive emulator in this case.

The cloud-based test automation setup was now ready. All I had to do was to start the PaceConnect agent on my laptop and click run in Qentinel Pace. This would launch the emulator on my machine, handle connection, run tests, and report results back to the cloud. 

What's next

It's always inspiring to experiment with new technologies and try something that hasn't been done before. However, this progress should be utilized and transformed into value for customers.

The trial project proved that Qentinel's test automation platform and libraries can be used for automating Android Automotive testing. UI tests can be written using simple PaceWord libraries, test run control, and reporting are accessible from the cloud, and testing resources can be easily scaled. 

We have continued the development of our Android Automotive capabilities and already experimented with real devices, and robot arms, with our partners. Our work continues and we will bring value-adding solutions for automotive software testing.


Want to try out test automation right away? Start testing now and create own robots with few easy steps. Or Contact Us to find a customized solution for your purposes.

Start Free Trial

 

Topics: Software Testing, Test Automation, Software Development, Test design, Test architecture, Android Automotive

Joona Sinisalo

Written by Joona Sinisalo