Android dev history romain guy chet haase header

Android: A Developer's History


[Romain Guy] We’re going to go over the history of Android, talk about every version, and give you a few anecdotes about every one. Some will be funny, some will be scary, and hopefully they will all be entertaining.


[RG] We’ll start with the prehistory, everything before Android 1.0.

As of last week, I have been at Google for exactly 10 years… Thank you for the two who think that’s a good thing. Everybody else is like, “Jesus, can he leave?”

Android had been acquired by Google in 2005. I joined in 2007, first as an intern, and then as a full time employee. Android was a secret project internally. A lot of people kept asking us, “What is it you guys do over there? What is that Android project?” Our first public release was in November 2007. It’s interesting how it was announced.

m3 – First public release

[Chet Haase] On November 5th, we announced that there was this Open Handset Alliance. We had a conglomeration of partners out there. We were gonna do things. They were gonna do things. There was gonna be code and sharing. There was gonna be this great business opportunity.

[RG] Usually it’s what you announce when you do not have code or you don’t have anything.

[CH] There were skeptical responses from top people at various organizations. Here’s a quote from Steve Ballmer, on November 8th:

“Their efforts are just some words on paper. Right now they have a press release. We have many, many millions of customers, great software, many hardware devices.”

All true. And then, 2 days later, the Android SDK was released!


[RG] This is what Android looked like back then. That device was called a Sooner. That was probably a horrible pun about shipping something Sooner rather than later.

[CH] It should’ve been called the Never.

[RG] I think that was based on an existing HTC phone that was running Windows Mobile. That was just a development device while we were waiting for the real hardware that we wanted to ship.

You can see what the UI looked like. We can call it a UI, you may not like it. What was nice about it was that the CPU was about 80 megahertz, you’re talking 32 megs of RAM, a pretty poor device, but the UI was so smooth. I still have one of those in the office, and there are a few lying around. From time to time we boot them and they’re still pretty fast and smooth.

[CH] It turns out you can have really good performance when there’s only 12 pixels to paint.

[RG] Well the resolution was actually 320x240. If we were to overlay a Sooner on top of a modern device like the Pixel XL, it would be bigger than an icon. Not by much, but it’s a little bigger. That gives you an idea of how far we’ve come. Some of the fundamentals were already there, for example, some of the buttons. We had the back button, the home button, the SurfaceFlinger, Binder, and Activities.

[CH] Notifications, intense! The animation system was there, specifically the animation system that I hate was there.

[RG] The old animation system, the crappy one. Then we had an update soon after. It was still using a hardware keyboard in the emulator. We did not want to tip our hand that we were working on the touchscreen. The underlying software was ready for touch.

m5 – Window shade

[RG] Then came release M5 in February, 2008. We had a brand new UI and that was the introduction of the window shade. Also, to give you a better idea of the cadence of our releases, we have a timeline. The first blue dot here is Android M3, every minor release is a yellow dot, and the green dots are major releases. Some of them are really close together. We’re going to go all the way to Oreo at the end.

[RG] M5 had the window shade, very similar to what we have today. It had notifications. The first four icons at the top of the home screen are the “recents”; we didn’t have a recent button. You could not put shortcuts on the launcher itself. You only had the All Apps button that was just an app store.

0.9 – Launch imminent

In August, 2008, we were almost ready for launch. That was our public 0.9 release, and the UI looks a lot more like what we have today. You can see the shortcuts on the workspace, the bottom drawer. It almost looks like Gingerbread.

[CH] My favorite thing was a blur effect. You could pop up this scrim that would blur everything that you didn’t want the user’s attention focused on. It’s a nice way to focus on the foreground. That effect was removed after .9 and before 1.0 because it wasn’t clear that it was going to be supportable in general on all devices. It was replaced by the dim window, which just dims everything behind it.

[RG] The UI lacked a lot of refinements that I still remember 10 years later. We were drawing almost everything in the color mode called 565, so 16 bit per pixel instead of 32 bits. It introduced artifacts. It was bad and ugly, but we were saving memory. If you’re still using 565 we need to have a chat after this presentation. You can see in the screenshot other issues: for example, the shadow here is clipped, because apparently UX did not crop the assets properly. We were learning.

[CH] Assets are hard. Generally, large companies and organizations have UX designers doing things. Android was quite small. So if you wanted an asset for something, you’d need to get the attention of the UX person and they were probably busy doing other things.

[RG] And when he means the UX person he means the UX person.

[CH] It was probably a little bit easier for you to just figure it out on your own.

