Tag Archives: latest

Gesture Navigation: A Backstory

Posted by Allen Huang and Rohan Shah, Product Managers on Android UI

mobile ui

One of the biggest changes in Android Q is the introduction of a new gesture navigation. Just to recap - with the new system navigation mode - users can navigate back (left/right edge swipe), to the home screen (swipe up from the bottom), and trigger the device assistant (swipe in from the bottom corners) with gestures rather than buttons.

By moving to a gesture model for system navigation, we can provide more of the screen to apps to enable a more immersive experience.

We wanted to give folks an inside look at how we’ve approached this challenge, the rationale, and some of the trade-offs as well. There is some nerding out on design around gestures ahead, but hopefully it provides some insight into our process and how we balance the developer and OEM ecosystem in service of users. If you’re looking for more detail on how to handle these changes as an app developer, check out Chris’s “Going edge-to-edge” article series.

Why gestures?

One of the amazing things about Android is the opportunity for app developers and Android partners to try new, innovative approaches on the phone.

In the last 3 years, we’ve seen gesture navigation patterns proliferate on handheld devices (though gestures have been around as early as 2009!).

This trend was led by innovative Android partners and Android apps trying some very cool ideas (for example: Fluid NG, XDA).

When we started researching this more, we honed in on the user benefits:

  1. Gestures can be a faster, more natural and ergonomic way to navigate your phone
  2. Gestures are more intentional than software buttons that you might trigger just by grabbing your phone
  3. Gestures enable a more immersive experience for apps by minimizing how much the system draws over app content, i.e. HOME/BACK buttons and the bar they sit on - especially as hardware trends towards bigger screens and smaller bezels

It wasn’t all roses though - we also saw issues with many of the gesture modes:

  1. Gestures don’t work for every user
  2. Gestures are harder to learn and can take some adjustment
  3. Gestures can interfere with an app’s navigation pattern

But most of all, we realized that there was a larger issue of fragmentation when different Android phones had different gestures, especially for Android developers.

Over the last year, we worked with partners like Samsung, Xiaomi, HMD Global, OPPO, OnePlus, LG, Motorola, and many others to standardize gesture navigation going forward. To ensure a consistent user and developer experience, the Android Q gestures will be the default gesture navigation for new Q+ devices.

Understanding that these gestures don’t work for every user, especially those with more limited dexterity and mobility, three-button navigation will continue to be an option on every Android device.

So why these gestures?

We started with research to understand how users held their phones, what typical reach looked like, and what parts of the phone users used the most. From there, we built many prototypes that we tested across axes like desirability, speed-of-use, ergonomics, and more. And we put our ultimate design through a range of studies - how quickly users learned the system, how quickly users got used to the system, how users felt about it.

A unique element of Android navigation since the very beginning is the Back button. It is appreciated by many users that find Android easier to navigate and learn (despite many debates on what the “correct” behavior is) -- and it's used a lot! In fact, 50% more than even Home. So one of our design goals was to make sure the back gesture was ergonomic, dependable, and intuitive -- and we prioritized this goal above other less frequent navigation such as drawers and recents.

Looking at the reachability charts below, we designed our two core gestures (Back and Home) to coincide with the most reachable/comfortable areas and movement for thumbs.

Phone screen heatmaps showing where users can comfortably do gestures, holding the phone in only one hand

Phone screen heatmaps showing where users can comfortably do gestures, holding the phone in only one hand

As mentioned, we built prototypes of many different gesture models, comparing user ratings and timed user tasks on what ultimately became the Q model to several other navigation paradigms. Here’s a few graphs showing the results of our testing:

Comparison of user ratings for ergonomics and one-handed use across different navigation modes (higher is better)

Comparison of user ratings for ergonomics and one-handed use across different navigation modes (higher is better)


Comparison of average time required to complete Home/Back tasks across various navigation modes (lower is better)

Comparison of average time required to complete Home/Back tasks across various navigation modes (lower is better)


Comparison of average time required to complete Overview/Recents-based tasks across various navigation modes (lower is better)

Comparison of average time required to complete Overview/Recents-based tasks across various navigation modes (lower is better)


Users, on average, performed tasks involving Home and Back more quickly than most other models - even faster than they did with buttons. The model did, however, come at the cost of being able to quickly access Overview/Recent apps, which users go to less than half as often as the Home screen.

From a more qualitative perspective, users viewed the Q model as more one-handed and reachable, although buttons were still viewed as more ergonomic for more users.

App Drawers and other App Swipes

Although we arrived at the side swipe as the gesture for back that best balanced many tradeoffs, it is important to note that there were hard decisions, particularly in how that gesture impacted apps.

For example, we found that ~3-7% of users (depending on the Google app) swipe to open the App Navigation Drawer - the rest of our users push the hamburger menu to invoke the drawer. This drawer swipe gesture is now overloaded with back and some users will need to adapt to using the hamburger menu. This was a tough choice but given the prolific use of back we optimized for what worked best there.

