Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Challenges developing an Android-based system f...

Avatar for DM DM
September 22, 2025

Challenges developing an Android-based system for 2-wheel vehicles

Avatar for DM

DM

September 22, 2025
Tweet

Other Decks in Programming

Transcript

  1. Challenges developing an Android based system for 2-wheel vehicles Challenges

    developing an Android-based system for 2-wheel vehicles Luke Carwardine - DroidKaigi (2025/09/12)
  2. Engineering manager at Drivemode for the IVI (In-Vehicle Infotainment) team

    Focus on developing software that connects the rider with the bike About me I work on this! IVI App
  3. “Smarter, safer, connected driving in any vehicle” Develops software for

    both 2W and 4W vehicles Acquired by Honda in 2019 About Drivemode
  4. A Unified System everything works together seamlessly A Modern Experience

    smooth and responsive UI Maintains Rider Safety glanceable composition Software Mission
  5. Default UI is tailored towards cars CarService for interfacing with

    the vehicle: CarPropertyManager CarPowerManager CarDiagnosticManager CarBluetoothManager etc… Android Automotive OS Designed for cars, not bikes Apps CarLauncher SystemUI Other apps Services Android Services Car Services HAL Standard HAL Vehicle HAL BSP Linux Kernel
  6. Non-standard APIs AAOS launched under-cooked basic support deprecated features Vendors

    use custom implementations to overcome limitations Android Automotive OS Apps CarLauncher SystemUI Other apps Services Android Services Car Services Custom Services HAL Standard HAL Vehicle HAL BSP Linux Kernel
  7. Apps CarLauncher SystemUI Other apps Services Any Interface HAL Standard

    HAL Vehicle HAL BSP Linux Kernel Need to support any interface Android Automotive OS
  8. We are not trying to be “an app”, we are

    the whole user experience No need for CarLauncher or SystemUI Android Automotive OS The Drivemode Experience Apps Drivemode ecosystem Services HAL Standard HAL Vehicle HAL BSP Linux Kernel Any Interface
  9. Decoupling from the Vehicle Vehicle specific or common modules Modules

    must either work anywhere, or only on a single vehicle Standard Modular Architecture Familiar Android / Gradle architecture Runs anywhere, no bike needed Phone/tablets Raspberry Pi or other boards Emulator No Requirement for AAOS Runs on standard Android builds
  10. Build system Supports complex requirements Multiple build variants Multiple apps

    
 (including desktop) Unique tasks Custom gradle plugin architecture Plugin handles common dependencies/setup to reduce build.gradle.kts boilerplate Simplify integration with the AOSP Generate Android.mk files Inject build properties Focus on making the developer’s job easy Automate common tasks and handle system app deployment
  11. Bike Modules Bike Scooter Common Modules Scooter Modules Vehicle Staging

    Environment UAT Production Develop Type Release Production Release Scooter Variant Multi-dimensional variants Environment - Which backends? Vehicle - What hardware? Build Type - Develop or Release For example: stagingBikeDevelop productionScooterRelease Build Variants
  12. Legal Meter Overlay IVI Android Software Renders legally required information


    (e.g. speed, odometer) Displays almost immediately when the vehicle is turned on Legal Meter
  13. A separate system on another CPU Always shown and layered

    on top of the Android UI Differs by vehicle Could contain transparency or animation Legal Meter
  14. Inputs primarily through buttons or joystick Touchscreen may or may

    not be available Even with a touchscreen Difficult to interact with using gloves Requires looking at the screen Disabled while bike is in motion Interactions
  15. Menu Select App Few buttons available Generally, only directions +

    select Requires a simple interaction model Interactions Joystick Control App
  16. Could come from any source Compose’s onKeyEvent Activity.onKeyDown CarInputManager Debug

    inputs Inputs can come from multiple sources Debug inputs Handling key inputs
  17. Need to handle Long Presses No native Jetpack Compose support

    Used for global functionality Handling key inputs Displays over most screens
  18. Raw key inputs are transformed in a single location Handling

    key inputs Compose Activity Debug CarInput Service Key press processor Observer A Observer B etc..
  19. Raw key inputs are: intercepted at the top level remapped

    to custom KeyPress type emitted via flow Handling key inputs Compose Activity Debug CarInput Service Key press processor Observer A Observer B etc..
  20. Raw key inputs are: intercepted at the top level remapped

    to custom KeyPress type emitted via flow Handling key inputs Compose Activity Debug CarInput Service Key press processor Observer A Observer B etc..
  21. Raw key inputs are: intercepted at the top level remapped

    to custom KeyPress type emitted via flow Handling key inputs Compose Activity Debug CarInput Service Key press processor Observer A Observer B etc..
  22. UI built around a concept of minimal focus Many screens

    have no focus ring/indicator Those that do are lists Easily tracked inside a view model Focus Recents Jeff John Carl Missed Outgoing Incoming Favorites Pagable Lists Directional Actions
  23. Keyboards break all our UI rules Started with Compose handling

    focus …this did not work well Handle focus manually Focus
  24. Focusable interface Groups are a row or column of Focusables

    Items are interactable UI element UnitItem for screens with one focusable Data model describing the layout and view data Focusables
  25. 1 6 2 3 4 5 Nested groups create the

    layout Outer group considered the bounding box DSL-style API Similar to creating a UI in Compose Nested rows/columns Can mix items and groups Focus Groups
  26. Focus group management Tracks current focus Handles changing focus between

    items Links UI interactions to actions onClick UI animations (e.g. selection or OOB) Designed for consistent behavior and ease of use Focus Group State
  27. Rendered by common composables FocusableColumn FocusableRow FocusableGroup Touchscreen events are

    still handled via Compose, through the FocusGroupState Focus Group Composition
  28. Input KeyPressEmitter KeyRedirector Store Global overlay UI Navigation State View

    model View model ... Higher priority redirector KeyRedirectorStore observes KeyPressEmitter KeyRedirectorStore distributes the key event Sent downstream to KeyRedirectors Unhandled key events propagate via priority Connecting Key Inputs to the UI Priority
  29. Input KeyPressEmitter KeyRedirector Store Global overlay UI Navigation State View

    model View model ... Higher priority redirector View model priority from navigation state Connecting Key Inputs to the UI
  30. Global overlay Media keys Notifications Available on most screens Connecting

    Key Inputs to the UI Input KeyPressEmitter KeyRedirector Store Global overlay UI Navigation State View model View model ... Higher priority redirector
  31. Allows for blocking global overlay functionality Connecting Key Inputs to

    the UI Input KeyPressEmitter KeyRedirector Store Global overlay UI Navigation State View model View model ... Higher priority redirector
  32. MviViewModel provides a common interface for handling key presses KeyPresses

    come through handleKeyPress Key inputs are mapped to FocusGroupState as required, or another action on screens without focus UI Connecting Key Inputs to the UI
  33. Other challenges Bluetooth Requires non-standard profile behaviors iOS and Android

    can behave differently OTA In production, only updateable via OTA Must be robust Power management Additional lifecycle states (ignition on/off)
  34. Other challenges Dead reckoning and map matching Location if GPS

    is lost Selecting the correct road UI Overlay Notifications Media Reverse Other important info Custom UI components Components must conform to safety standards