If you watch All About Android on on the TWiT network on Tuesday nights, you may have caught this week's interview with three of Android's top executives. The panel included Dave Burke, Vice President of Engineering for Android; Stephanie Saad Cuthbertson, Group Product Manager for Android; and Sameer Samat, Vice President of Product management for Android and Google Play.

The trio gave a recap of Google I/O 2017, as well as a bit more context about some of the new technologies and announcements made during the keynote. For instance, much of the improvements made to Android O this time around are focused on making the platform stable for both developers and users alike. Here's how Cuthbertson explains it:

We really focused on three core things. First was the security program we talked about, Play Protect, which is a larger extent exposing many things we were doing already. In particular, the fact that we were scanning every app on every connected device to look for harmful apps. The second changes: Instead of OS optimizations that are fairly comprehensive, boot time is one of the big ones we talked about and you'll see that right away [in Android O]. We [also] made optimizations in the runtime and in the compilers. Apps will just run faster and more smoothly and that's because of a whole maelstrom of changes we made, like concurrent compacting garbage collection. All those changes…mean those apps you have are automatically going to run faster.

One theme remained particularly resonant throughout the interview and that's Google's attempt at mending Android's disjointed software update process. Before explaining how it plans to fix the process, however, Burke offered a colorful anecdote as to why it takes so long for software updates to get to you in the first place:

The right way to think about it is like a pipeline: We write all this code, and then we release it in open source and then the silicon vendors...take the Android code and then they do a lot of work on the code to optimize it for the silicone. The challenge today is that they actually end up changing not just low level code, but quite a lot of pieces of code. And then what happens is they hand that code to device makers, who then make more changes on top of it because they have a specific camera part they want to use, or a specific GPS or what not. Then it goes to carriers to test it, and then [emphasis added] it goes out to users.

Thus, he continues, came the idea for Project Treble. Burke describes it as an interface that will help make it easier for device manufacturers to drop in code relevant to their hardware, without interfering with Android's existing APIs.

You can watch the interview in its entirety -- about 40 minutes -- to get the scoop, including how the idea of adding Kotin support in Android Studio came to be, and how Android Go will affect the current Android One program.