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

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. IVI? 2-Wheel? Android? https://www.youtube.com/watch?v=Q5IbqJAV7fs
5. A Unified System everything works together seamlessly A Modern Experience smooth and responsive UI Maintains Rider Safety glanceable composition Software Mission
6. What about Android Automotive OS?
7. 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
8. 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
9. Apps CarLauncher SystemUI Other apps Services Any Interface HAL Standard HAL Vehicle HAL BSP Linux Kernel Need to support any interface Android Automotive OS
10. 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
11. 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
12. How do we achieve this?
13. 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
14. 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
15. Straight-forward configuration scripts Build Scripts
16. Custom plugins for apps and libraries Build Scripts
17. dmConfig is the plugin configuration block Build Scripts
18. Common app configuration Build Scripts
19. Vehicle specific configurations Build Scripts
20. AOSP related configuration Build Scripts
21. Special dependencies block Build Scripts
22. Configurations can be extremely simple Build Scripts
23. Time to start coding... right?
24. 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
25. 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
26. Requires synchronization with Android Communication via Vehicle API Challenge to maintain synchronization Legal Meter
27. Anything else to consider?
28. 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
29. Menu Select App Few buttons available Generally, only directions + select Requires a simple interaction model Interactions Joystick Control App
30. Could come from any source Compose’s onKeyEvent Activity.onKeyDown CarInputManager Debug inputs Inputs can come from multiple sources Debug inputs Handling key inputs
31. Need to handle Long Presses No native Jetpack Compose support Used for global functionality Handling key inputs Displays over most screens
32. Support for Short and Long key presses Handling key inputs
33. 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..
34. 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..
35. 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..
36. 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..
37. How does this interact with the UI? Firstly, let’s discuss focus
38. 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
39. However...
40. Keyboards break all our UI rules Started with Compose handling focus …this did not work well Handle focus manually Focus
41. 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
42. 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
43. 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
44. Rendered by common composables FocusableColumn FocusableRow FocusableGroup Touchscreen events are still handled via Compose, through the FocusGroupState Focus Group Composition
45. So... about those key inputs?
46. 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
47. 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
48. 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
49. 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
50. 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
51. There’s a lot more! But we don’t have enough time...
52. 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)
53. 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
54. Thank you!