[RG] We introduced hardware acceleration in 3.0, but I was bored one day and I tried to implement hardware acceleration in Android 0.9. There was even an API to enable it in your application. We did not end up shipping with it, because we could not implement the whole Canvas API with OpenGL 1.0. We had to wait for OpenGL 2.0 to be able to do everything. So it was turned off. But two years later when I did hardware acceleration for real, I went onto our old code server, because between 0.9 and 3.0 we switched from Perforce to Git, so I had to go find that server somewhere at Google, find the Java file that contained all the hardware acceleration code, and use that as a basis for the new hardware acceleration code.

[CH] Copy paste, all done.

[RG] Not quite, not quite. It was a little more complicated than that. And I have proof here, some of the code.

[CH] It turns out that APIs are hard. There were some that were in .9, like PageTurner, which fortunately got removed before it went out.

[CH] That’s one of those things about developing a platform versus an application or a library where it’s a totally fine widget to have. The PageTurner widget solved a use case that you had, but adding it to the API for that one niche use case would introduce developer confusion over thousands of people.

[RG] But we left in a lot of things like that, for example the analog clock, because everybody needs an analog clock in their application!

Get more development news like this

[CH] We should’ve removed AbsoluteLayout. Who’s using AbsoluteLayout now? [Some audience members raise their hands]

[RG] Come see me after the talk.

[CH] It is certainly the easiest layout to use because it’s not a layout. It’s not doing anything. That works well when you only have one device and one form factor in the world. It broke down with Android really quickly. That got deprecated in 1.5.

[RG] And it was only deprecated because WebView extended and still extends AbsoluteLayout.

[RG] Again, APIs are hard. There were a few things we got right. We had layouts. We had DIPs or DPs for resolution dependence. It made the apps a little more complicated to write at first, but everybody would agree today that it’s nice that we’ve had that since the beginning.

The Early Years

1.0 – Android has arrived

[RG] About a month after 0.9 we reached Android 1.0 in September 2008. Our first phone was the T-Mobile G1. That device had 192 megs of RAM. The system image was about 64 megabytes. Today, the system image is about three to four gigabytes. We’ve been writing a lot of code since then. We had a touchscreen, we had a GPS, gyroscope, GPU. The only way to go to landscape was to reveal the keyboard. It had a nice click to it. I still like to play with that device from time to time. We were really constrained on memory. When you have 192 megs of RAM, some of it is reserved for the radio so you can make phone calls, some is reserved for the kernel, etc. The user space only had about 48 megabytes. Shortly before we shipped, one of the engineers, Bryan, found 32 megabytes just laying around. He had been hiding them because he was worried that we would just use too much RAM. That was probably a good idea. We also had all the fundamentals that we know today - the lock patterns on the lock screen, the density independence, multitasking, notifications, save state, window shade, everything was there. I don’t know what we’ve been doing since then really!

[CH] Shh, don’t tell anyone! So, we actually had Android Market, an early version of Play Store. You could buy applications … for free. We knew how to allow you to download and install applications. We didn’t quite know how to charge for them yet. So, it’s called Market, but it’s not really much of a market.

[RG] Whenever you tried to install an application, we would already show you the permissions that the application was requesting. We had the comments and the rating system. Market hasn’t changed that much. We just redo the UI all the time. Just shortly after the public release in October we released the source code itself - the entire source code of the entire OS - and we had system images so that people could flash their device, build the OSP, make changes, and contribute. And we’ve done that for every release except one.

[CH] Yeah, certainly one of the most distinguishing elements of the Android platform is all the code is open source so that everybody can figure out what’s going on.

[RG] As an engineer, having the source code out there was a little scary because people would use it to do things. At the CES show in Las Vegas every year, people would show Android running in an oven, or in a car, or going to space. I’d think - I know the code! I wrote some of it. Please don’t do that.

[CH] Ever been on one of those flights with the TV in front of you and you sort of touch it wrong and the navigation bar pops up at the bottom? You’re thinking, “Oh, it’s running an Android tablet. Is the cockpit running on this, as well? Or is it just the entertainment system?” We’ll never know.

1.1 – First Android update

[RG] A few months later, we had the first Android update, Android 1.1. We called it Petit Four. The name comes from the fact that it was supposed to be just a small update with a few bug fixes and features. We added voice search. We also introduced paid applications on the Market. You could finally buy something. And that was our first system update.

1.5 Cupcake – The first named release

[RG] Two months later was another release. We were pretty busy back then and stressed out. 1.5 was our first named release. It was called Cupcake. So, why is it called C? Internally, we had two releases called Astro Boy and Bender after famous robots. For many reasons, partly also because it’s hard to find a robot name for every letter of the alphabet, we stopped choosing robot names and we went to desserts, and I think that came from the Petit Four update. And there was also the introduction of our first touch only device. We had the IME, the first software keyboard. We had auto rotation based on a sensor, and you didn’t have to open the screen anymore. Interestingly, at Google, we’ve shipped a lot of messaging applications over the years, and we still do. In Android 1.0 we had four messaging applications. There was Email, Gmail, Messaging, which was SMS, and there was one called IM, which was doing AIM, Windows Live Messenger, Yahoo Messenger, and GTalk or whatever it was called back then. Then in Android 1.5 we added a fifth messaging application. We took GTalk out of the IM application and created its own app. Android loves messaging applications.

