Android Oreo Greatly Reduced Lock Screen Unlocking Latency

We may earn a commission for purchases made using our links.

What people may perceive we can call “jank” or lag on an Android device can be explained in various ways. While most people focus on the smoothness and speed of a device when describing real-world performance, large delays and latency issues when performing animations can also produce visual annoyances and jarring breaks in responsiveness that contribute to our perception of a device’s lack of fluidity. The lock screen latency we (might) perceive when we unlock an Android device, for example, can make unlocking your phone quite jarring — but it should be going away with Android Oreo.

According to a new commit in AOSP, recent changes have caused this issue for a couple of different reasons. The commit author says that when we go from the lock screen to an application, Android now has to create a full starting window containing the snapshot. Before those recent changes were implemented, the Android OS was just showing a surface.

Also, when going from the lock screen to the home screen, Android can’t use the saved surface anymore (because it currently doesn’t support snapshotting translucent activities). The commit also mentions that in the long run, they want the home screen to be more involved into transitions. This means the operating system will have to wait for the first frame draw anyway. Googler Jorim Jaggi added additional latency in this transition 3 years ago, stating that he didn’t understand how to read systraces with binders involved at the time, though he rightly blamed that there was no available binder tracing then.

Now, though, they’ve been able to completely fix the latencies that all of the above introduced. By removing the wasteful 100ms latency, and they’ve made unlocking 30ms to 70ms better than before. The commit does warn that this requires “a lot more discipline” in SystemUI; the callback to dismiss Keyguard (portion that handles lockscreen unlocking) takes around 30ms, but by moving all non-essential binder calls they’ve managed to bring it down to just 5ms, allowing the window animation and Keyguard animation to start at about the same time.