Разработка Android Auto интеграции для Android-приложения
Android Auto позволяет вывести интерфейс приложения на экран мультимедийной системы автомобиля через USB или беспроводное подключение. Архитектурно это хост-рендеринг: автомобиль запрашивает шаблоны через Car App Library, приложение их формирует — но отрисовывает не само приложение, а хост на стороне Auto.
Car App Library — единственный правильный путь
Старый способ через CarActivity и кастомный UI устарел. С Android Auto 6.0+ Google требует использовать androidx.car.app:app (Car App Library). Это декларативные шаблоны, похожие на CarPlay: ListTemplate, GridTemplate, NavigationTemplate, MapWithContentTemplate.
Важный нюанс: Car App Library имеет несколько API уровней (CarAppApiLevel). Шаблоны, добавленные в уровне 5, недоступны на автомобилях с более старым хостом. Проверяем CarContext.getCarAppApiLevel() и деградируем интерфейс для старых хостов.
Категории приложений — навигация, POI (парковки, зарядки, заправки), IOT (управление умным домом), погода, видеозвонки. С 2024 года Apple-аналогично добавили еду. Обычное приложение без разрешённой категории в AndroidManifest.xml → <category android:name="androidx.car.app.category.NAVIGATION"/> → Auto просто не запустит его.
Типичные ошибки при интеграции
Блокировка main thread в Session.onCreateScreen(). Session — точка входа в Auto приложение. onCreateScreen() должен вернуть начальный Screen мгновенно. Если тут делать сетевой запрос — Auto покажет пустой экран с таймаутом. Правильно: возвращаем LoadingTemplate или пустой ListTemplate, затем асинхронно загружаем данные и вызываем invalidate().
MapTemplate и Surface rendering. Для навигационных приложений нужно рендерить карту на SurfaceContainer через SurfaceCallback. Это принципиально иначе, чем обычный View: рисуем на Canvas через SurfaceContainer.getSurface(), обновляем только при изменении данных. Нет onDraw() цикла — только явный lockCanvas() → draw → unlockCanvasAndPost(). Частая ошибка: рисовать в каждом onStableAreaChanged() даже если карта не изменилась — это видно как мерцание на некоторых хостах.
Тестирование без автомобиля. Desktop Head Unit (DHU) — официальный симулятор от Google. Запускается через android-sdk/extras/google/auto/desktop-head-unit. DHU с параметром --phone эмулирует телефон-режим (USB), --car — беспроводной. Финальное тестирование в реальном авто обязательно — поведение SurfaceCallback и жесты на тач-экране авто воспроизводятся только там.
Архитектура
CarAppService
└── Session (lifecycle: Car connected)
└── Screen stack (push/pop)
├── HomeScreen → ListTemplate
├── DetailScreen → DetailTemplate
└── NavigationScreen → NavigationTemplate + SurfaceCallback
Screen — аналог Fragment. invalidate() переопределяет onGetTemplate(), система запрашивает обновлённый шаблон. Нельзя обновлять шаблон быстрее, чем разрешает хост — есть rate limiting. Если invalidate() вызывается слишком часто, Auto игнорирует промежуточные вызовы.
Интеграция с основным приложением — через общий слой бизнес-логики (Repository, UseCases). Auto Session подписывается на те же Flow/LiveData что и мобильный UI.
Сроки
POI или аудио-интеграция: 4–7 недель. Навигационное приложение с картой и Surface rendering: 8–14 недель. Стоимость зависит от сложности навигационной логики и наличия существующей карты в мобильном приложении.