[CH] Marketing people will tell you that a successful product is always based on good messaging, and we took it a little too literally.

[RG] My theory is that we were doing that so that our managers could reach us at any time of the week so that we could fix bugs. It would be 10 p.m. Sunday night, and you’d look at your phone and see a notification that reads “YT?” from your boss and you’d think “Oh crap, what does he want now?”

[CH] Also, Maps appears on Market, the first unbundled application. Now, this is basically the model. There are just a few applications that actually ship with the release with the system image, for example the calculator. I think even Dialer is partially unbundled. Most of the stuff is independent. They’re on their own release trains. They have their own teams outside of Android.

1.6 Donut – New networks and screen sizes

[RG] Then we reach a very interesting release, Android 1.6 or Donut. The main improvements were the addition of support for CDMA, which was the type of network that Verizon was using back then. That was a big deal, because Verizon meant a lot of customers. We finished the support for resolution independence. So we had support for multiple screen sizes with our layouts, but the resolution dependence with the DIP and DPs was mostly there, not quite finished yet, and you’ll see why it was important that we landed it in Donut. We had text to speech. And it was a very small update in many ways, but you can see that it was already five months after Cupcake. We did not go on vacation. We did not stop working.

2.0 Eclair – High density and droids

[RG] 2.0 came one month after 1.6. We were actually doing both 2.0 and 1.6 at the same time. I often joke that it’s called And-Droid not Or-Droid. We do multiple things. That was a lot of work to do two releases at the same time, but we’ve done it several times. Like Gingerbread happened pretty much during Honeycomb. The big new features for 2.0 were our first HDPI device, high density, and the Verizon Droid, which helped Android really take off. And yeah, so 2.0 actually was done before we shipped 1.6, which makes no sense at all. That’s when we also introduced turn by turn navigation in Google Maps, which is still to this day one of the best features.

2.1 – Nexus devices

[CH] Nexus started making these devices. So the nice thing about making devices is it gives you a way to actually prove that you’re doing the right thing. The purpose of the Nexus program was to create a decent phone, but more importantly to create a reference device that allowed us to prove out all these new features.

[RG] Nexus One was interesting. We still had the trackball. We were already moving towards soft buttons, so the back, recent menu, all that stuff, were not true hardware buttons but were capacitive buttons that still could not be removed. They were not part of the screen, but we were moving in that direction. Another big change in 2.1 was the introduction of live wallpapers. They were implemented using RenderScript, which was a hidden API back then. I think I was the first user of RenderScript, so I wrote most of those first live wallpapers. And here’s one of the reasons why we didn’t ship RenderScript in that version. When you had a syntax error, let’s say you have a script of 2,000 lines of RenderScript and there’s a syntax error somewhere, the error message logcat was a dump of the CPU registers, and that’s all you had. I had long nights. Live wallpapers arrived fairly late in the release process. One day, Andy Rubin showed up in my office and he asked Diane and Joe Norito and myself to come up with 10 live wallpapers. Oh and by the way, here’s a live wallpaper, figure out an API and ship it! By the way, we’re shipping in five weeks! I was the UX for those live wallpapers, so sorry about that.

[CH] The other part of getting the project done was that somebody decided that they would put a product manager (PM) on the project, because this is really important. We need somebody to make sure that it actually ships. So, the first thing the PM did was to set up a daily half-hour meeting with Romain to ask the status of the feature, which was the last meeting that he had with Romain I believe.

[RG] We also saw the introduction of the 3D gallery and the 3D launcher. So, the all apps screen was mapped onto a wheel, like a semi-cylindrical object.

2.2 Froyo – Going faster

[RG] That was the introduction of the JIT in Dalvik. Until now our virtual machine was fully interpreted, and it was really fast for an interpreted virtual machine. We had a few really smart folks writing a ton of highly optimized C code or even assembly code to make it run well, but it was nice when we got the JIT.

[CH] Also, more importantly, this device had Flash on it. I was working at Adobe at the time on the Flash platform, so that was pretty cool. Obviously, that’s the future of the web.

[RG] There was also an introduction of V8, the JavaScript VM in our web browser, and we had a Twitter application.

[CH] In November of 2007, meanwhile, Microsoft launched Windows Phone 7. Alright. On to Android 2.3!

2.3 Gingerbread – Too good to die

