what we encountered when integrating 2GIS navigator into Android Auto

Hey! I’m Anya, a QA engineer from the Android team at 2GIS. In the middle of last year, we established contact with the Google team. At that time, there was no release of the Android Auto SDK yet. But we got early access to the SDK and were the first in Russia to integrate the navigator into it. In this article I will tell you how it was.

Gradually learned the requirements and restrictions

We started in June, when not all the documentation for Android Auto was written. It appeared in its entirety by October 2020. Until October, we worked with the initial version of the documentation.

Google has strict requirements for third-party developers. The conditions that we learned from the documentation had to be taken into account. We had to either abandon the original ideas, or implement them in a different way. We cut off the functionality and design. Here are some examples.

We threw out the cases where the cars were supposed to be. They were planned to be added only in the second version of the SDK. So we had to add zoom buttons on all screens to allow the user to scale the map.

Refused to show the travel time to the object. Initially, it was planned as follows: the user typed “Cafe” in the search, 2GIS showed the pins of the cafe on the map and mini-cards. The mini-cards contain titles and other information.

But it didn’t work out. Since a map is drawn against the background of the search results, according to Google’s requirements, it is the distance that needs to be indicated.

It turned out that you can’t render your UI. Google requires all navigators to look consistent. The user is busy driving, you cannot waste his attention on the new interface. Therefore, the entire UI is created by the framework. We could only choose a ready-made template and draw a 2GIS map on its background. You couldn’t use your own fonts, control day and night themes.

Removed notifications about speed cameras. Because the places for these notifications were occupied by other buttons and controls. And the number of items on the screen is limited.

I had to limit the lists to six items. According to the requirements, user stories should be short, with a minimum of information. Therefore, Android Auto has no more than six list items, be it app settings or search results. This is unusual for the user, but it is not possible to display more items in the lists. The system monitors compliance with the restrictions. If the rule is violated, the application will be stopped.

The same rule imposed on us a depth limit of five screens. For example: main screen → go to search → get a list of cafes → open a café card → choose an alternative route – that’s it, the limit has been reached.

All of these limitations forced us to rethink our feature implementation process.

It usually looked like this:

In the task of implementing the navigator, the process has changed:

The usual stages of work had to be abandoned. In an atypical task, there is a high risk of doing something, and then figuring out that something else is needed. Therefore, we went in short iterations. Development, testing and work on designs in different parts of the project were parallel. This helped to quickly determine what was realistically done and what wasn’t.

Tested on our own hardware and test environment

The first QA build appeared at the end of August 2020. We received radio tape recorders – the same as they are installed in cars. But not all testers had cars, so our radio tape recorders were modernized: the administrators soldered a plug and a 12V power supply from the computer to each of them.

When I started testing the radio, I ran into a problem: if I simulate movement, I can look at the map, but I can’t delve into the settings. It turned out that the application can be configured only when the car is stationary – these are the safety standards. That is, I need to prove to the Android Auto system that my “car” is parked.

Had to emulate the parking brake or parking mode. I closed the Parking wire to the radio case and went into the settings.

We also added hardware when we tested the voice acting of the navigator. The radio does not have its own speakers, it reproduces sound through the car’s audio system. But our “cars” did not have it. This means that you need a test environment that would repeat this scheme.

I found an old speaker, the developers and I figured out how to attach it to the radio. I strip the wires, connect – there is still no sound.

There were three options, what is the problem: a speaker, a radio tape recorder, or an application. I started the radio – the sound appeared. The problem is in the app! This is how I found the first bug with blocker priority. We reported it to Google, and the bug was fixed.

Another requirement was Cluster Display support. This is an additional screen for vehicles manufactured after 2020.

You can’t buy it separately, like a radio tape recorder. Finding a car with it is not easy. There were no cars with such a display in Novosibirsk car dealerships – this was checked by our product. So we set up a headunit emulator and hoped that would be enough. Naturally, during the review in the side, it turned out that this was not the case. The maneuvers in the Cluster Display did not always match the maneuvers in the navigator. We have fixed this problem.

Catching bugs even before release

Bugs were divided into two categories: those that are reproduced only on a radio tape recorder, and those that are reproduced only on a car.

Of the first, I remember a bug when navigation disappeared after a few minutes of driving. I ran motion emulation and after a few minutes I was thrown to the main screen. The logs were empty. We decided that the problem was in my radio and stopped worrying. As it turned out, in vain. A couple of months later, this bug made life difficult for one of our colleagues when he installed our navigator and went to Altai.

The fix of this bug was complicated by the fact that the bug still did not pop up among the developers. To understand what was the matter, I had to contact the guys from Google. They gave us a solution and the bug was fixed.

The bugs that were reproduced only on the car were caught by colleagues on their cars. The location bug was especially interesting. When I was at home, I changed my geolocation using the internal utility: in it, you can change the direction of movement, stop, leave the route, and so on. Testing was successful until we drove a real car. It turned out that when the car stands for a long time, in a traffic jam or at traffic lights, the location marker rotates around its axis.

It turned out that this was not even a bug, but an implementation feature. At low travel speeds, GNSS gives the marker a random direction. As if we are marking time, turning around all the time. It is treated by the fact that when the speed drops below a certain threshold, the direction is frozen. In the main 2GIS application this was done many years ago, but in the implementation for Android Auto I had to remember about it again.

There were some bugs in the SDK itself. It was in our interest to work with a stable SDK, so we helped to catch these bugs: we collected logs and videos, sent them in bug reports to Google developers. They quickly entered into a dialogue and helped solve the problem – either they fixed a bug, or suggested what to do to us. It was clear that they did not care at all how and when the problem was solved. I have a very pleasant impression from such participation.

We caught a bug with voice search in the SDK. 2GIS does not affect the context of voice input recognition, it is part of Google. In Akademgorodok, where one of our offices is located, there is a canteen called “Kukuruza”. When our product tried to build a route to it, he heard: “Corn is an annual herbaceous cultivated plant …”. Educational, of course, but it didn’t help to get to cutlets.

Finally, we fixed everything and went to the review in the side. Usually it took us 12 hours from review to release, but not this time. The app was returned for revision because it “used a permission not allowed for this category.”

Users were already angry: in the announcement, written before the review, we promised Android Auto, but it is still not in the store:

We have been looking for the problem for several days. It turned out that our application did not stop when the user launched another navigation program. Alerts popped up on the screen from two applications at once. According to the TK, this was prohibited. Of course, they could not miss such a mistake.

The problem was fixed and on November 12, 2020 we launched a public beta test. We were proud – 2GIS was the first third-party developer in Russia to release an application for Android Auto.

Self-made test benches and thousands of kilometers on their own cars. Close communication with Google developers, the time difference with them is 14 hours. And a job where you need to look for non-standard solutions on the go. This project turned out to be very memorable and I am glad that I took part in it.