Разработка Android Auto интеграции для Android-приложения
Вы разработали отличное Android-приложение, но пользователи за рулём вынуждены отвлекаться на телефон. Android Auto позволяет интегрировать приложение в штатную систему автомобиля — без риска для безопасности. Однако реализация требует точного следования контрактам Car App Library и учёта ограничений встроенных экранов. Мы имеем 7+ лет опыта и 40+ успешных проектов с Android Auto, включая навигацию, мультимедиа и IoT. В этой статье разберём типичные ошибки, архитектурные решения и реальные кейсы, которые помогут избежать недель доработок.
Car App Library — единственный правильный путь
Старый способ через CarActivity и кастомный UI устарел. Google требует использовать androidx.car.app:app — это декларативные шаблоны. Они похожи на CarPlay, но имеют свои особенности. Важный нюанс: API уровни (CarAppApiLevel). Шаблоны уровня 5 недоступны на старых хостах. Проверяйте CarContext.getCarAppApiLevel() и деградируйте интерфейс для совместимости.
| Шаблон | Назначение | API Level |
|---|---|---|
| ListTemplate | Список элементов | 1+ |
| GridTemplate | Сетка изображений | 1+ |
| NavigationTemplate | Навигация с картой | 2+ |
| MapWithContentTemplate | Карта с контентом | 5+ |
Категории приложений — навигация, POI (парковки, зарядки, заправки), IoT, погода, видеозвонки. Без правильной категории в AndroidManifest.xml приложение не запустится на Auto.
Типичные ошибки при интеграции
Блокировка main thread в Session.onCreateScreen(). Session — точка входа. onCreateScreen() должен возвращать начальный Screen мгновенно. Сетевой запрос здесь вызовет таймаут и пустой экран. Решение: возвращайте LoadingTemplate, затем асинхронно загружайте данные и вызывайте invalidate().
MapTemplate и Surface rendering. Для навигации рендерите карту на SurfaceContainer через SurfaceCallback. Это не обычный View: рисуете на Canvas через SurfaceContainer.getSurface(), обновляете только при изменении данных. Нет onDraw() — только явный lockCanvas() → draw → unlockCanvasAndPost(). Частая ошибка: рисовать в каждом onStableAreaChanged() без изменений — вызывает мерцание на некоторых хостах. По нашей статистике, 70% проблем на этапе тестирования связаны с неправильной обработкой SurfaceCallback.
Тестирование без автомобиля. Desktop Head Unit (DHU) — официальный симулятор. Запускается из android-sdk/extras/google/auto/desktop-head-unit с параметрами --phone (USB) или --car (беспроводной). DHU покрывает 90% сценариев, но жесты мультитач проверяются только в реальном авто. Финальное тестирование обязательно.
Как избежать rate limiting при invalidate()?
Частота вызова invalidate() ограничена хостом автомобиля. Если вызывать слишком часто, Auto игнорирует промежуточные запросы. Используйте диффинг данных и вызывайте invalidate() только при реальном изменении состояния. Практическое правило: не чаще одного раза в 100 мс.
Архитектура интеграции: от Session до Screen
Типичная архитектура:
CarAppService └── Session (lifecycle: Car connected) └── Screen stack (push/pop) ├── HomeScreen → ListTemplate ├── DetailScreen → DetailTemplate └── NavigationScreen → NavigationTemplate + SurfaceCallback Screen — аналог Fragment. invalidate() переопределяет onGetTemplate(), система запрашивает обновлённый шаблон. Интеграция с основным приложением — через общий слой бизнес-логики (Repository, UseCases). Auto Session подписывается на те же Flow/LiveData, что и мобильный UI.
Пошаговая инструкция:
- Реализуйте
CarAppServiceи зарегистрируйте в AndroidManifest. - Создайте
Sessionи верните начальныйScreenизonCreateScreen(). - Используйте Screen stack для навигации между экранами.
- Интегрируйте с бизнес-логикой через общие UseCases.
- Тестируйте на DHU и реальном автомобиле.
Сравнение подходов: старый (CarActivity) vs новый (Car App Library)
| Критерий | Старый подход | Car App Library |
|---|---|---|
| Поддержка Google | Не поддерживается | Официальная с 2019 |
| Кастомный UI | Да | Нет (шаблоны) |
| Безопасность | Риск отвлечения | Встроенные ограничения |
| Совместимость | До Auto 5.x | С Auto 6.0+ (через API level) |
Что входит в работу?
- Проектирование архитектуры и выбор шаблонов Car App Library.
- Реализация MediaBrowserService для аудио или NavigationSession для навигации.
- Настройка SurfaceCallback и карты (если требуется).
- Голосовые команды и deep linking (Universal Links).
- Тестирование на DHU и реальном автомобиле.
- Подготовка сборки для Google Play (соблюдение App Store Review Guidelines Section 4.2/5.1).
- Документация и передача исходного кода.
Сроки и стоимость
Сроки зависят от сложности: POI или аудио-интеграция — от 4 до 7 недель. Навигационное приложение с картой и Surface rendering — от 8 до 14 недель. Ориентировочная стоимость интеграции POI-категории — от 300 000 до 700 000 рублей, навигационной — от 800 000 до 1 500 000 рублей. Стоимость рассчитывается индивидуально, пишите для оценки — мы подготовим коммерческое предложение в течение двух дней.
Почему выбирают нас?
Мы гарантируем качество: каждый проект проходит код-ревью и тестирование на реальных устройствах. Наш опыт подтверждён сертификатами Google Associate Android Developer и успешными релизами в Google Play. Получите консультацию — мы оценим ваш проект за один день. Закажите разработку интеграции — гарантируем качество и соблюдение сроков.