[RG] I mentioned this earlier, 2.3 is a release that we built while we were doing Honeycomb. It was meant to be mostly a refresher of the UI to something more modern. It was also released. It took a long, long time to die, because it was too good. It didn’t need too much RAM to run. It could run on fairly underpowered phones, so it stuck around for a long time even though a lot of you probably suffered from that. I don’t know if I should be sorry about that - sorry we did a good job? I’m not sure.

[CH] Assets are hard.

[RG] Yeah, assets are hard. That’s also when I was so mad at all those applications still using 565, that I made 888 the default format for bitmaps. I still get people mad at me for that. But, I think that was the right call. The UI was a lot nicer than before.

[CH] We had the original overscroll effects, which have gone through various contortions over the years now. It became this sort of circular thing, which it still is, with tweaks. The trick as an engineering organization working with the design department is to give them little hooks into the system occasionally that they can think about while you go on and think about everything else. And then they’ll say, “Hey, it’s really important that we update this overscroll effect.” You’re like, “You’re right.” And then you update that and then you go back to the rest of the thing you’re doing. So, overscroll is one of those. They like to revisit that occasionally. It makes them happy.

3.0 Honeycomb – Sleepy Holo

[RG] And then we entered Limbo, the famous Honeycomb release that was never released in the OSP.

[CH] We went dark for a while. So, this is when I got here. I worked on Honeycomb from the time that I arrived in about May of 2011. Meanwhile, the rest of the team was still working on Gingerbread for quite some time. So, they were trying to ship that and I was working on basically the new animation system and property system in Honeycomb. We did Holo, new look and feel. I think it’s the beginning of consistency for Android UIs. They always had a certain flavor to them, but there were various inconsistencies between the apps and the system UI and exactly how it was implemented in all these different places. Holo is the first attempt to have a system wide consistency.

[RG] It had personality. It used to have those blue glows everywhere. To me it always looked like if you took a Smurf and splashed it on the screen and then smeared it, that’s what it would look like.

[CH] Speaking of smearing, who owned the Zoom tablet?

[CH] Wow! Sorry?

[RG] Whoa! We have fans. The Zoom did not have hardware buttons - these were our first software buttons and new nav bar. We experimented. The UX team did a lot of awesome experiments in Honeycomb and we’ve kept most of them. You can already see some of the ideas behind material design, like with Cards. That was a 720p display, and our biggest issue when we got that hardware is that there was no way we could draw our UI at 60 frames per second in software. So, that’s when we did hardware acceleration for the entire UI. That kept Chet and me quite busy for a few months. I originally had three months to do the whole hardware acceleration. That’s okay, because I didn’t know OpenGL at all, so that gave me plenty of time to learn. We introduced Chet’s new animation APIs for the property animators. We had a tablet UI, so there’s two column modes. We added the Action bar for the first time. RenderScript became a public API.

[CH] And I think that my favorite part about that release was actually the Zoom tablet because it gave what I like to call hardware assisted motion blur. It took so long for the pixels to decay that you could actually see things smear across the screen as they moved around.

[RG] Actually, it’s worse than that. I was working really hard on that hardware acceleration pipeline. We were trying to reach 60 FPS and we could just not get there. And every time I tried to profile the code, the profiler said, “Yep, you’ve got 60 frames per second. You’re fine.” But, that’s not what I was seeing on screen. Then one day, I don’t know why, I hooked up the Zoom to a TV because it had an HDMI out, and on the TV it was 60 frames per second! So we called Motorola and said, “Hey, the refresh rate of the screen, what’s up?” It turned out to be what Chet mentioned. The screen could refresh at most 25 frames per second. It’s 25 smeared frames. It’s not even a number. It’s like a complex number or something!


[RG] We also saw the introduction of Fragments[dramatic pause, laughter from audience]. And hardware acceleration, like we said: android:hardwareAccelerated="true" [more laughter from audience]. Here’s the big change we made for hardware acceleration. The Canvas API on Android is what we call an “immediate mode” API. When you call drawLine, it draws a line immediately on screen. The first version of hardware acceleration worked exactly like that. Unfortunately, that is not the most efficient way to do things on the GPU. But we didn’t have much time, so we couldn’t really do what’s called deferred rendering.

And about two months before the release, our boss’s boss, someone higher up, came to us and said, “Hey, don’t you have an idea about how we could make things even faster and smoother?” We said, “Yeah, we could go to deferred rendering mode. That gets really scary, though, because it could break applications. It’s crazy.” He said, “You’re right. We ship in two months. Let’s not do that.” Then he came back to us two weeks before we were going to ship and said, “So, that idea of yours. Yep.” And that’s what we spent the last two weeks of the release doing. That was really stressful. I remember making changes six hours before going to the factory. That’s fine. We don’t do that anymore. Android is serious now. We have tests!

