Хабр, привет! Меня зовут Борис Денисенко. Я мобильный разработчик и наставник на курсе «Android-разработчик» в Яндекс Практикуме. У себя в блоге я пишу про Android Automotive OS, но сегодня отойду от частностей и расскажу, в каких ещё сферах может работать мобильный разработчик, если он не занимается приложениями для смартфонов и планшетов.

Если вы думаете, что навигационная система в современном автомобиле — это просто красивое приложение, которое рисует синюю линию на карте и говорит «через 200 метров поверните направо», вы застряли в 2010 году.

В Android Automotive OS (AAOS) навигация часто становится одним из самых жирных и критически важных системных компонентов. Это «пространственный мозг» машины. Десятки других модулей постоянно дергают её за рукав с вопросами: «Где мы?», «Какое ограничение скорости?», «Сколько полос на дороге?», «В какой полосе мы сейчас едем?».

В этой статье я поделюсь опытом из своей практики разработки навигационной системы для крупного немецкого автопроизводителя. Мы разберем, как построить надежное межпроцессное взаимодействие (IPC) внутри автомобиля на примере передачи ADAS-атрибутов для японского модуля ETC 2.0.

В предыдущих сериях мы научились ковыряться под капотом: доставать данные с датчиков через VHAL и прятать кнопки от водителя, когда машина едет. Но давайте честно: просто выводить скорость на экран — это скучно. Этим занимались инженеры еще в 90-х.

Сегодня мы живем в эпоху ИИ. У нас есть железка стоимостью в десятки тысяч евро, напичканная датчиками, и операционная система, которая может всё это читать. Так давайте дадим машине «мозги»!

В этой статье мы напишем концепт Smart Driving Assistant — фонового сервиса на Android Automotive, который будет анализировать телеметрию (руль, педали, скорость) и с помощью локальной нейросети (On-Device ML) понимать, что водитель начал "играть в шашечки" на дороге.

В прошлой серии мы научились вытаскивать из машины данные. Мы знаем скорость, обороты двигателя и даже какая дверь открыта. Руки чешутся вывести всё это на огромный экран в 4K, добавить анимаций, графиков и запустить YouTube на фоне, да?

Не спешите.

Если вы сделаете это, ваше приложение никогда не попадет в стор. А если вы работаете на OEM (автопроизводителя) и протащите это в прод — вас, возможно, проклянут водители, въехавшие в столб, пока разглядывали ваш красивый график расхода топлива.

Сегодня говорим о Driver Distraction — главной боли и главной фишке разработки под авто. О том, как сделать интерфейс, который не убивает.

В прошлой статье мы запустили эмулятор и убедились, что Android Automotive OS (AAOS) — это не просто зеркало вашего телефона. Это самостоятельная экосистема. Но пока мы запускали только стандартные медиа-плееры, мы скользили по поверхности.

Настоящая магия начинается там, где софт встречается с «железом».

В телефоне у вас есть стандартный набор датчиков: GPS, акселерометр, гироскоп. В современном автомобиле таких датчиков тысячи: от давления в шинах и температуры масла до угла поворота руля и статуса каждой двери. Как Android-разработчику получить доступ к этому океану данных? Не будем же мы тянуть провода к OBDII разъему?

Конечно, нет. Для этого Google построила мощный мост, по которому мы сегодня и пройдемся. Добро пожаловать в мир Car API и VHAL.

Мир полон отличных и не очень мобильных приложений, ваш код работает на миллионах девайсов в карманах пользователей. Но это все еще «малый экран». А как насчет того, чтобы ваш софт крутился на дашборде Polestar или Volvo?

Раньше разработка под Automotive была похожа на закрытый клуб масонов: свои проприетарные системы, SDK, которые выдавали только по подписке кровью, и документация которую походу специально шифром непонятным на случай оккупации писали. Но потом пришел Google, и понял что тут он еще не зарабатывал. Так появился Android Automotive OS (AAOS).

И нет, это не тот Android Auto - зеркало который транслирует карты с вашего телефона на экран машины. Давайте сразу это запомним ибо путаница здесь колоссальная.