Because it’s never a goal to change out behavior on users, we tried several ways to enable users to distinguish the drawer gesture from the Back gesture. However, all these paths led to users pulling in the drawer when they were trying to go Back and having less confidence that Back would work.

Beyond drawers, gestures are a big change for people and it took on average 1-3 days to adapt - in particular, users struggled with patterns like swiping right or left on a carousel and triggering Back.

In qualitative studies, we found that after an initial break-in period of 1-3 days, users became fluent and could consistently distinguish between these two gestures. The majority of users did not want to switch back to 3 button nav (even though that remains an option).

Additional research showed that there is a clear adjustment phase for users to get used to a new system navigation (across many different navigations). In our Q model, we found that usage of Back goes down for the first 1-3 days. After that period, the average # of Back presses/day ends up being the same as 3-button and our P navigation.

So What Does This Mean for Developers?

With gestural navigation, we are aiming to move forward and standardize the user experience on Android. The model we landed on is the optimal one for most users, but it also means that some of the gestures conflict with existing app gestures, necessitating developer adjustments to how users interact with your apps. We take our responsibility to Android developers seriously and want to help you in this process.

There are three key steps to support gesture navigation:

  1. Go edge-to-edge to enable your app to draw across the entire screen
  2. Handle any visual overlaps with the system user interface (i.e. navigation bar)
  3. Resolve any gesture conflicts with the system gestures

We’ve just published the first article in our “Going edge-to-edge” series on Medium, detailing those steps in turn. The final article in the series will cover some of the common scenarios we’ve seen, and how you can best support them in your apps.

Thank you all for the feedback -- all of your comments and interactions have helped us improve the gesture navigation experience in Android Q and, more broadly, help make Android better each day.

Final Beta update, official Android Q coming soon!

Posted by Dave Burke, VP of Engineering

AndroidQ logo

We’re just a few weeks away from the official release of Android Q! As we put the final polish on the new platform, today we’re rolling out Beta 6, the last Beta update. Now is the time to make sure your apps are ready, before we bring the official release to consumers. Take this opportunity to finish up your testing and publish your app updates soon to give users a smooth transition to Android Q.

You can get Beta 6 today on Pixel devices by enrolling here. If you're already enrolled and received Beta 5, you'll automatically get Beta 6 soon. Partners participating in the Android Q Beta program will also be updating their devices over the coming weeks -- visit their sites to learn more. To get started with Android Q, visit developer.android.com/preview.

Watch for more information on the official Android Q release coming soon!

What’s in Beta 6?

Today’s Beta 6 update includes the latest Android Q system images for Pixel and Android Emulator, the final API 29 SDK, and updated build tools for Android Studio. Beta 6 includes all of the features, system behaviors, and developer APIs that you’ll find in the final platform, so it gives you everything you need to get your apps ready. For users, Beta 6 includes many new fixes and optimizations -- take a look at the release notes for details.

We've made further refinements to Gesture Navigation in Beta 6 based on user feedback. First, to ensure reliable and consistent operation, there's a 200dp vertical app exclusion limit for the Back gesture. Second, we've added a sensitivity preference setting for the Back gesture. Watch for more details coming soon in our blog post series on optimizing for gesture navigation.

Get your apps ready for Android Q!

With the consumer release coming soon, we’re asking all Android developers to update your current apps for compatibility as soon as possible.

Here’s how to do it:

We realize that supporting these changes is an investment for you too, so thanks to all of you who have prioritized the work to get your apps ready for Android Q!

Enhance your app with Android Q features and APIs

Next, when you're ready, dive into Android Q and learn about the new features and APIs that you can use. Here are some of the top features to get started with.

We recommend these for every app:

  • Dark Theme: Ensure a consistent experience for users who enable system-wide dark theme by adding a Dark Theme or enabling Force Dark.
  • Support gestural navigation in your app by going edge-to-edge and making sure your custom gestures are complementary to the system navigation gestures.
  • Optimize for foldables: Deliver seamless, edge-to-edge experiences on today’s innovative devices by optimizing for foldables.

We recommend these if relevant for your app:

  • More interactive notifications: If your notifications include messages, enable suggested replies and actions in notifications to engage users and let them take action instantly.
  • Better biometrics: If you use biometric auth, move to BiometricPrompt, the preferred way to support fingerprint auth on modern devices.
  • Enriched recording: To support captioning or gameplay recording, enable audio playback capture -- it’s a great way to reach more users and make your app more accessible.
  • Better codecs: For media apps, try AV1 for video streaming and HDR10+ for high dynamic range video. For speech and music streaming, you can use Opus encoding, and for musicians, a native MIDI API is available.
  • Better networking APIs: If your app manages IoT devices over Wi-Fi, try the new network connection APIs for functions like configuring, downloading, or printing.

These are just a few of the many new features and APIs in Android Q -- to see them all, visit the Android Q Beta site for developers.

Publish your app updates to Google Play