[CH] I had come from development departments where we would lock down essentially six to nine months before, and then ship increasingly critical bugs as we got closer to release, and then you’re basically just going through quality cycle so that you know that it’s robust by the time it goes out. And then I land on Android and within the first year we’re checking in code like this hours before we’re cutting the release. And it worked! It’s fine.

[RG] Versions 3.1 and 3.2 are refinements to Honeycomb. We added the screenshots in the list of recents. You can see the dead Smurfs here, those blue glows… We had the resizable widgets, introduction of one of my most favorite APIs ever, the ViewPropertyAnimator, thanks to Chet.

Support Library

[CH] And stunning, Support Library, because Fragments! [audience laughs] At the beginning, and over the early course of its life, Support Library was basically this thing that we did. “Oh, did they want that functionality? Okay, yeah, we’ll put that there. And then we’ll add some app compat stuff. And then maybe we can put that utility thing over there.” And then all of a sudden all this stuff started getting tossed into Support Library until we’re at a point in Support Library’s life where not even the name makes sense anymore! We call it Support Library, but it’s not a library. It’s a large series of libraries, plural. So, how do you make sense out of this thing? And the problem was that it grew so organically, you know, “We’ll just do this thing that people want,” and then this turns out to be the critical path for most developers. Everybody, I believe, is or should be using Support Library at least to support the compatibility use case, unless you also want the myriad of other things in there like RecyclerView and all the rest of the stuff that we’re doing there. Well, we finished the Honeycomb release, and did we release the codes? No.

[RG] I have seen so many conspiracy theories about that online. The main reason is it was a huge endeavor to implement that brand new UI, to go to tablets, to hardware acceleration, and fragments, and rethink almost every single application. We just didn’t have time both on the UX side and the rendering side to implement the phone UI. Contrary to what I’ve read, there was no hack to the code. There was nothing like, “do this if I’m a tablet, do that if I’m a phone.” No, the code was fine. We just didn’t have a UX for phones. So, we didn’t want to release it to the world and have weird versions of Android with a broken UI running on random phones. So, that’s why we held onto the release of the source code, until the release after that.

The Modern Era

And that’s when we entered what we call the modern era, the premises of natural design, effectively. So, Holo came to phones at the end of 2011. On the slide, you can see that small bar is the number of Android active devices… We had about 190 million users at the time.

4.0 Ice Cream Sandwich - Holo comes to phones

[RG] Version 4, Ice Cream Sandwich, ICS, introduced support for NFC sharing, beaming, that kind of stuff. The UI was refined. And as with the tablets, we wanted consistency. We have a very consistent UI on the phones now.

[CH] You can see that the clock tends to change every release. You’ll notice little changes to the font or the style. This is one of them.

[RG] Clocks and weather - those are the two most important things in an OS apparently.

[CH] So, we did the UI. We did the phone stuff. We qualified that the platform would actually work on phones with ICS, so now we released the source code and we’re back in action.

Google Play

Google Play made things more consistent. We used to have a bunch of apps out there that were the content that you could get from Google, and we just brought it altogether into the “Play” moniker, sort of collected these things together intelligently.

[RG] None of those apps appeared for the tablet because a tablet is great to consume content, so that’s when we introduced [Play] Books and Video and maybe Music I believe. I don’t remember. android-dev-history-google-play-mar-2012

4.1 Jelly Bean – Project butter

[CH] We’d been adding a lot of capabilities, and were running on pretty good hardware, but we had gotten to a point where jank was fairly prevalent depending on the device that you were at and the things that you were trying to do. So, we took a big step back and worked specifically in two areas of improving jank. One was input latency and the other was hardware acceleration improvements.

[RG] I believe it’s in 4.1 that hardware acceleration became on by default for apps.

[CH] Before that, it was opt-in. Google apps like the launcher and the home screen were opted in already. But now all of your applications got opted in automatically.

[RG] And we shipped Jelly Bean on one of my favorite devices ever, the Nexus 7. Nexus 7 2nd Generation was even better, but that was a great device. We added a lot of features. There was the introduction of Google Now. “Market” became the Play Store. We had support for x86 in the emulator, so it was a lot faster to use. I believe that’s also when we introduced tools like Profile GPU Rendering on-screen. We really wanted to help developers figure it out. And back to the original days of Android, the introduction of bi-directional text, right to left.

[CH] Not the layouts yet, just the text. One step at a time. Can’t fix everything. Turns out to be a hard problem to solve.

4.2 – 2560x1600 and right to left layouts

