WEBVTT - Android Dumps Desserts 0:00:04.240 --> 0:00:07.240 Welcome to tech Stuff, a production of I Heart Radios, 0:00:07.320 --> 0:00:13.920 How Stuff Works. Hey there, and welcome to tech Stuff. 0:00:13.960 --> 0:00:16.960 I'm your host, Jonathan Strickland. I'm an executive producer with 0:00:17.000 --> 0:00:18.840 I Heart Radio and How Stuff Works and Love of 0:00:18.840 --> 0:00:22.239 all Things Tech. And in our last episode, I talked 0:00:22.239 --> 0:00:25.920 about the creation of Google Android leading up to the 0:00:25.960 --> 0:00:30.040 release of ice Cream Sandwich, also known as Android version 0:00:30.120 --> 0:00:32.680 four point Oh. But before I go any further with 0:00:32.760 --> 0:00:35.400 that story, I thought I might take some time to 0:00:35.440 --> 0:00:39.480 describe what an operating system actually does from a high level, 0:00:39.479 --> 0:00:42.080 since I kind of skipped over that in the last episode. 0:00:42.720 --> 0:00:44.280 But in my defense, I really wanted to get to 0:00:44.320 --> 0:00:48.680 the actual Android stuff, all right, So let's go from 0:00:48.880 --> 0:00:52.559 the most basic explanations here and work our way up 0:00:52.600 --> 0:00:56.680 from there. A computer is essentially a machine that, through 0:00:56.960 --> 0:01:01.160 processing tons of complex calculations in a short amount of time, 0:01:01.440 --> 0:01:05.080 can produce all sorts of different end results. Some of 0:01:05.080 --> 0:01:08.800 them can be pretty intuitive, like calculating a formula that's 0:01:08.800 --> 0:01:13.560 embedded in a spreadsheet program. That's very clearly a mathematical process. 0:01:13.600 --> 0:01:16.720 It's easy to understand. Some are a little less intuitive, 0:01:17.200 --> 0:01:20.080 like allowing you to make a video call to someone 0:01:20.120 --> 0:01:22.959 who's on the other side of the world. But ultimately, 0:01:23.000 --> 0:01:26.520 a computer is taking information in the forms of zeros 0:01:26.520 --> 0:01:30.000 and ones, and it is performing various operations on that 0:01:30.080 --> 0:01:32.480 data to get results, which are then fed back to 0:01:32.560 --> 0:01:35.800 you in some appropriate way, depending upon whatever it is 0:01:35.800 --> 0:01:37.960 you're trying to do, but you know you'll be able 0:01:38.000 --> 0:01:39.480 to see it in a way that makes sense to you, 0:01:39.560 --> 0:01:42.280 as opposed to just a different string of zeros and ones, 0:01:42.319 --> 0:01:46.400 which would be useless to us. We run programs on 0:01:46.440 --> 0:01:49.440 computers to get these results. So in the examples I've 0:01:49.440 --> 0:01:52.800 already mentioned, you would have some sort of spreadsheet program 0:01:52.800 --> 0:01:57.400 like Microsoft Excel, or some sort of video calling program 0:01:57.440 --> 0:02:01.160 like Skype. Microsoft has nothing to do with this episode, 0:02:01.160 --> 0:02:04.200 by the way, Obviously I'm talking about androids, so but 0:02:04.280 --> 0:02:06.840 that's just to give you an example of programs that 0:02:06.880 --> 0:02:10.960 exist on computers. These programs need to interface with the 0:02:11.040 --> 0:02:16.080 hardware that's actually doing all of those calculations and gathering 0:02:16.200 --> 0:02:20.480 that information. Now, in the old old days of computers, 0:02:20.840 --> 0:02:25.120 programmers would build their programs into the machines themselves. They 0:02:25.120 --> 0:02:28.600 would program on what we would call bare metal, and 0:02:28.760 --> 0:02:32.600 computers would only do very specific tasks. By the time 0:02:32.639 --> 0:02:36.520 we got to general programmable computers, we could run different 0:02:36.520 --> 0:02:40.480 programs on the same machines. Programmers would write these four 0:02:40.520 --> 0:02:44.800 specific computers, and the program instructions were essentially telling the 0:02:44.800 --> 0:02:47.600 hardware what to do. And this goes all the way 0:02:47.639 --> 0:02:51.800 from the era where you would actually physically unplug parts 0:02:52.080 --> 0:02:54.440 of the computer system and plug it into different parts, 0:02:55.000 --> 0:02:57.959 up to where you might program it in a series 0:02:58.000 --> 0:03:00.600 of punch cards that would be read by computer, and 0:03:00.639 --> 0:03:03.760 then the computer would follow whatever the instructions were that 0:03:03.800 --> 0:03:07.480 the punch cards indicated. These are all various examples of 0:03:07.560 --> 0:03:12.120 programs and computers, but as computers and programs evolved, it 0:03:12.200 --> 0:03:15.640 became necessary to create some sort of liaison between the 0:03:15.680 --> 0:03:20.200 bare metal of the hardware underneath and the programs that 0:03:20.240 --> 0:03:22.720 would run on top of it. And the operating system 0:03:22.800 --> 0:03:26.359 is kind of like a foreman or a supervisor. It's 0:03:26.360 --> 0:03:30.040 in charge of managing stuff like computer memory and the 0:03:30.160 --> 0:03:33.600 order of operations, and with modern computer devices that also 0:03:33.680 --> 0:03:37.400 handles stuff like multitasking, making sure each instance of a 0:03:37.480 --> 0:03:40.600 program has the resources it needs to run, or in 0:03:40.640 --> 0:03:43.760 some cases even throttling those resources that are going to 0:03:43.800 --> 0:03:46.440 a program that might be in the background while another 0:03:46.440 --> 0:03:50.240 program is taking center stage. It's sort of dynamically managing 0:03:50.280 --> 0:03:53.720 all these different resources. Most of the operating systems we 0:03:53.840 --> 0:03:58.600 encounter today incorporate a graphical user interface or gooey, in 0:03:58.640 --> 0:04:03.040 which little icon represent computer processes. Now, in the old 0:04:03.120 --> 0:04:06.720 days and with some modern line command systems, you would 0:04:06.720 --> 0:04:10.080 actually type out a command to start a program dot 0:04:10.200 --> 0:04:13.120 e x C file. So, for example, I remember using 0:04:13.200 --> 0:04:15.920 our old two eight six PC back when I was 0:04:15.960 --> 0:04:18.680 a kid. We had MS DOSS running on it. That 0:04:18.760 --> 0:04:21.559 was a line command operating system, and you would type 0:04:21.560 --> 0:04:24.800 in commands to go to a particular file directory in 0:04:24.880 --> 0:04:29.400 order to run a program like say Wolfenstein. The gooey 0:04:29.400 --> 0:04:32.800 for home PCs became popular after the introduction of the 0:04:32.839 --> 0:04:37.720 Macintosh computer from Apple and the Windows operating system from 0:04:37.720 --> 0:04:42.560 Microsoft the following year, though really Windows truly took off 0:04:42.600 --> 0:04:46.760 after Windows three point one. Now for pretty obvious reasons, 0:04:47.240 --> 0:04:52.640 the operating systems we find on smartphones feature gooey's, Apple's iOS, 0:04:52.720 --> 0:04:56.640 Android and other smartphone OS flavors. All of us interface 0:04:56.680 --> 0:04:59.680 with programs through touch screen controls, or, as was the 0:04:59.720 --> 0:05:03.440 case with older Android phones, with physical keyboards and maybe 0:05:03.440 --> 0:05:06.160 even a track ball controller. The old g one had 0:05:06.200 --> 0:05:12.280 one of those those icons on the screen represent processes, programs, 0:05:12.360 --> 0:05:17.360 initiation programs, executable files. So selecting one of these icons 0:05:17.520 --> 0:05:20.960 initiates the sequence to start a program sending instructions to 0:05:20.960 --> 0:05:23.960 the operating system underneath to manage the resources that are 0:05:23.960 --> 0:05:28.880 required to make the program go. Computer programmers and engineers 0:05:29.440 --> 0:05:35.800 describe operating systems as existing as a stack of various functions. 0:05:36.080 --> 0:05:39.360 Now these are not physical layers or anything like that. 0:05:39.960 --> 0:05:42.599 It's more of a way for us to think about 0:05:42.680 --> 0:05:46.440 the different functions the operating system must perform and grouping 0:05:46.480 --> 0:05:50.320 those functions together in a way that makes sense. So 0:05:50.360 --> 0:05:52.440 in general, you can think of if you think of 0:05:52.480 --> 0:05:54.719 a stack like a vertical stack, almost like a stack 0:05:54.760 --> 0:05:58.360 of wooden blocks. At the very bottom or the foundation 0:05:58.600 --> 0:06:02.600 of the stack, the part that's against the bare metal 0:06:03.000 --> 0:06:06.440 or the hardware of the device itself would be the 0:06:06.600 --> 0:06:11.839 kernel that is the core of the operating system. These 0:06:11.880 --> 0:06:15.600 are the functions that are are most directly interfacing with 0:06:15.720 --> 0:06:19.159 the hardware stuff like processors and circuits and all the 0:06:19.160 --> 0:06:22.520 stuff that's doing all the number crunching androids. Foundation is 0:06:22.560 --> 0:06:26.400 based specifically around the Linux kernel. So, as I said, 0:06:26.440 --> 0:06:28.560 the kernel is the core of the operating system. It 0:06:28.600 --> 0:06:32.839 has complete control over the hardware. Lenox is an open 0:06:32.920 --> 0:06:36.599 source operating system, has a large community of developers and 0:06:36.680 --> 0:06:40.360 programmers contributing to it. And because of this huge community, 0:06:40.720 --> 0:06:44.799 things like security vulnerabilities and bugs are typically discovered pretty 0:06:44.880 --> 0:06:47.920 quickly and they can be fixed pretty quickly too. Now 0:06:47.920 --> 0:06:52.400 an Android that's just the kernel. Android itself is not Lennox. 0:06:52.920 --> 0:06:56.600 So the next layer up from the Lenox kernel and 0:06:56.600 --> 0:07:02.120 Android is called the hardware abstraction layer or how which 0:07:02.160 --> 0:07:05.719 is an ominous at all. Sorry, I can't do that, Dave. 0:07:06.400 --> 0:07:10.640 This layer provides a software environment through which the programs 0:07:10.720 --> 0:07:13.600 higher up on the stack can interface to access the 0:07:13.600 --> 0:07:17.000 components they need, such as let's say it's the handset speaker. 0:07:17.120 --> 0:07:21.280 Let's say that it's a music program. Well it the 0:07:21.320 --> 0:07:25.720 program would then send messages to the hardware abstraction layer 0:07:26.080 --> 0:07:27.960 to say I need to get access to the speaker 0:07:28.360 --> 0:07:32.440 and play this audio file through the speaker. So how 0:07:32.560 --> 0:07:36.600 would kind of handle that and then relay the specific 0:07:37.000 --> 0:07:40.240 requirements further down to the Linux kernel to get all 0:07:40.280 --> 0:07:43.679 the way down to the speaker level. So other examples 0:07:43.720 --> 0:07:47.840 would be the Bluetooth devices. You know, Bluetooth devices connect 0:07:47.840 --> 0:07:52.239 to a phone via the Bluetooth transmitter. Well, the hardware 0:07:52.240 --> 0:07:56.120 abstraction layer provides the resources needed for an app that 0:07:56.400 --> 0:07:59.960 needs to have access to a Bluetooth transmitter to actually 0:08:00.080 --> 0:08:02.720 get that access. So this way, developers don't have to 0:08:02.760 --> 0:08:06.840 create stuff for specific handsets, but rather for any Android handset. 0:08:07.200 --> 0:08:10.800 They don't have to worry if one Android phone is 0:08:10.840 --> 0:08:14.040 built in a very different way to another Android phone. 0:08:14.520 --> 0:08:17.320 Now two blocks share the next layer in the stack. 0:08:17.680 --> 0:08:21.240 They are the Android run time block and the native 0:08:21.360 --> 0:08:26.800 c C plus plus libraries. Okay, so the Android run 0:08:26.800 --> 0:08:30.920 Time or a RT serves as a kind of envelope 0:08:31.240 --> 0:08:35.199 for processes. Alright, think of like every program that you're 0:08:35.280 --> 0:08:37.600 running on a phone, like you're actually running that program 0:08:37.600 --> 0:08:40.120 on the phone. It exists in kind of a think 0:08:40.160 --> 0:08:43.760 of it as like a box. It keeps each process separate. 0:08:43.840 --> 0:08:47.040 So let's say that you've got your photo app running 0:08:47.400 --> 0:08:50.920 and you're also listening to something on the I Heart 0:08:51.000 --> 0:08:55.880 radio app, for example, shameless Plug. Let's say you're listening 0:08:55.880 --> 0:08:58.079 to both of those, so you've got both processes running 0:08:58.120 --> 0:09:00.320 at the same time. Well, you don't want them just 0:09:00.760 --> 0:09:05.160 running on the phone with no division between them, because 0:09:05.200 --> 0:09:08.240 if something were to happen to one of those processes, 0:09:08.559 --> 0:09:11.439 it could affect the other one. Let's say that the 0:09:11.480 --> 0:09:15.480 photo app has a failure for some reason, something goes 0:09:15.520 --> 0:09:17.960 wrong and it freezes. Well, you don't want that to 0:09:18.040 --> 0:09:21.040 affect the other apps running on your device. So the 0:09:21.080 --> 0:09:23.400 best thing you could do is create what are called 0:09:23.520 --> 0:09:26.040 virtual machines, which I've talked about quite a bit in 0:09:26.080 --> 0:09:32.240 recent episodes. These virtual machines act as silos. They act 0:09:32.280 --> 0:09:38.360 as as uh, separated and protected areas in which a 0:09:38.440 --> 0:09:41.840 process can run without it affecting anything else, and each 0:09:41.880 --> 0:09:46.079 of them will get the resources needed to run that process. 0:09:46.600 --> 0:09:49.719 So again, the operating system has to look at the 0:09:49.800 --> 0:09:52.640 requirements of each of those processes, the photo app and 0:09:52.760 --> 0:09:55.040 the I Heart Radio app, and say, all right, well, 0:09:55.360 --> 0:09:58.040 I need to dedicate this much memory and processing power 0:09:58.080 --> 0:10:00.760 to run this one, and this much memory processing power 0:10:00.760 --> 0:10:03.360 to run this other one, and that all that stuff 0:10:03.400 --> 0:10:06.280 is happening in the background. We as users are completely 0:10:07.000 --> 0:10:10.160 not you know, aware of this, unless something were to 0:10:10.200 --> 0:10:11.800 go wrong, in which case we might say, oh, the 0:10:11.800 --> 0:10:14.080 photo app crashed, but at least I'm still listening to 0:10:14.120 --> 0:10:17.839 my music, so really you don't notice it happening. Now 0:10:17.840 --> 0:10:22.120 I should add that this particular feature was really added 0:10:22.200 --> 0:10:26.400 in starting with Android version five point oh also known 0:10:26.440 --> 0:10:29.880 as Lollipop. So this is technically jumping ahead in our 0:10:29.920 --> 0:10:32.640 story a little bit, but this is the part of 0:10:32.640 --> 0:10:35.840 the stack that lets stuff run independently of one another. Now, 0:10:35.880 --> 0:10:40.959 before Android run time, before that was the virtualization strategy 0:10:41.040 --> 0:10:43.880 that Google was using, they did rely on a different 0:10:43.960 --> 0:10:49.440 virtualization strategy with a process virtual machine software called dal 0:10:49.520 --> 0:10:52.959 vic d A l v I K. That's what did 0:10:53.040 --> 0:10:55.480 essentially the same sort of job as the Android run 0:10:55.520 --> 0:10:59.360 time component up through Android version four point four, also 0:10:59.440 --> 0:11:02.800 known as get cat. So Android did have this earlier, 0:11:03.800 --> 0:11:06.480 but I figured it would be more and make more 0:11:06.480 --> 0:11:09.240 sense to talk about Android runtime because that's what's currently 0:11:09.320 --> 0:11:13.959 being used in Android operating system phones today. Now, as 0:11:14.000 --> 0:11:17.160 for the libraries I mentioned earlier, In programming, a library 0:11:17.240 --> 0:11:20.520 is a collection of pre compiled routines that programs can 0:11:20.600 --> 0:11:23.120 take advantage of. So when you think of a program, 0:11:23.120 --> 0:11:26.280 a program is really a series of instructions for a computer, 0:11:26.600 --> 0:11:29.199 and some of those instructions are going to be common ones, 0:11:29.360 --> 0:11:32.520 ones that you would use in lots of different types 0:11:32.559 --> 0:11:34.760 of programs. So it doesn't make a whole lot of 0:11:34.760 --> 0:11:38.960 sense to have to go back and re established that 0:11:39.040 --> 0:11:41.600 path every single time you want to build a program. 0:11:41.640 --> 0:11:44.280 It would be time consuming, it would be wasteful. So 0:11:44.400 --> 0:11:49.480 libraries are these pre compiled routines that mean that you 0:11:49.480 --> 0:11:52.559 you just plug those in for that part. And this 0:11:52.640 --> 0:11:55.840 is a very, very granular approach. We'll get into a 0:11:55.880 --> 0:12:00.000 slightly larger version of this in just a second. Library 0:12:00.120 --> 0:12:02.560 is dramatically reduced the amount of work programmers have to 0:12:02.600 --> 0:12:05.720 do to build out applications. So if a program needs 0:12:05.720 --> 0:12:08.559 to access a particular process, a module in the library 0:12:08.640 --> 0:12:11.400 can be plugged into the program as a kind of shortcut. 0:12:11.679 --> 0:12:14.800 So it's an invaluable resource and pretty much all programming 0:12:14.920 --> 0:12:18.160 environments take advantage of them. Now, next up in the 0:12:18.240 --> 0:12:21.720 stack we have the Java a p I framework. This 0:12:21.760 --> 0:12:24.480 includes all the basic components you need to build out apps. 0:12:24.720 --> 0:12:27.160 So it's kind of like taking that concept I just 0:12:27.200 --> 0:12:29.760 talked about with the library, you know, these these little 0:12:29.960 --> 0:12:33.920 pre compiled routines and building on that. Now we're talking 0:12:33.920 --> 0:12:39.640 about larger building blocks, not super teeny tiny ones, but 0:12:39.800 --> 0:12:43.760 that can still be used to put together basic functions 0:12:43.800 --> 0:12:48.080 of various applications and it's a huge help to developers. 0:12:48.679 --> 0:12:51.640 The framework has the building blocks or puzzle pieces that 0:12:51.720 --> 0:12:54.679 programmers can use to to build out those apps. And 0:12:54.720 --> 0:12:57.760 this is the environment in which programmers actually operate. They 0:12:57.760 --> 0:13:00.520 rely on the a p I, which stands for Application 0:13:00.559 --> 0:13:03.800 Programming Interface in order to build out the apps, whether 0:13:03.840 --> 0:13:06.079 it's a video editing app or a puzzle game or 0:13:06.120 --> 0:13:09.240 whatever it might be. Now, the topmost layer of this 0:13:09.400 --> 0:13:12.880 stack is what it tends to be that well, it 0:13:13.000 --> 0:13:16.240 is the system apps themselves. So again, if you think 0:13:16.280 --> 0:13:18.719 of that bottom layer of the stack as the foundation 0:13:19.080 --> 0:13:22.960 that rests against the bare metal of the handset, this 0:13:23.120 --> 0:13:26.760 topmost layer, you can think of, is the layer that 0:13:26.800 --> 0:13:30.079 actually faces the end user. It's it's what we interact 0:13:30.120 --> 0:13:32.640 with when we're using our phones. So this is the 0:13:32.679 --> 0:13:35.880 side that we actually see. It includes stuff like the 0:13:35.920 --> 0:13:38.640 dialer application, you know, in case we want to use 0:13:38.640 --> 0:13:43.600 our smartphone as a phone, or maybe the email app 0:13:43.720 --> 0:13:47.800 or well you get the idea. It's all those basic apps. Now, 0:13:48.360 --> 0:13:51.360 these are intended to be the basic apps that any 0:13:51.400 --> 0:13:56.280 other third party app could tap into for certain capabilities. Now, 0:13:56.320 --> 0:14:00.000 Google made the decision to allow users, carriers, and or 0:14:00.200 --> 0:14:04.960 handset manufacturers the chance to swap out many, but not all, 0:14:05.080 --> 0:14:08.840 of these system apps for something from a third party. 0:14:09.320 --> 0:14:11.800 So if you don't like let's say the basic on 0:14:11.960 --> 0:14:16.160 screen keyboard that comes standard with Android, you could change that. 0:14:16.280 --> 0:14:18.880 You could switch it out for a different on screen 0:14:18.960 --> 0:14:23.640 keyboard created from a different put third party, and that 0:14:23.640 --> 0:14:27.160 would become the new system level app for that particular feature. 0:14:27.560 --> 0:14:31.240 Google does restrict this for certain functions. Not every system 0:14:31.320 --> 0:14:34.400 level app is available to be swapped out. For example, 0:14:34.440 --> 0:14:37.600 the settings app, you can't do that, and that gives 0:14:37.640 --> 0:14:40.280 you more fine tune control over a lot of the 0:14:40.280 --> 0:14:43.880 handsets settings. So that's the reason why Google says, no, 0:14:44.240 --> 0:14:46.520 this one is off limits. We're going to keep it 0:14:46.560 --> 0:14:49.800 as is. But otherwise it's pretty fair game. And that's 0:14:49.840 --> 0:14:53.440 an overview of what an operating system is and how 0:14:53.480 --> 0:14:57.360 the Android OS stacks up, so to speak. And it's 0:14:57.480 --> 0:15:00.120 good to remember that Android is built on top of 0:15:00.240 --> 0:15:04.600 an older operating system, that being Linux. Because Linux is 0:15:04.640 --> 0:15:07.880 open source, Reuben and his team of developers Andy Rubin, 0:15:07.960 --> 0:15:11.800 that is, could tweak the Linux kernel to suit their 0:15:11.800 --> 0:15:14.840 own needs when they were building out Android. Anyone can 0:15:14.880 --> 0:15:18.400 do that because it's open source. And another point that's 0:15:18.480 --> 0:15:22.960 important to stress. I'm really just talking about the kernel 0:15:23.200 --> 0:15:26.880 that component just above the bare metal the interfaces directly 0:15:26.920 --> 0:15:29.240 with the hardware of the handset. And the reason it's 0:15:29.240 --> 0:15:32.280 important to remember that is you can't just run Linux 0:15:32.280 --> 0:15:36.480 applications on an Android device, nor can you run Android 0:15:36.480 --> 0:15:39.640 apps on a Linux computer, at least without not without 0:15:39.680 --> 0:15:42.840 some sort of emulator. And that's because those layers that 0:15:42.920 --> 0:15:46.600 stack on top of the kernel are different. Between Linux 0:15:46.600 --> 0:15:50.600 and Android, the software libraries necessary to run certain processes 0:15:50.720 --> 0:15:54.280 are different, and because of those differences, there's been some 0:15:54.320 --> 0:15:57.680 debate over whether or not you should actually call Android 0:15:57.720 --> 0:16:01.680 a Linux distribution or dis s trow so. In Linux speak, 0:16:02.200 --> 0:16:06.480 a distribution is a specific implementation of the Linux operating system, 0:16:06.480 --> 0:16:09.920 and there are hundreds of different distros out there now. 0:16:09.960 --> 0:16:13.720 I think the debate is largely unimportant because it remains 0:16:13.800 --> 0:16:17.760 that the two different operating systems are different enough that 0:16:17.920 --> 0:16:21.120 you can't port apps across environments without doing a lot 0:16:21.120 --> 0:16:24.360 of extra legwork. Now, before I take a quick break, 0:16:24.640 --> 0:16:26.640 I do want to give a quick recap of what 0:16:26.720 --> 0:16:30.280 was going on. When I finished the last episode. Google 0:16:30.320 --> 0:16:33.440 had released Android three point oh a k A Honeycomb, 0:16:33.480 --> 0:16:35.680 which I'll talk about a little bit more in a second, 0:16:36.160 --> 0:16:38.840 and this was a version of Android that Google had 0:16:38.840 --> 0:16:42.320 designed specifically for Android tablets. It was the first version 0:16:42.320 --> 0:16:46.720 of Android that UI expert Matthias Duarte really had a 0:16:46.800 --> 0:16:49.640 hand in, as he had been brought in shortly before 0:16:49.760 --> 0:16:53.400 its predecessor, Gingerbread, had been pushed out to users. So 0:16:53.600 --> 0:16:56.040 Duarte didn't have a whole lot of opportunity to put 0:16:56.080 --> 0:16:59.040 his mark on Gingerbread, but he definitely did a lot 0:16:59.080 --> 0:17:02.280 more work on honey Home. Duarte also faced a big 0:17:02.400 --> 0:17:06.240 challenge because Google is a company built by and arguably 0:17:06.359 --> 0:17:10.720 some would say four engineers, and the Android phones definitely 0:17:10.760 --> 0:17:13.440 reflected that. I say that as someone who owned a 0:17:13.800 --> 0:17:19.000 first generation Android phone. They worked, but they weren't necessarily intuitive. 0:17:19.280 --> 0:17:23.800 The design didn't establish a coherent aesthetic. There was no 0:17:24.720 --> 0:17:29.280 defining trait for an Android app apart from the fact 0:17:29.320 --> 0:17:31.520 that it was running on an Android phone. They all 0:17:31.760 --> 0:17:37.960 looked wildly different. There was no cohesive vision. Convincing engineers 0:17:37.960 --> 0:17:42.200 that design was an important component wasn't always easy, but 0:17:42.320 --> 0:17:45.720 Duarte figured he was up for the challenge. I'll talk 0:17:45.760 --> 0:17:47.679 a little bit more about that in just a second, 0:17:47.680 --> 0:17:57.840 but first let's take a quick break. Okay, let's go 0:17:57.960 --> 0:18:03.159 back to Honeycomb for a second. The tablet only version 0:18:03.160 --> 0:18:06.119 of Android. Google itself has admitted that the development of 0:18:06.119 --> 0:18:10.119 Honeycomb was rushed. They didn't have a whole lot of 0:18:10.160 --> 0:18:13.120 time to get it out, and it was a frantic response. 0:18:13.200 --> 0:18:17.199 You could think to Apple's iPad launch, which managed to 0:18:17.240 --> 0:18:20.440 do what no other tablet had done up to that point. 0:18:20.560 --> 0:18:24.320 It was able to capture the attention of the mainstream public. 0:18:24.920 --> 0:18:28.240 Tablet computers had been around for a while, and they 0:18:28.240 --> 0:18:30.400 weren't brand new when the iPad came out. They had 0:18:30.440 --> 0:18:33.840 been a thing for years, but they had previously been 0:18:33.880 --> 0:18:37.479 fairly niche gadgets used by a few different industries, like 0:18:37.960 --> 0:18:41.199 in medicine. Nurses were using them things like that for 0:18:41.359 --> 0:18:44.760 very specific tasks, and largely they were ignored by the 0:18:44.800 --> 0:18:48.600 general public. In fact, tablet computers had been such a 0:18:48.680 --> 0:18:55.200 non component in everyday computing that I famously, and if 0:18:55.240 --> 0:18:58.840 you want to search the back catalog of tech stuff 0:18:58.840 --> 0:19:01.200 you can find out where I did this. I famously 0:19:01.280 --> 0:19:04.440 predicted the iPad itself would flop. I mean, no one 0:19:04.560 --> 0:19:07.719 had managed to make tablet computers useful enough for anyone 0:19:07.760 --> 0:19:10.879 to actually want one, So I was a bit off 0:19:11.480 --> 0:19:15.359 on that particular prediction, But I don't even know to 0:19:15.440 --> 0:19:19.240 this day if I was off about them truly being usable. 0:19:19.480 --> 0:19:23.560 Maybe this speaks more to my inability to incorporate tablets 0:19:23.600 --> 0:19:26.800 into my day to day life. So I very rarely 0:19:27.000 --> 0:19:29.439 use them myself. If I do use a tablet, I 0:19:29.480 --> 0:19:33.120 typically turn it into a super lightweight laptop computer instead, 0:19:33.680 --> 0:19:36.119 like I have a Microsoft Surface that I use for 0:19:36.200 --> 0:19:40.640 that purpose. I love it as a very lightweight laptop, 0:19:40.680 --> 0:19:42.120 but I don't know that I would get as much 0:19:42.200 --> 0:19:44.280 use out of it if I used it strictly as 0:19:44.280 --> 0:19:48.320 a tablet, simply because that's not how I work. However, 0:19:48.359 --> 0:19:51.840 I should say I gotta concede. The Apple iPad was, 0:19:52.280 --> 0:19:57.479 without any qualifiers, a huge success, and Google recognized that too, 0:19:57.720 --> 0:20:00.119 and so there was a strong incentive to develop a 0:20:00.200 --> 0:20:03.960 version of Android aimed at the tablet experience. In some ways, 0:20:04.640 --> 0:20:08.280 this helped the people who were building Honeycomb because the 0:20:08.359 --> 0:20:11.199 version of Android would only be used for tablets, and 0:20:11.280 --> 0:20:13.800 that helped cut down on the sheer variety of things 0:20:13.840 --> 0:20:17.080 that had to consider, like screen size or access to 0:20:17.160 --> 0:20:20.520 a cell phone. Those were off the table. Because most 0:20:20.560 --> 0:20:23.399 tablets were in a pretty small range of sizes, they 0:20:23.440 --> 0:20:26.399 didn't have to worry about the huge number of variables 0:20:26.400 --> 0:20:29.320 that they would encounter if they were designing and operating 0:20:29.320 --> 0:20:32.320 system for smartphones. But it also meant that Google needed 0:20:32.320 --> 0:20:35.520 to make sure the hardware manufacturers were gonna play by 0:20:35.520 --> 0:20:39.560 the rules because previous versions of Android were all open source, 0:20:40.040 --> 0:20:43.200 so after they were pushed out after a certain amount 0:20:43.240 --> 0:20:46.520 of time, Google would allow the code to be freely 0:20:46.560 --> 0:20:51.840 available for anyone to look at, to use, and etcetera. 0:20:52.320 --> 0:20:56.879 But Google did not want some manufacturer out there trying 0:20:56.880 --> 0:21:00.399 to push Honeycomb out on a phone like device was 0:21:00.480 --> 0:21:05.880 not intended to do that, so they said, while we're 0:21:05.920 --> 0:21:08.200 going to instead of releasing this as open source, we're 0:21:08.200 --> 0:21:11.600 going to keep it to ourselves, and manufacturers would have 0:21:11.640 --> 0:21:14.600 to go through Google to get Honeycomb for their Android 0:21:14.600 --> 0:21:19.080 based tablets. Upon its initial release, Honeycomb lacks support for 0:21:19.160 --> 0:21:22.800 some pretty important processes, like it didn't have support for 0:21:22.840 --> 0:21:25.960 Adobe Flash, which at the time was still a very 0:21:26.000 --> 0:21:31.480 important component for web content, and Honeycomb was a bit 0:21:31.560 --> 0:21:34.320 buggy when it was first released. There were a lot 0:21:34.320 --> 0:21:38.240 of little performance issues and that, paired with the lack 0:21:38.320 --> 0:21:42.320 of open source, would end up hurting the launch of Honeycomb, 0:21:42.720 --> 0:21:45.600 and so a lot of people didn't really care for 0:21:45.720 --> 0:21:47.960 the Android tablets that were coming out of that time, 0:21:48.000 --> 0:21:51.000 and that's not really the fault of the OS necessarily, 0:21:51.680 --> 0:21:54.399 but it didn't end up doing it didn't do the 0:21:54.440 --> 0:21:59.400 OS any favors either. The design decisions were largely admired. 0:21:59.480 --> 0:22:03.119 Duarte had created a more cohesive design approach and he 0:22:03.280 --> 0:22:07.280 leaned really hard on sci fi like visuals. A lot 0:22:07.320 --> 0:22:10.680 of people referred to it as a tron like interface, 0:22:11.400 --> 0:22:15.200 and it was called a hologram interface. Within Google, Google 0:22:15.200 --> 0:22:18.280 built in some new features that would give handset manufacturers 0:22:18.280 --> 0:22:22.240 more options. Uh the Zoom, the XO o M, the 0:22:22.280 --> 0:22:26.280 first tablet to feature Honeycomb, had no hardware buttons, so 0:22:26.440 --> 0:22:29.720 Google had to build in on screen capabilities to do 0:22:29.800 --> 0:22:33.160 stuff like navigate to the home page of the Android 0:22:33.160 --> 0:22:36.119 operating system, pull up menus, that kind of stuff, the 0:22:36.160 --> 0:22:42.120 stuff that previously had dedicated hardware buttons on Android devices, 0:22:42.160 --> 0:22:44.480 because up to that point that's what you had to 0:22:44.480 --> 0:22:46.679 have if you had an Android phone. It had a 0:22:46.720 --> 0:22:50.159 physical menu button, a physical home button, a physical back button. 0:22:50.920 --> 0:22:54.280 But starting with Honeycomb, Google was able to get rid 0:22:54.320 --> 0:22:56.760 of some of that and they built in on screen 0:22:56.920 --> 0:23:00.720 versions of those functions. That design element would carry over 0:23:00.760 --> 0:23:04.719 into ice Cream Sandwich, which was the next version for 0:23:04.880 --> 0:23:09.120 actual Android smartphones, it was toned down a bit. However, 0:23:09.160 --> 0:23:13.080 The Honeycomb was full on tron but ice Cream Sandwich 0:23:13.160 --> 0:23:16.240 was sort of tron light. They eased off a bit 0:23:16.400 --> 0:23:19.800 on that design approach. This version of Android debut on 0:23:19.840 --> 0:23:23.000 the Samsung Galaxy Nexus, a phone that had a seven 0:23:24.119 --> 0:23:26.879 resolution screen, which was a big step up from the 0:23:26.920 --> 0:23:30.199 earlier Android phones, and the additions in Honeycomb for on 0:23:30.280 --> 0:23:34.200 screen controls meant the Galaxy Nexus and most Android phones 0:23:34.240 --> 0:23:37.600 that were to follow no longer needed those physical buttons. 0:23:37.600 --> 0:23:40.880 Other than maybe a power button and volume controls, those 0:23:40.880 --> 0:23:44.120 would typically be physical, everything else would be an on 0:23:44.160 --> 0:23:48.560 screen button. Uh. This let designers create more sleek and 0:23:48.600 --> 0:23:52.520 aesthetically pleasing handsets to dedicate more of the space of 0:23:52.560 --> 0:23:56.080 the phone to the screen itself, and it put the 0:23:56.160 --> 0:23:59.879 more chunky origins of Android phones deep into the past. 0:24:00.480 --> 0:24:03.280 Ice Cream Sandwich also had a lot of UI updates, 0:24:03.320 --> 0:24:05.280 like a system bar for the top of the phone 0:24:05.320 --> 0:24:08.680 that would hold stuff like notifications, and there was also 0:24:08.720 --> 0:24:10.200 a system bar at the bottom of the phone that 0:24:10.200 --> 0:24:13.159