As soon as you're ready, publish your APK updates to Google Play that are compiled against, or optionally targeting, API 29. To make sure that your updated app runs well on Android Q as well as older versions, try using Google Play testing tracks. With tracks you can safely get early feedback from a small group of users and then do a staged rollout to production.

How do I get Beta 6?

It’s easy! Just enroll any supported Pixel device here to get the update over-the-air. If you're already enrolled, you'll receive the update soon and no action is needed on your part. Downloadable system images are also available here. Partners who are participating in the Android Q Beta program will be updating their devices over the coming weeks. See android.com/beta for details.

To get started developing, download the official API 29 SDK and tools into the stable release of Android Studio 3.4, or for the latest Android Q support update to Android Studio 3.5 Beta. Then follow these instructions to configure your environment, and see the release notes for known issues.

Please continue to share your feedback and requests in our issue tracker. You can use our hotlists for filing platform issues (including privacy and behavior changes), app compatibility issues, and third-party SDK issues.

A big thank you to our developer community for your participation in our recent Reddit AMA on r/androiddev! It’s always great to hear what’s important to you and we hope we were able to help!

Kotlin named Breakout Project of the Year at OSCON

Posted by Wojtek Kaliciński, Developer Advocate, Android

Stephanie on Stage with Kotlin on screen

Stephanie Saad Cuthbertson announces support for Kotlin during the Developer Keynote at I/O 2017.

Today at OSCON (the O'Reilly Open Source Software Conference), Kotlin was awarded the Open Source Award for Breakout Project of the Year.

There is no doubt to us why Kotlin received this award: it’s a fast moving (but thoughtfully developed) programming language that lets you write better code, faster. It’s great to see Kotlin continue to receive the sort of recognition as Breakout Project of the Year, building on other awards like #1 fastest growing language on Github.

We’re big fans of Kotlin, and we’ve heard that you are too – feedback from you is in part why we announced support for the language over two years ago. This meant bundling the Kotlin plugin in Android Studio, along with promising to support Kotlin-built apps going forward.

But there was a long way to go for many teams at Google to provide a first class experience with Kotlin in the Android ecosystem, and to convince developers that Kotlin on Android is not just a fad, but is here to stay.

If you haven’t tried Kotlin yet, now is a great time to start! In fact, in the past two years, we’ve been adding a number of new features and upgrades to the Kotlin for Android experience, including:

  • Android Jetpack APIs now have first class support for Kotlin Coroutines, transforming the way we do async operations on Android. This includes Room, LiveData, ViewModels, WorkManager and more coming in the future.

  • Many Jetpack libraries have Kotlin extension libraries (KTX) to make using them even more fluent with Kotlin.
  • The compilation toolchain has received many improvements for Kotlin, including compiler enhancements, incremental annotation processing with KAPT, and Kotlin-specific R8 optimizations.
  • All of our documentation pages now contain Kotlin code snippets, so you can easily compare how our APIs work in both languages.
Kotlin code snippet
  • Most of our flagship samples are also written in Kotlin (including IOSched, Plaid, Sunflower and many more), along with any new samples that we make in the future.
  • We've added a language switcher to our API reference pages, so you can have a Kotlin view of the AndroidX library and the Android framework.
Kotlin view of the AndroidX library
  • We doubled down on providing guidance to developers and teams who want to switch to Kotlin on our developers.android.com/kotlin pages.
  • Our Developer Relations engineers are posting real life examples and guides on integrating Kotlin in your apps on our Medium publication, such as the great intro to Coroutines on Android series and many more.
  • If you prefer to learn Kotlin in person, you can join one of the many Kotlin/Everywhere events happening around the world. If you are an organizer in a local developer community, consider signing up to host your own event!
    This initiative is a cooperation between JetBrains and Google.
  • For those of you who don't have access to in-person training, we added a new, free course on Udacity for Developing Android apps in Kotlin. Our Kotlin Bootcamp for Programmers course is still available as well!
  • We have worked with many external partners to gather feedback and learn about their experiences with Kotlin, such as this case study with Square.
  • And lastly, we've enabled Kotlin as a supported language for Android app teams at Google. We're already seeing adoption in apps such as Google Home, Google Drive, Android System UI, Nest, with many more to follow.

The road to fully supporting Kotlin on Android was not always easy, but it was truly rewarding seeing Kotlin adoption among professional Android developers rise from a handful of early adopters to around 50% since the original announcement!

We were confident when we announced earlier this year at Google I/O 2019 that Android is going increasingly Kotlin-first, opening up the possibility for APIs built specifically around Kotlin and for Kotlin users, starting with the new, declarative UI toolkit - Jetpack Compose (still in early development).

We want to congratulate JetBrains, our partners through the Kotlin Foundation and creators of Kotlin, on receiving the OSCON Open Source Award today. It shows how disruptive and transformative Kotlin has been, and not just for the Android developer community, but beyond.

We know one thing: on Android, Kotlin is here to stay.