[RG] 4.2 was also called Jelly Bean. That brought the introduction of the Nexus 10, another tablet, which had massive resolution, it was 2560 x 1600, which is a little more than what we get on the Pixel XL today, except back then the hardware was not as good as what we have today, so that was a huge challenge. The bandwidth requirements were huge, and even hardware acceleration had problems coping with the demands of the device. It shipped with really good performance, although things got slower in portrait mode due to certain limitations.

[CH] In right to left, now layouts work. We do the right thing for other languages finally.

[CH] Who filed a bug about the clock in MR2? It turns out that it was intentional. Many people said, “Something went wrong with this font. You obviously didn’t mean to bold just the hour, because who would do that?” android-dev-history-bold-move-not-a-bug

[RG] That was my reaction working on the text renderer. I thought there was something wrong with the renderer. Nope.

[CH] Just something wrong with the design specification, that’s all. The Quick Settings feature has gone through several contortions. When I first saw this, I sent a note to Dan Sandler who runs the system UI team. I said, “I love the new Quick Settings thing, but I would like to drag these things around because I have a different priority order, and edit an item and get rid of the items that I no longer use.” And it turns out that’s exactly the way that it worked internally, but we only expose that functionality in O.

[CH] So very recently. It was actually in there way, way back then, and you could run a system utility that would allow you to do it, but that was very hidden.

Android Studio

[RG] Android Studio was introduced at Google I/O in 2013. We were deprecating Eclipse. Who’s still using Eclipse? Don’t be shy, that’s okay. I might disagree, but that’s okay. Eclipse is still good. Obviously, Android Studio is where all our tooling goes nowadays. We kept working on Project Butter. We introduced OpenGL 3.0 and wearables.

4.4 KitKat – Project svelte

[CH] Up to 750 million devices out there were activated. We’re up to KitKat. Project Svelte was about slimming things down. A lot of users and manufacturers were stopping at Gingerbread because these devices did not have the resources capable of running all the stuff that we’d added to it since then. So, we took a step back and reduced a lot of it, so that people could actually adopt newer releases on much more limited devices.

[RG] It’s pretty awesome the kind of bugs you find when you look at pieces of code that you think have been stable for years. I remember that every time the WiFi transfer indicator would toggle, all the icons would reinflate, including the ones in the quick settings that you don’t see. That was overkill. Also, there’s a blinking cursor for the password input on your lock screen. When the screen is off, the text field would be redrawn every time the cursor blinks! It turns out when you fix a lot of those little things it adds up.


[CH] One of the great new things in KitKat was not obvious to users or most developers - now we had ART. Finally Dalvik with a JIT came out a few releases ago. ART was basically a rewrite from the ground up of a much more optimized and optimizable runtime, both for GC and pure performance. Dalvik had really hit the wall. It was designed for different constraints, and there was only so much optimization that we could crank out of it. So, they wrote this new thing called ART, but it was off by default so that people could actually test it a bit before we forced it upon the world. That was nice. Another nice thing was that we fixed the bold hour bug.

[RG] One of the optimizations we’ve done for this release is called batching and merging. In the rendering pipeline, since we record all the commands through deferred rendering, now what we do is that we group them and we sort them. So even when you have an app like Settings, with 30 text views, and a bunch of checkboxes, and list dividers, we can actually group all those commands and render the whole screen in about five or six draw calls, whereas it used to take many more. So, that’s much more efficient for the GPU.

[CH] Also great for implementing blink tag effects.

[RG] Yeah. Well, there’s a blink tag, but that’s from Android 1 I think. I put it in. It’s a secret tag. Who knows about the blink tag? Just a few people. So yeah, in the layout you can just add a blink tag and any view you put inside will blink.

[CH] Why did you tell them that?

[RG] Who knows? It might be useful. Don’t use it. It’s not documented, so technically it’s a private API. Okay, that’s another optimization we’ve done for Svelte to reduce memory usage. Every app had to load assets from the framework, for example, the checkboxes, the stars, the progress bar, the overscroll effect. You can see this huge dead Smurf that was taking a lot of memory.

[CH] You see the progress bar thing at the top? As progress is going, it’s that break in the line that goes left to right as time increases. It’s a nice effect. Back in some earlier release, Romain finally noticed that you’d see it jump occasionally, and you’d just think something went really fast. But actually, some of the assets were out of order.

[RG] I noticed in that release, because I was working on the code to create that atlas of images. If you look at the bars up there on the slide, you can see that one or two are missing in the animation sequence. I chased that bug in my code for so long. Then I realized - those images do not exist! Anyway, instead of loading all those assets in every single process, we have this atlas that’s built at startup for your device. It’s optimized for your device, and we share it between all the apps. So, that saves about a megabyte or two megabytes per process that’s live on the device. So, it’s the kind of optimizations we’ve done all over the place in the system to be able to fit in 512 megs of RAM again.

