Affiliate links on Android Authority may earn us a commission. Learn more.
Android 17 could mimic this helpful iOS feature to reduce motion sickness
1 hour ago

Many people avoid using their Android phones in moving vehicles due to motion sickness, a condition that can induce nausea, headaches, and dizziness. Motion sickness is believed to be caused by a sensory conflict; your eyes focus on a stationary object (the phone) while your inner ears signal that you are moving. Since people spend so much time as passengers, it’s a bummer that many can’t use their phones without feeling sick. Fortunately, Google is working on a new feature for Android 17 aimed at reducing this discomfort.
You’re reading the Authority Insights Newsletter, a weekly newsletter that reveals some new facet of Android that hasn’t been reported on anywhere else. If you’re looking for the latest scoops, the hottest leaks, and breaking news on Google’s Android operating system and other mobile tech topics, then we’ve got you covered.
Subscribe here to get this post delivered to your email inbox every Saturday.
Called Motion Cues, the feature mitigates this sensory mismatch by adding visual elements that mimic the vehicle’s movement. It places dots on the screen that shift in real-time based on data from your phone’s motion sensors. This simple yet incredibly useful trick effectively “moves” the screen with you, potentially solving motion sickness for many users.
If this feature sounds familiar, it’s because Google isn’t the pioneer here. While Apple’s Vehicle Motion Cues in iOS 18 might be better known, a free Android app implemented this idea back in 2018. Available for any phone running Android 7.0 or later, KineStop simply requires you to download it, grant the “display over other apps” permission, and tap start.

Why, then, must Google’s version wait for next year’s Android 17 update? It is a question we’ve grappled with since discovering evidence of Motion Cues in late 2024. According to our resident APK teardown specialist, Assemble Debug, the feature is fully functional but lies dormant in Google Play Services. However, it has a flaw that likely explains why Google is holding off on releasing it until a future OS release.
As shown in the screen recording above, the motion dots fail to appear over system elements like the Settings app, status bar, notifications, Quick Settings, lock screen, or volume panel. This happens because the current implementation relies on Android’s standard overlay API. For security reasons, Android prevents apps from drawing over these critical system components to stop malicious actors from tricking users into performing unintended actions. While this is a sensible security limitation, it reduces the effectiveness of Motion Cues.

Android 17 could address this by introducing a system-level Motion Cues API. Evidence found in the latest 2512 Android Canary release suggests this API transfers the rendering responsibility to SystemUI — the exact system app that manages the components where Motion Cues currently fail to appear.
Android now includes code — MotionCuesService, IMotionCuesCallback, MotionCuesData, and MotionCuesSettings — that allow a client application (in this case, Google Play Services) to define the X/Y coordinates, color, radius, and spacing of the dots. It then renders these dots on a privileged window layer via the startMotionCuesSession command. Effectively, Google Play Services determines the placement and look of the dots, while SystemUI handles the actual on-screen display.
To prevent third-party apps from cluttering the screen with unwanted dots, Android only allows apps holding the new DRAW_MOTION_CUES permission to use the API. This permission is restricted to privileged system apps or those signed by the platform certificate. SystemUI will only bind to services (BIND_MOTION_CUES_SERVICE) that meet this requirement, ensuring it ignores data from unauthorized third-party apps.
This dual-layer architecture bypasses the limitations of the overlay API, but because it relies on a new system API, it requires an OS upgrade. This would explain why Google hasn’t released the feature yet. Depending on Google’s roadmap, we could see this feature roll out in the third quarterly release of Android 16 or, more likely, in Android 17. While we don’t know Google’s plans for this feature, I’m personally betting on an Android 17 debut.
Hopefully, Google releases a version of this feature that’s compatible with existing devices. Despite the limitations with the overlay API, many would still find the current implementation useful. If Google doesn’t release the feature as is, though, users can always turn to KineStop as a reliable alternative.
When Google eventually launches the feature, it might debut as “Motion Assist” rather than “Motion Cues” to avoid accusations of copying Apple. Regardless of the name, we hope Google integrates it with the upcoming Transiting mode, which is designed to automate device settings for smoother commutes. Ideally, Transiting mode would trigger Motion Assist automatically, though the feature’s built-in vehicle detection might make that unnecessary.
Want more?
Authority Insights is more than a newsletter — it’s the hub for all our best content. If you care about Android, you won’t want to miss any of our other exclusive reports.
Don’t have time to read them all? Subscribe to our Authority Insights Podcast to hear me and my co-host, C. Scott Brown, break down our top stories of the week.
This week’s top Authority Insights
A first look at other new features coming to Android 17


New tools for tracking symptoms and protecting your senses


Handshakes & hotspots: Updates to cross-device communications



Google polish: Quality-of-life tweaks to menus, reading, and discovery




Other top stories
One UI 8.5 is smarter but looks too familiar



We strapped Android to our faces and couldn’t be more excited


The State of Pixel: Nagging pains & future promises



Killing the Flagship Killer?



Power user moves: Tips, tricks, and UI updates




Thank you for being part of our community. Read our Comment Policy before posting.