[CH] More good Support Library stuff. We started adding more fundamental widgets to Support Library. We realized we could build widgets that people want to use that don’t need to live in the framework and therefore aren’t beholden to developers updating or users updating to that new release to get those bug fixes or functionality. Instead, developers can adopt this wholesale and use it everywhere. So, RecyclerView is the first great example of that.

[RG] This came out in 2014, and I think the first time we started talking about it was in 2008. It took us a while.

[CH] Complicated widget.

[RG] Some things for the animation standard that were shipped in Honeycomb are things that I wanted to do when I joined Google. It just took me to hire you [Chet] to make it happen.

[CH] The first thing I worked on when I got to Google was to fix his bug that he had filed four years before!

[RG] In 2007.

5.0 Lollipop – Material Design

[CH] Yeah. So, here we are in Lollipop. We get material design, a nice consistent thing. It’s even more consistent now that there’s a whole design system around it, this idea of ink and layers of paper.

[RG] And one billion users.

[CH] At the time I worked on the UI toolkit team. Our job for that release was to basically listen to design teams and interpret what they meant. So, they would sort of wave their hands and they would talk about ink and paper and the importance of real-time soft shadows, and good performance, and blah, blah, blah. And we’d go, “Okay, I heard all these words and here is what we can do for you.” And then it was a process of iteration between what it is they were looking for, and what we could do on the limited devices that we had.

[CH] Lollipop was the first time that we released the release before it was actually done, so we did developer preview for the first time. We said, “Here it is. Here are the APIs. Here’s the documentation. You can start playing with this stuff.”

[RG] And finally, after years of seeing people put Android in places where it should not be, we did it ourselves. So, we did the API for Android TV and Android Auto. So now to get back to the topic of UX. One thing that UX really wanted was soft shadows everywhere. And they would show you those beautiful renders that would take 30 seconds on the Mac Pro or in After Effects or something, and of course they wanted them at 60 FPS on a phone.

[CH] “We just want this but 1800 times faster.”

[RG] To be fair, that wasn’t new. They were doing that for Android 1. They wanted motion blur in the original launcher version where you could pan across multiple screens. The conversation would go: “How long did it take to render in After Effects?” “Uh, a few minutes.” “Alright, you want it real time. I’ll get right on it.” It looked nice. When I prototyped the first version of shadows, I did fully ray-traced soft shadows, because UX wanted area lights that could change size and position. They looked beautiful and were physically correct! I took photos of actual shadows to make sure. And they ran very smoothly until the device would reboot because it was too hot. So we figured maybe the device should stay alive for more than two minutes at a time. Maybe we should not ship it this way. android-dev-history-ray-tracing-shadows

6.0 Marshmallow – Permissions

[CH] Permissions, and 1.4 billion devices out there.

[RG] And you can see from the timeline, that’s when we started to have a more consistent cadence for releases, about once a year, when it used to be whenever.

[CH] Yeah, it’s pretty regular now. So, now we’re in the M release. Runtime permissions was the big change. We’ve got JobScheduler. I think that came along in KitKat. But we’ve also got GCMNetworkManager.

[RG] Software performance, and memory - it was about battery life.

[CH] Yes. In the more recent releases there are these initiatives where there will be a long-standing or large issue that we need to solve that is across device and platform and apps. So, we’ll make targeted efforts to do that - like the battery issue, the background processing, whatever it is.

7.0 Nougat – Multi-window, Vulkan and VR

[CH] Multi-window support was introduced.

[RG] That was last year.

[CH] Yes, very recent. Multi-window was one of those instances where a lot of work went into making some of the underlying bits work, but for the most part, applications just worked, because it used the fundamentals of the way our layout and redrawing system works already. So, if the screen is being resized there, well, we know how to do re-layouts to different form factors, and your applications do too, because they’re not using AbsoluteLayout, right? Okay. So, it was one of those nice things where it just comes together, and things work the way that they should.

Vulkan came along as a system. There is a driver in there that enables some faster games and low level acceleration. VR was a thing, and A/B updates from Play Store.

[RG] Android has matured. It used to be that we had huge foundation changes all the way into the 4.X series… Like bolding the clock! But, now we have solid engineering and UX foundations with material design, so our releases are more refined. So we have a lot of new features, but we don’t have those huge changes that we used to have. Except, of course, this year, with Daydream.

8.0 Oreo – Here comes Treble!

The big change in 8.0, Oreo, is Treble. That’s a huge internal change that should/will allow the OS to update the framework or allow other companies to update the system without having to change the drivers at the same time. So, a lot of engineering time on O was was spent working on that.

[CH] Here’s some random stuff that we did in this release. We did a bunch of interesting text features, things like EmojiCompat. So now we can actually update the emojis and stay current a lot easier than simply updating the platform releases year after year. We added fonts in XML and some other font updates. We had adaptive icons for launchers, as well as other notification improvements, like notification channels, and Romain’s favorite feature [slide shows blinking text]…

[RG] You don’t like me. That is not nice.

[CH] Lots of stuff was going on in the Support Library in the meantime. ConstraintLayout came out.

[RG] And Nicolas Roard is somewhere all the way in the back. You can talk to him about it.

[CH] You owe me 10 bucks. I mentioned your feature. We did the first major refactor in the Support Library. We actually upped the minSDK. We used to handle everything back to Donut. We also split up the v4 package so you could be more modular and only pull in the things that you actually needed instead of pulling in everything. We introduced some new widgets and did some performance improvements for RecyclerView with prefetch. And, we did the first step towards physics based animation. We upped the minSDK again this year to 14, so Gingerbread and Honeycomb are gone. The rest of the physics based animation stuff came in, and all the text stuff that was on the platform then came into the Support Library. So, what is next? Everybody of course wants to know what we’re working on next. And, we’re not going to tell you!


[Audience Member] I was wondering about this - you didn’t mention the up/back button, sometimes it takes you up, instead of back.

[CH] Oh, up versus back. Yeah, nobody is confused about that at all.

[RG] If someone wants to come explain to me how those things work.

[CH] It’s a thing, yeah. I do think it’s an important paradigm. Sometimes you want to go up the stack in what you were doing and sometimes you’re gonna go back. It’s important, how did that application developer decide to implement that? Did they actually create the correct back stack when they went into that deep link? That ends up causing a lot of problems. Sometimes you’ll be deep and you’ll go back and the application will go away, and that’s probably not what you were looking for, right?

[Audience Member] I have some coworkers who are taking Android training, and they’re learning about Fragments and they’re all excited. As someone who’s been developing a long time, I don’t use Fragments anymore. Would you advise people to stay away from them or not?

[RG] Fragments are just a tool that we give you. You don’t have to use them, but you can use them. We know there are some developers who are already happy with them, some developers like Fabio in the back who’s making signs that he should not be making. We don’t like them, but we’re not telling you to do it one way or another. It’s just a tool. If you’re okay with it then use it by all means.

[CH] I would say in their defense, there were some fundamental issues that got resolved over the last couple years. People took a pretty good run at fixing some of the harder to use things about Fragments, fixing bugs as well as APIs and use cases. And also there’s been a couple of pretty good talks by Adam and George in the last couple of Android Dev Summit and Google I/Os you should check out that give a good explanation of how some of this stuff works or should work in your application. So, I do think it’s easier and better to use them now than it was when they were first introduced and there were very brittle edges there. Yep, thank you.

[CH] There’s a question from the audience, “Can you tell us about transporting goats?”

[RG] I can tell you about it, but here’s another story. If you look in the sensor APIs - I think they might have been removed recently - we need to know the gravity and the mass of things. The developer put in the gravity on the island from Lost, and we also have the mass of the Death Star. It’s actually the second Death Star, because we couldn’t find the size of the first one. We did compute the mass of that thing, so it should be accurate. If Android is still there a long, long time ago when the rebels need it then it should work.

[CH] I think the one you were referring to is probably the isUserAGoat method.

[RG] A lot of people in Android have been doing operating systems for a long time. They came from BOS and Palm OS and Danger. One of those had an API that was called isComputerOnFire. It was actually documented to return true if the computer is on fire. I don’t remember why. So, isUserAGoat is one of those, and we have a bunch. We have isUserAMonkey. That was the first one I think, but that one was actually about the Monkey tool. And people thought that was a joke, but it’s actually a real API. We have this tool called the Monkey that simulates what would happen if you gave your phone to a bunch of monkeys. They just start banging on the screen and on the keys and that tends to trigger bugs in the implementation. Who knew? And sometimes the best workaround is to ask “Well is the user a monkey?” If not then do something else. Look, when you get a bug and you realize that to recreate the bug you have to press the Menu Holo button, open the screen and push Shift while you’re scrolling a list in less than 100 milliseconds, is it really worth fixing? If you’re that fast, I want to talk to you.

Next Up: Android Architecture #6: Fragments: The Solution to All of Android's Problems

General link arrow white

About the content

This content has been published here with the express permission of the author.

Romain Guy

Romain is an engineer at Google. He worked on the Android Framework team from Android 1.0 to 5.0 before joining the world of Robotics. He is now back to Android, working on new UI and graphics related projects.

Chet Haase

Chet is also an engineer at Google. He is the lead of the Android UI Toolkit team, where he works on animation, graphics, UI widgets, and anything else that helps create better Android user interfaces. He’s also been known to write and perform comedy.

4 design patterns for a RESTless mobile integration »