Speaker 1: Welcome to tech Stuff, a production of I Heart Radios,
Speaker 1: How Stuff Works. Hey there, and welcome to tech Stuff.
Speaker 1: I'm your host, Jonathan Strickland. I'm an executive producer with
Speaker 1: I Heart Radio and How Stuff Works and Love of
Speaker 1: all Things Tech. And in our last episode, I talked
Speaker 1: about the creation of Google Android leading up to the
Speaker 1: release of ice Cream Sandwich, also known as Android version
Speaker 1: four point Oh. But before I go any further with
Speaker 1: that story, I thought I might take some time to
Speaker 1: describe what an operating system actually does from a high level,
Speaker 1: since I kind of skipped over that in the last episode.
Speaker 1: But in my defense, I really wanted to get to
Speaker 1: the actual Android stuff, all right, So let's go from
Speaker 1: the most basic explanations here and work our way up
Speaker 1: from there. A computer is essentially a machine that, through
Speaker 1: processing tons of complex calculations in a short amount of time,
Speaker 1: can produce all sorts of different end results. Some of
Speaker 1: them can be pretty intuitive, like calculating a formula that's
Speaker 1: embedded in a spreadsheet program. That's very clearly a mathematical process.
Speaker 1: It's easy to understand. Some are a little less intuitive,
Speaker 1: like allowing you to make a video call to someone
Speaker 1: who's on the other side of the world. But ultimately,
Speaker 1: a computer is taking information in the forms of zeros
Speaker 1: and ones, and it is performing various operations on that
Speaker 1: data to get results, which are then fed back to
Speaker 1: you in some appropriate way, depending upon whatever it is
Speaker 1: you're trying to do, but you know you'll be able
Speaker 1: to see it in a way that makes sense to you,
Speaker 1: as opposed to just a different string of zeros and ones,
Speaker 1: which would be useless to us. We run programs on
Speaker 1: computers to get these results. So in the examples I've
Speaker 1: already mentioned, you would have some sort of spreadsheet program
Speaker 1: like Microsoft Excel, or some sort of video calling program
Speaker 1: like Skype. Microsoft has nothing to do with this episode,
Speaker 1: by the way, Obviously I'm talking about androids, so but
Speaker 1: that's just to give you an example of programs that
Speaker 1: exist on computers. These programs need to interface with the
Speaker 1: hardware that's actually doing all of those calculations and gathering
Speaker 1: that information. Now, in the old old days of computers,
Speaker 1: programmers would build their programs into the machines themselves. They
Speaker 1: would program on what we would call bare metal, and
Speaker 1: computers would only do very specific tasks. By the time
Speaker 1: we got to general programmable computers, we could run different
Speaker 1: programs on the same machines. Programmers would write these four
Speaker 1: specific computers, and the program instructions were essentially telling the
Speaker 1: hardware what to do. And this goes all the way
Speaker 1: from the era where you would actually physically unplug parts
Speaker 1: of the computer system and plug it into different parts,
Speaker 1: up to where you might program it in a series
Speaker 1: of punch cards that would be read by computer, and
Speaker 1: then the computer would follow whatever the instructions were that
Speaker 1: the punch cards indicated. These are all various examples of
Speaker 1: programs and computers, but as computers and programs evolved, it
Speaker 1: became necessary to create some sort of liaison between the
Speaker 1: bare metal of the hardware underneath and the programs that
Speaker 1: would run on top of it. And the operating system
Speaker 1: is kind of like a foreman or a supervisor. It's
Speaker 1: in charge of managing stuff like computer memory and the
Speaker 1: order of operations, and with modern computer devices that also
Speaker 1: handles stuff like multitasking, making sure each instance of a
Speaker 1: program has the resources it needs to run, or in
Speaker 1: some cases even throttling those resources that are going to
Speaker 1: a program that might be in the background while another
Speaker 1: program is taking center stage. It's sort of dynamically managing
Speaker 1: all these different resources. Most of the operating systems we
Speaker 1: encounter today incorporate a graphical user interface or gooey, in
Speaker 1: which little icon represent computer processes. Now, in the old
Speaker 1: days and with some modern line command systems, you would
Speaker 1: actually type out a command to start a program dot
Speaker 1: e x C file. So, for example, I remember using
Speaker 1: our old two eight six PC back when I was
Speaker 1: a kid. We had MS DOSS running on it. That
Speaker 1: was a line command operating system, and you would type
Speaker 1: in commands to go to a particular file directory in
Speaker 1: order to run a program like say Wolfenstein. The gooey
Speaker 1: for home PCs became popular after the introduction of the
Speaker 1: Macintosh computer from Apple and the Windows operating system from
Speaker 1: Microsoft the following year, though really Windows truly took off
Speaker 1: after Windows three point one. Now for pretty obvious reasons,
Speaker 1: the operating systems we find on smartphones feature gooey's, Apple's iOS,
Speaker 1: Android and other smartphone OS flavors. All of us interface
Speaker 1: with programs through touch screen controls, or, as was the
Speaker 1: case with older Android phones, with physical keyboards and maybe
Speaker 1: even a track ball controller. The old g one had
Speaker 1: one of those those icons on the screen represent processes, programs,
Speaker 1: initiation programs, executable files. So selecting one of these icons
Speaker 1: initiates the sequence to start a program sending instructions to
Speaker 1: the operating system underneath to manage the resources that are
Speaker 1: required to make the program go. Computer programmers and engineers
Speaker 1: describe operating systems as existing as a stack of various functions.
Speaker 1: Now these are not physical layers or anything like that.
Speaker 1: It's more of a way for us to think about
Speaker 1: the different functions the operating system must perform and grouping
Speaker 1: those functions together in a way that makes sense. So
Speaker 1: in general, you can think of if you think of
Speaker 1: a stack like a vertical stack, almost like a stack
Speaker 1: of wooden blocks. At the very bottom or the foundation
Speaker 1: of the stack, the part that's against the bare metal
Speaker 1: or the hardware of the device itself would be the
Speaker 1: kernel that is the core of the operating system. These
Speaker 1: are the functions that are are most directly interfacing with
Speaker 1: the hardware stuff like processors and circuits and all the
Speaker 1: stuff that's doing all the number crunching androids. Foundation is
Speaker 1: based specifically around the Linux kernel. So, as I said,
Speaker 1: the kernel is the core of the operating system. It
Speaker 1: has complete control over the hardware. Lenox is an open
Speaker 1: source operating system, has a large community of developers and
Speaker 1: programmers contributing to it. And because of this huge community,
Speaker 1: things like security vulnerabilities and bugs are typically discovered pretty
Speaker 1: quickly and they can be fixed pretty quickly too. Now
Speaker 1: an Android that's just the kernel. Android itself is not Lennox.
Speaker 1: So the next layer up from the Lenox kernel and
Speaker 1: Android is called the hardware abstraction layer or how which
Speaker 1: is an ominous at all. Sorry, I can't do that, Dave.
Speaker 1: This layer provides a software environment through which the programs
Speaker 1: higher up on the stack can interface to access the
Speaker 1: components they need, such as let's say it's the handset speaker.
Speaker 1: Let's say that it's a music program. Well it the
Speaker 1: program would then send messages to the hardware abstraction layer
Speaker 1: to say I need to get access to the speaker
Speaker 1: and play this audio file through the speaker. So how
Speaker 1: would kind of handle that and then relay the specific
Speaker 1: requirements further down to the Linux kernel to get all
Speaker 1: the way down to the speaker level. So other examples
Speaker 1: would be the Bluetooth devices. You know, Bluetooth devices connect
Speaker 1: to a phone via the Bluetooth transmitter. Well, the hardware
Speaker 1: abstraction layer provides the resources needed for an app that
Speaker 1: needs to have access to a Bluetooth transmitter to actually
Speaker 1: get that access. So this way, developers don't have to
Speaker 1: create stuff for specific handsets, but rather for any Android handset.
Speaker 1: They don't have to worry if one Android phone is
Speaker 1: built in a very different way to another Android phone.
Speaker 1: Now two blocks share the next layer in the stack.
Speaker 1: They are the Android run time block and the native
Speaker 1: c C plus plus libraries. Okay, so the Android run
Speaker 1: Time or a RT serves as a kind of envelope
Speaker 1: for processes. Alright, think of like every program that you're
Speaker 1: running on a phone, like you're actually running that program
Speaker 1: on the phone. It exists in kind of a think
Speaker 1: of it as like a box. It keeps each process separate.
Speaker 1: So let's say that you've got your photo app running
Speaker 1: and you're also listening to something on the I Heart
Speaker 1: radio app, for example, shameless Plug. Let's say you're listening
Speaker 1: to both of those, so you've got both processes running
Speaker 1: at the same time. Well, you don't want them just
Speaker 1: running on the phone with no division between them, because
Speaker 1: if something were to happen to one of those processes,
Speaker 1: it could affect the other one. Let's say that the
Speaker 1: photo app has a failure for some reason, something goes
Speaker 1: wrong and it freezes. Well, you don't want that to
Speaker 1: affect the other apps running on your device. So the
Speaker 1: best thing you could do is create what are called
Speaker 1: virtual machines, which I've talked about quite a bit in
Speaker 1: recent episodes. These virtual machines act as silos. They act
Speaker 1: as as uh, separated and protected areas in which a
Speaker 1: process can run without it affecting anything else, and each
Speaker 1: of them will get the resources needed to run that process.
Speaker 1: So again, the operating system has to look at the
Speaker 1: requirements of each of those processes, the photo app and
Speaker 1: the I Heart Radio app, and say, all right, well,
Speaker 1: I need to dedicate this much memory and processing power
Speaker 1: to run this one, and this much memory processing power
Speaker 1: to run this other one, and that all that stuff
Speaker 1: is happening in the background. We as users are completely
Speaker 1: not you know, aware of this, unless something were to
Speaker 1: go wrong, in which case we might say, oh, the
Speaker 1: photo app crashed, but at least I'm still listening to
Speaker 1: my music, so really you don't notice it happening. Now
Speaker 1: I should add that this particular feature was really added
Speaker 1: in starting with Android version five point oh also known
Speaker 1: as Lollipop. So this is technically jumping ahead in our
Speaker 1: story a little bit, but this is the part of
Speaker 1: the stack that lets stuff run independently of one another. Now,
Speaker 1: before Android run time, before that was the virtualization strategy
Speaker 1: that Google was using, they did rely on a different
Speaker 1: virtualization strategy with a process virtual machine software called dal
Speaker 1: vic d A l v I K. That's what did
Speaker 1: essentially the same sort of job as the Android run
Speaker 1: time component up through Android version four point four, also
Speaker 1: known as get cat. So Android did have this earlier,
Speaker 1: but I figured it would be more and make more
Speaker 1: sense to talk about Android runtime because that's what's currently
Speaker 1: being used in Android operating system phones today. Now, as
Speaker 1: for the libraries I mentioned earlier, In programming, a library
Speaker 1: is a collection of pre compiled routines that programs can
Speaker 1: take advantage of. So when you think of a program,
Speaker 1: a program is really a series of instructions for a computer,
Speaker 1: and some of those instructions are going to be common ones,
Speaker 1: ones that you would use in lots of different types
Speaker 1: of programs. So it doesn't make a whole lot of
Speaker 1: sense to have to go back and re established that
Speaker 1: path every single time you want to build a program.
Speaker 1: It would be time consuming, it would be wasteful. So
Speaker 1: libraries are these pre compiled routines that mean that you
Speaker 1: you just plug those in for that part. And this
Speaker 1: is a very, very granular approach. We'll get into a
Speaker 1: slightly larger version of this in just a second. Library
Speaker 1: is dramatically reduced the amount of work programmers have to
Speaker 1: do to build out applications. So if a program needs
Speaker 1: to access a particular process, a module in the library
Speaker 1: can be plugged into the program as a kind of shortcut.
Speaker 1: So it's an invaluable resource and pretty much all programming
Speaker 1: environments take advantage of them. Now, next up in the
Speaker 1: stack we have the Java a p I framework. This
Speaker 1: includes all the basic components you need to build out apps.
Speaker 1: So it's kind of like taking that concept I just
Speaker 1: talked about with the library, you know, these these little
Speaker 1: pre compiled routines and building on that. Now we're talking
Speaker 1: about larger building blocks, not super teeny tiny ones, but
Speaker 1: that can still be used to put together basic functions
Speaker 1: of various applications and it's a huge help to developers.
Speaker 1: The framework has the building blocks or puzzle pieces that
Speaker 1: programmers can use to to build out those apps. And
Speaker 1: this is the environment in which programmers actually operate. They
Speaker 1: rely on the a p I, which stands for Application
Speaker 1: Programming Interface in order to build out the apps, whether
Speaker 1: it's a video editing app or a puzzle game or
Speaker 1: whatever it might be. Now, the topmost layer of this
Speaker 1: stack is what it tends to be that well, it
Speaker 1: is the system apps themselves. So again, if you think
Speaker 1: of that bottom layer of the stack as the foundation
Speaker 1: that rests against the bare metal of the handset, this
Speaker 1: topmost layer, you can think of, is the layer that
Speaker 1: actually faces the end user. It's it's what we interact
Speaker 1: with when we're using our phones. So this is the
Speaker 1: side that we actually see. It includes stuff like the
Speaker 1: dialer application, you know, in case we want to use
Speaker 1: our smartphone as a phone, or maybe the email app
Speaker 1: or well you get the idea. It's all those basic apps. Now,
Speaker 1: these are intended to be the basic apps that any
Speaker 1: other third party app could tap into for certain capabilities. Now,
Speaker 1: Google made the decision to allow users, carriers, and or
Speaker 1: handset manufacturers the chance to swap out many, but not all,
Speaker 1: of these system apps for something from a third party.
Speaker 1: So if you don't like let's say the basic on
Speaker 1: screen keyboard that comes standard with Android, you could change that.
Speaker 1: You could switch it out for a different on screen
Speaker 1: keyboard created from a different put third party, and that
Speaker 1: would become the new system level app for that particular feature.
Speaker 1: Google does restrict this for certain functions. Not every system
Speaker 1: level app is available to be swapped out. For example,
Speaker 1: the settings app, you can't do that, and that gives
Speaker 1: you more fine tune control over a lot of the
Speaker 1: handsets settings. So that's the reason why Google says, no,
Speaker 1: this one is off limits. We're going to keep it
Speaker 1: as is. But otherwise it's pretty fair game. And that's
Speaker 1: an overview of what an operating system is and how
Speaker 1: the Android OS stacks up, so to speak. And it's
Speaker 1: good to remember that Android is built on top of
Speaker 1: an older operating system, that being Linux. Because Linux is
Speaker 1: open source, Reuben and his team of developers Andy Rubin,
Speaker 1: that is, could tweak the Linux kernel to suit their
Speaker 1: own needs when they were building out Android. Anyone can
Speaker 1: do that because it's open source. And another point that's
Speaker 1: important to stress. I'm really just talking about the kernel
Speaker 1: that component just above the bare metal the interfaces directly
Speaker 1: with the hardware of the handset. And the reason it's
Speaker 1: important to remember that is you can't just run Linux
Speaker 1: applications on an Android device, nor can you run Android
Speaker 1: apps on a Linux computer, at least without not without
Speaker 1: some sort of emulator. And that's because those layers that
Speaker 1: stack on top of the kernel are different. Between Linux
Speaker 1: and Android, the software libraries necessary to run certain processes
Speaker 1: are different, and because of those differences, there's been some
Speaker 1: debate over whether or not you should actually call Android
Speaker 1: a Linux distribution or dis s trow so. In Linux speak,
Speaker 1: a distribution is a specific implementation of the Linux operating system,
Speaker 1: and there are hundreds of different distros out there now.
Speaker 1: I think the debate is largely unimportant because it remains
Speaker 1: that the two different operating systems are different enough that
Speaker 1: you can't port apps across environments without doing a lot
Speaker 1: of extra legwork. Now, before I take a quick break,
Speaker 1: I do want to give a quick recap of what
Speaker 1: was going on. When I finished the last episode. Google
Speaker 1: had released Android three point oh a k A Honeycomb,
Speaker 1: which I'll talk about a little bit more in a second,
Speaker 1: and this was a version of Android that Google had
Speaker 1: designed specifically for Android tablets. It was the first version
Speaker 1: of Android that UI expert Matthias Duarte really had a
Speaker 1: hand in, as he had been brought in shortly before
Speaker 1: its predecessor, Gingerbread, had been pushed out to users. So
Speaker 1: Duarte didn't have a whole lot of opportunity to put
Speaker 1: his mark on Gingerbread, but he definitely did a lot
Speaker 1: more work on honey Home. Duarte also faced a big
Speaker 1: challenge because Google is a company built by and arguably
Speaker 1: some would say four engineers, and the Android phones definitely
Speaker 1: reflected that. I say that as someone who owned a
Speaker 1: first generation Android phone. They worked, but they weren't necessarily intuitive.
Speaker 1: The design didn't establish a coherent aesthetic. There was no
Speaker 1: defining trait for an Android app apart from the fact
Speaker 1: that it was running on an Android phone. They all
Speaker 1: looked wildly different. There was no cohesive vision. Convincing engineers
Speaker 1: that design was an important component wasn't always easy, but
Speaker 1: Duarte figured he was up for the challenge. I'll talk
Speaker 1: a little bit more about that in just a second,
Speaker 1: but first let's take a quick break. Okay, let's go
Speaker 1: back to Honeycomb for a second. The tablet only version
Speaker 1: of Android. Google itself has admitted that the development of
Speaker 1: Honeycomb was rushed. They didn't have a whole lot of
Speaker 1: time to get it out, and it was a frantic response.
Speaker 1: You could think to Apple's iPad launch, which managed to
Speaker 1: do what no other tablet had done up to that point.
Speaker 1: It was able to capture the attention of the mainstream public.
Speaker 1: Tablet computers had been around for a while, and they
Speaker 1: weren't brand new when the iPad came out. They had
Speaker 1: been a thing for years, but they had previously been
Speaker 1: fairly niche gadgets used by a few different industries, like
Speaker 1: in medicine. Nurses were using them things like that for
Speaker 1: very specific tasks, and largely they were ignored by the
Speaker 1: general public. In fact, tablet computers had been such a
Speaker 1: non component in everyday computing that I famously, and if
Speaker 1: you want to search the back catalog of tech stuff
Speaker 1: you can find out where I did this. I famously
Speaker 1: predicted the iPad itself would flop. I mean, no one
Speaker 1: had managed to make tablet computers useful enough for anyone
Speaker 1: to actually want one, So I was a bit off
Speaker 1: on that particular prediction, But I don't even know to
Speaker 1: this day if I was off about them truly being usable.
Speaker 1: Maybe this speaks more to my inability to incorporate tablets
Speaker 1: into my day to day life. So I very rarely
Speaker 1: use them myself. If I do use a tablet, I
Speaker 1: typically turn it into a super lightweight laptop computer instead,
Speaker 1: like I have a Microsoft Surface that I use for
Speaker 1: that purpose. I love it as a very lightweight laptop,
Speaker 1: but I don't know that I would get as much
Speaker 1: use out of it if I used it strictly as
Speaker 1: a tablet, simply because that's not how I work. However,
Speaker 1: I should say I gotta concede. The Apple iPad was,
Speaker 1: without any qualifiers, a huge success, and Google recognized that too,
Speaker 1: and so there was a strong incentive to develop a
Speaker 1: version of Android aimed at the tablet experience. In some ways,
Speaker 1: this helped the people who were building Honeycomb because the
Speaker 1: version of Android would only be used for tablets, and
Speaker 1: that helped cut down on the sheer variety of things
Speaker 1: that had to consider, like screen size or access to
Speaker 1: a cell phone. Those were off the table. Because most
Speaker 1: tablets were in a pretty small range of sizes, they
Speaker 1: didn't have to worry about the huge number of variables
Speaker 1: that they would encounter if they were designing and operating
Speaker 1: system for smartphones. But it also meant that Google needed
Speaker 1: to make sure the hardware manufacturers were gonna play by
Speaker 1: the rules because previous versions of Android were all open source,
Speaker 1: so after they were pushed out after a certain amount
Speaker 1: of time, Google would allow the code to be freely
Speaker 1: available for anyone to look at, to use, and etcetera.
Speaker 1: But Google did not want some manufacturer out there trying
Speaker 1: to push Honeycomb out on a phone like device was
Speaker 1: not intended to do that, so they said, while we're
Speaker 1: going to instead of releasing this as open source, we're
Speaker 1: going to keep it to ourselves, and manufacturers would have
Speaker 1: to go through Google to get Honeycomb for their Android
Speaker 1: based tablets. Upon its initial release, Honeycomb lacks support for
Speaker 1: some pretty important processes, like it didn't have support for
Speaker 1: Adobe Flash, which at the time was still a very
Speaker 1: important component for web content, and Honeycomb was a bit
Speaker 1: buggy when it was first released. There were a lot
Speaker 1: of little performance issues and that, paired with the lack
Speaker 1: of open source, would end up hurting the launch of Honeycomb,
Speaker 1: and so a lot of people didn't really care for
Speaker 1: the Android tablets that were coming out of that time,
Speaker 1: and that's not really the fault of the OS necessarily,
Speaker 1: but it didn't end up doing it didn't do the
Speaker 1: OS any favors either. The design decisions were largely admired.
Speaker 1: Duarte had created a more cohesive design approach and he
Speaker 1: leaned really hard on sci fi like visuals. A lot
Speaker 1: of people referred to it as a tron like interface,
Speaker 1: and it was called a hologram interface. Within Google, Google
Speaker 1: built in some new features that would give handset manufacturers
Speaker 1: more options. Uh the Zoom, the XO o M, the
Speaker 1: first tablet to feature Honeycomb, had no hardware buttons, so
Speaker 1: Google had to build in on screen capabilities to do
Speaker 1: stuff like navigate to the home page of the Android
Speaker 1: operating system, pull up menus, that kind of stuff, the
Speaker 1: stuff that previously had dedicated hardware buttons on Android devices,
Speaker 1: because up to that point that's what you had to
Speaker 1: have if you had an Android phone. It had a
Speaker 1: physical menu button, a physical home button, a physical back button.
Speaker 1: But starting with Honeycomb, Google was able to get rid
Speaker 1: of some of that and they built in on screen
Speaker 1: versions of those functions. That design element would carry over
Speaker 1: into ice Cream Sandwich, which was the next version for
Speaker 1: actual Android smartphones, it was toned down a bit. However,
Speaker 1: The Honeycomb was full on tron but ice Cream Sandwich
Speaker 1: was sort of tron light. They eased off a bit
Speaker 1: on that design approach. This version of Android debut on
Speaker 1: the Samsung Galaxy Nexus, a phone that had a seven
Speaker 1: resolution screen, which was a big step up from the
Speaker 1: earlier Android phones, and the additions in Honeycomb for on
Speaker 1: screen controls meant the Galaxy Nexus and most Android phones
Speaker 1: that were to follow no longer needed those physical buttons.
Speaker 1: Other than maybe a power button and volume controls, those
Speaker 1: would typically be physical, everything else would be an on
Speaker 1: screen button. Uh. This let designers create more sleek and
Speaker 1: aesthetically pleasing handsets to dedicate more of the space of
Speaker 1: the phone to the screen itself, and it put the
Speaker 1: more chunky origins of Android phones deep into the past.
Speaker 1: Ice Cream Sandwich also had a lot of UI updates,
Speaker 1: like a system bar for the top of the phone
Speaker 1: that would hold stuff like notifications, and there was also
Speaker 1: a system bar at the bottom of the phone that
Speaker 1: would allow users to navigate home, back and hit the
Speaker 1: menu button. Some of the icons got not just a
Speaker 1: graphical facelift, but also a name change, so what was
Speaker 1: previously referred to as contacts now became people. For example,
Speaker 1: it seems a little less cold, so I'm I'm in
Speaker 1: favor of it. It's an Android that's learning to love.
Speaker 1: In January two twelve, Duarte led the effort to publish
Speaker 1: a set of guidelines called Android Design. The site would
Speaker 1: act as a tutorial for app developers so they can
Speaker 1: make apps in such a way as to fit within
Speaker 1: the overall aesthetic of Android operating system. This was something
Speaker 1: that Apple had been doing for a while. In fact,
Speaker 1: over at Apple, it was notorious for the company to
Speaker 1: deny apps from being able to go into the App Store,
Speaker 1: and one of the many reasons that Apple might give
Speaker 1: is that the aesthetic of the app didn't match Apple's
Speaker 1: overall aesthetic for iOS, and so the designers will have
Speaker 1: to go back and retool the look and u I
Speaker 1: of their app. So that was more in line with
Speaker 1: Apple's design policies. Google would be a lot more lenient
Speaker 1: than Apple in those days, but Duarte saw the value
Speaker 1: of establishing a definable look so that when people saw
Speaker 1: something they would know, oh, that's an Android app, as
Speaker 1: opposed to that's on some sort of mobile device. A
Speaker 1: few months after the introduction of ice Cream Sandwich, Google
Speaker 1: made some more changes to some of its primary apps.
Speaker 1: The company introduced the Google Play banner of apps. So
Speaker 1: you had Google Play Music, Google Play Books, Google Play Store, etcetera.
Speaker 1: And you could buy content through the Google Play Store
Speaker 1: like you Let's say you want to buy a movie
Speaker 1: or maybe a record album. Anyway, the content would end
Speaker 1: up going to the appropriate apps library, so was all
Speaker 1: the management stuff was done in the background. You didn't
Speaker 1: have to worry about it, and you didn't have to
Speaker 1: go through the individual apps in order to access the store.
Speaker 1: This was the first example of Google doing an out
Speaker 1: of cycle update for individual apps, and it would mean
Speaker 1: more freedom to update apps without having to wait for
Speaker 1: a full operating system cycle update, a full version update
Speaker 1: in other words. And this approach also managed to do
Speaker 1: something that would have a big a big impact on users. Earlier,
Speaker 1: Google would issue updates in a new version of the
Speaker 1: operating system, or at least an update to the current version,
Speaker 1: and it would then make that update available for all
Speaker 1: the service carriers and handset manufacturers to push out to
Speaker 1: users on the network. But that meant that Android phone
Speaker 1: owners might be waiting for a while to get the
Speaker 1: latest update, just because the carrier they used had and
Speaker 1: pushed it out yet, or because there are delays in
Speaker 1: the handset manufacturers making sure that the chips in their
Speaker 1: handsets could accommodate the new operating system. But the app
Speaker 1: updates were different. Google could push those out through the
Speaker 1: Play Store and bypass the entire operating system update. If
Speaker 1: it was just adjusting something, you know, relatively small in
Speaker 1: one of these apps, those were completely under Google's control,
Speaker 1: so in that way, Google could deliver new features to
Speaker 1: users without them getting frustrated while waiting for their carrier
Speaker 1: to roll out the latest OS update. And in April
Speaker 1: two twelve, Google would go back to selling devices directly
Speaker 1: to customers through the Google Play Store. They had done
Speaker 1: this with the launch of the Nexus one smartphone, but
Speaker 1: it essentially discontinued the practice shortly thereafter. Then it would
Speaker 1: open up a new market for Google, one that would
Speaker 1: include not just smartphones and tablets, but eventually also stuff
Speaker 1: like smart thermostats and Chromebook laptops. So Google started to
Speaker 1: get more into the business of selling hardware directly to users,
Speaker 1: more like Apple in that regard, although Google was relying
Speaker 1: on third party manufacturers to actually design the hardware, at
Speaker 1: least until we acquired Nest. The next version of Android
Speaker 1: to come out of Google was version four point one,
Speaker 1: also known as jelly Bean, and starting with jelly Bean,
Speaker 1: Google hidden operating system update cycle that would typically last
Speaker 1: about half a year, so you could expect to updates
Speaker 1: each year for several operating system updates in a row.
Speaker 1: Jelly Bean featured some more updates to the user interface.
Speaker 1: It also aimed to create more smooth animations and scrolling.
Speaker 1: Google managed to make some steps forward with tablets as well.
Speaker 1: A sous had created a seven inch tablet that would
Speaker 1: be branded the Nexus seven and that would set a
Speaker 1: form factor for many Android tablets to follow. It was
Speaker 1: not so successful in the ten inch tablet size form factor.
Speaker 1: I mean, I had it pretty much sewned that up,
Speaker 1: but they were able to get some traction on this
Speaker 1: smaller version the seven inch form factor, and in fact
Speaker 1: they were successful enough that for once, Apple would end
Speaker 1: up following suit by later launching the iPad many largely
Speaker 1: as a response to this. Jelly Bean also introduced the
Speaker 1: Google Now feature a type of predictive search results based
Speaker 1: upon user activities and locations. Some people found this to
Speaker 1: be a bit creepy because Now would serve up cards
Speaker 1: of information that seemed to anticipate what you wanted before
Speaker 1: you knew you wanted it. Some folks, like yours, truly
Speaker 1: found the feature really interesting. However, since they do a
Speaker 1: ton of research for lots of different stuff. I'm not
Speaker 1: always really interested in all that stuff. I'm doing it
Speaker 1: for my job. But my Now results sometimes feature a
Speaker 1: lot of news stories about things that aren't really that
Speaker 1: pertinent to me. I still get news stories about football,
Speaker 1: for example, and I am not really a football fan,
Speaker 1: but do keep the baseball updates coming because I am
Speaker 1: a baseball fan. The card style introduced by Google Now,
Speaker 1: in which each of these predictive search results sat in
Speaker 1: their own sort of individual cards, and then you could
Speaker 1: select a card to learn more about whatever the thing was.
Speaker 1: That would become the basis for many of the play
Speaker 1: apps that Google offered, and this would be a huge
Speaker 1: contribution of jelly Bean. It shaped the way Android operated
Speaker 1: and looked from that point. Moving forward, Google also introduced
Speaker 1: play services, which were extremely important for the company. And
Speaker 1: for app developers and almost entirely invisible to the end user.
Speaker 1: It concerns stuff going on in the heart of the
Speaker 1: Android operating system. With play Services, Google could send out
Speaker 1: tweaks to core components of the operating system and add
Speaker 1: new A p I features without the need for a
Speaker 1: full system update. Again, this would let Google bypass handset
Speaker 1: manufacturers and carriers to make these adjustments to the operating system.
Speaker 1: And why is that important, Well, it meant that app
Speaker 1: developers could be sure that the stuff they were creating
Speaker 1: would be able to run on most of the Android
Speaker 1: phones out in the market. So by this time, Android
Speaker 1: was rapidly becoming the dominant operating system for smartphones in
Speaker 1: the world. Now, again I want to stress this does
Speaker 1: not mean Android was superior to iOS. Rather, Apple was
Speaker 1: taking a very different approach in which you had to
Speaker 1: go through Apple to get a phone that was running
Speaker 1: iOS on it, and it was a premium experience. Android
Speaker 1: phones could run on just about anything, so there was
Speaker 1: a huge range of different hardware and a different price
Speaker 1: points out there. So adoption for Android skyrocketed because there
Speaker 1: was an Android phone for just about every budget, as
Speaker 1: opposed to the iPhone, which was still kind of a
Speaker 1: luxury item. So on the one hand, that was great
Speaker 1: news for developers because it meant they could potentially reach
Speaker 1: a much larger audience because there are more people with
Speaker 1: Android phones. But on the other hand, it also meant
Speaker 1: that there were folks out there with older handsets running
Speaker 1: older versions of Android, and the people with the latest,
Speaker 1: most up to date version might end up being a
Speaker 1: small sliver of the overall Android population, and that would
Speaker 1: discourage developers from embracing Android because the fragmentation in the
Speaker 1: operating system would mean that there was no guarantee someone
Speaker 1: with an Android phone could even run the app the
Speaker 1: developer was making the play Services update. Then Google could
Speaker 1: address this, creating more assurances that apps would run across
Speaker 1: a greater number of handsets, though obviously hardware limitations would
Speaker 1: still mean that some people wouldn't get a great result
Speaker 1: if they ran particularly demanding apps on their older phones.
Speaker 1: But this wouldn't stop the operating system updates, mind you.
Speaker 1: Those would continue on and there would be some important
Speaker 1: contributions made by some of them. I'll explain more in
Speaker 1: just a moment, but first let's take another quick break.
Speaker 1: Google pushed out a couple of updates still under the
Speaker 1: jelly Bean designation, so Android versions four point two and
Speaker 1: four point three were still technically jelly Bean. With four
Speaker 1: point four, the company again assigned a dessert nickname to
Speaker 1: the operating system, and this time it was a branded name,
Speaker 1: kit Cat from Nestley. The launch device for a kit
Speaker 1: Cat was the Nexus five from LG. And one of
Speaker 1: the things I think is really interesting about Android phones
Speaker 1: is that you have the Nexus line of devices, both
Speaker 1: phones and tablets, and they were made by several different manufacturers.
Speaker 1: So you can have an HTC neck Nexus phone, you
Speaker 1: can have a Samsung Nexus phone, you can have an
Speaker 1: LG Nexus phone. They're all made at different times for
Speaker 1: different operating system versions of Android. It's very interesting to
Speaker 1: me that you can have one model name spread across
Speaker 1: multiple manufacturers. At that point, the Nexus five had the
Speaker 1: largest screen for an Android phone at five inches, with
Speaker 1: the resolution of nineteen twenty by ten eighty pixels, so
Speaker 1: a much better resolution than those early Android phones. With KitKat,
Speaker 1: Google was able to improve on stuff under the hood
Speaker 1: to make memory usage more efficient. This made it possible
Speaker 1: to run current versions of Android on lower powered devices,
Speaker 1: which was important because developing countries were building out network
Speaker 1: infrastructure at that time, and that opened up a lot
Speaker 1: of opportunities to have Android phones in brand new markets. Also,
Speaker 1: it gave opportunities for people to get an unprecedented amount
Speaker 1: of access to connectivity apps. And more so, it was
Speaker 1: beneficial both for the company and for the people in
Speaker 1: those developing countries. Kit Kat was also pretty much transitioning
Speaker 1: away from the sci fi design that had been introduced
Speaker 1: with Honeycomb and ice Cream Sandwich. It would also be
Speaker 1: the uperating system that would power many of the first
Speaker 1: Android wear products. These are things like Android based smart watches.
Speaker 1: As far as I can tell, that particular category has
Speaker 1: never really taken off for Google. I don't think any
Speaker 1: Android based smart watch has seen enormous success in the market,
Speaker 1: not like the Apple Watch dead for Apple. Google would
Speaker 1: follow up KitKat with Lollipop, which I mentioned earlier in
Speaker 1: this episode. Lollipop was the first to use the Android
Speaker 1: run time environment for virtualization. It also introduced a new
Speaker 1: era at Google, the era of material design. This was
Speaker 1: not just a set of guidelines, but an actual design
Speaker 1: blueprint that Google gave third party developers to follow. This
Speaker 1: wasn't just for Android, but also for Chrome and all
Speaker 1: versions of Google apps, even those that would be hosted
Speaker 1: on other operating systems like iOS. So while Duarte had
Speaker 1: already shaped the design principles for Android apps, now he
Speaker 1: was working with a team to do the same thing
Speaker 1: across all of Google's apps and services, the idea being
Speaker 1: that if it was from Google, you should be able
Speaker 1: to tell. Duarte would actually leave Android and transition to
Speaker 1: a role in Google itself to help drive this initiative
Speaker 1: across the company. The material design aesthetic took inspiration from paper.
Speaker 1: Each layer a person would see would be like a
Speaker 1: sheet of paper on top of all the ones beneath it,
Speaker 1: and animation was given very much more focus in this
Speaker 1: version of Android. The goal was to have all elements
Speaker 1: animate onto the screen rather than just appear or pop
Speaker 1: into place, so they should scroll up into view or
Speaker 1: fly on into view. They shouldn't just appear. There should
Speaker 1: never just be a transformation of one screen into another.
Speaker 1: The result of all this was that, starting with Lollipop,
Speaker 1: the UI had a very different look and feel to it,
Speaker 1: and Lollipop was the first Android release to include the
Speaker 1: voice recognition feature, in which a user would say okay,
Speaker 1: follow by the word Google to activate the ability to
Speaker 1: speak commands to the phone directly. I tried very hard
Speaker 1: to avoid saying the activation phrase itself to spare all
Speaker 1: of those listening in or near Google devices from having
Speaker 1: to deal with the aftermath. If you listen to my
Speaker 1: recent episode about how this stuff works, you know that
Speaker 1: it's not always listening in on with a sense of it,
Speaker 1: you know, keeping track of what it is you're saying,
Speaker 1: like the phone is not spying on you. Rather, it's
Speaker 1: on a constant lookout for a digital footprint of an
Speaker 1: audio signal that indicates that the activation phrase has been spoken.
Speaker 1: So it's like a key sliding into a lock. Around
Speaker 1: this same time, in Andy Reuben, the guy who had
Speaker 1: founded Android the company and who was associated with the
Speaker 1: operating system at Google, thought of as the father of Android,
Speaker 1: left Google. Now. The official story at the time was
Speaker 1: that Reuben was leaving to start an incubator company to
Speaker 1: help startups that were focusing on hardware. He had already
Speaker 1: stopped running Android back in two thousand thirteen. He had
Speaker 1: transitioned over to working in Google's robotics division, and now
Speaker 1: he was leaving Google completely. Later on, it was revealed
Speaker 1: that Larry Page had actually asked Reuben to resign, and
Speaker 1: this was in the wake of sexual misconduct allegations that
Speaker 1: had been brought against Reuben. The details of those allegations
Speaker 1: are gross and they are horrible, So I'll just say
Speaker 1: that if the allegations are accurate, Paige probably should have
Speaker 1: just fired Reuben. But perhaps there was a worry of
Speaker 1: how this might be bad pr around the whole thing,
Speaker 1: and so I guess it was decided to keep things
Speaker 1: quiet for the sake of and I really hate this word,
Speaker 1: but for the sake of optics. And if so, if
Speaker 1: that were in fact the reason why, that strategy backfired
Speaker 1: big time because in it was revealed that Uben had
Speaker 1: left Google with a ninety million dollar exit package as
Speaker 1: well as leaving in the wake of these allegations. This
Speaker 1: sparked an enormous reaction within Google, with employees protesting and
Speaker 1: walking out upon discovering that a man accused of these
Speaker 1: horrible acts would end up walking away with nearly a
Speaker 1: hundred million dollars, and it's a dark stain on both
Speaker 1: Google and Android. In March, Google rolled out an update
Speaker 1: to Lollipop and introduced a new version of Android for cars,
Speaker 1: called Android Auto, so it's designed to work in car
Speaker 1: systems itself. It's the sort of thing that might power
Speaker 1: the information and entertainment systems within a car. Following Lollipop
Speaker 1: was Marshmallow in October two fifteen. This version introduced fingerprints
Speaker 1: scanning for stuff like unlocking the phone and authorizing apps.
Speaker 1: It was also introducing a feature called Google Now on Tap,
Speaker 1: and that was a particularly odd feature. The I behind
Speaker 1: it was you could hold down the home button on
Speaker 1: any screen that you were in, whether it was an app,
Speaker 1: maybe you were watching a video. But if you held
Speaker 1: down the home button button, what it would do is
Speaker 1: it would take a screenshot of whatever was on your
Speaker 1: screen at that second and send it off to Google,
Speaker 1: and then Google's AI and machine learning technology would analyze
Speaker 1: the image and return search results based on what it,
Speaker 1: quote unquote, thought you were interested in. Ultimately, this feature
Speaker 1: didn't get much traction. It didn't have a refined focus,
Speaker 1: so the chances of you getting the results you were
Speaker 1: hoping for weren't that great. It just made more sense
Speaker 1: to use the search feature for that kind of stuff,
Speaker 1: where you could craft a query to return exactly what
Speaker 1: you were looking for instead of just sending a picture
Speaker 1: and hoping that Google picks up on the right thing
Speaker 1: in that picture and doesn't just send you a bunch
Speaker 1: of random garbage. The Google Assistant service would eventually replace
Speaker 1: Google Now on Tap. Marshmallow also changed up how per
Speaker 1: missions work for apps. So in the past, when you
Speaker 1: downloaded an app that would need to get access to
Speaker 1: stuff on your phone's hardware, stuff like your phone's microphone
Speaker 1: or its camera, whatever that might be, you would get
Speaker 1: a permissions page listing all of the components the app
Speaker 1: wanted to have access to, and then you would authorize
Speaker 1: the app and it would get that access. But starting
Speaker 1: with Marshmallow, that changed. Instead, you would install an app
Speaker 1: and you would never see a permissions page during the
Speaker 1: installation phase. But the first time the app attempted to
Speaker 1: make use of one of those phone components, it would
Speaker 1: then ask permission. A little pop up would appear in
Speaker 1: front of you, and it would ask you to give
Speaker 1: permission for the app to access whatever it was it
Speaker 1: was trying to get access too. So if you downloaded
Speaker 1: like a camera app, and you activated it, you would
Speaker 1: then receive a notification asking you to permit the app
Speaker 1: access to your phone's camera. Or maybe not just your
Speaker 1: phone's camera, but maybe your photos file folder, and then
Speaker 1: you would have to either authorize it or say no,
Speaker 1: and then maybe even uninstalled the program. After Marshmallow came
Speaker 1: Nougat and Google's Pixel phones. Also recently, there was a
Speaker 1: class action lawsuit against Google that wrapped up around that
Speaker 1: first generation of Pixel phones, and if you owned one
Speaker 1: of those first generation Pixels, you could be due a
Speaker 1: small amount of compensation. As the first generation of Pixel
Speaker 1: phones suffered a few problems, such as the handsets microphone
Speaker 1: occasionally just not working anymore. Interestingly, I have a pixel too,
Speaker 1: in fact, to have a pixel two XL right next
Speaker 1: to me that keeps going off because it keeps hearing
Speaker 1: me say the word Google, and it actually happened with
Speaker 1: my phone to the main microphone on my phone doesn't work.
Speaker 1: The speaker phone microphone works, but the main microphone doesn't. Now,
Speaker 1: as far as I can tell, the pixel two is
Speaker 1: not covered in that lawsuit, so I'm just out of luck.
Speaker 1: Nougat added features like the ability to do picture and
Speaker 1: picture due to a recizeable app feature now built into Android.
Speaker 1: This would be more useful for stuff like Android TV
Speaker 1: or Android on tablet devices. Other updates were behind the scenes,
Speaker 1: stuff like support for file based encryption, so the things
Speaker 1: that are important but that we probably wouldn't notice as
Speaker 1: end users. NUGA would stick around for a good long while.
Speaker 1: They would get an update in late and then it
Speaker 1: would make way for Android version eight point oh also
Speaker 1: known as OREO another trademark name. Part of this update
Speaker 1: was something called Project Trouble, and Google released some pretty
Speaker 1: crazy marketing technos speak to describe what this was about.
Speaker 1: So I'm going to quote to you how Google described
Speaker 1: Project Trouble. Quote. It's Google's ambitious effort to re architect
Speaker 1: Android in order to establish a modular base in which
Speaker 1: the lower level code created by Silicon vendors is separated
Speaker 1: from the main Android operating system framework, so that the
Speaker 1: device manufacts can update the OS code without having to
Speaker 1: rely on Silicon vendors to refresh the lower level code
Speaker 1: for every release. End quote. Now, what that actually means
Speaker 1: is that Google was working on ways to smooth out
Speaker 1: the challenges that handset manufacturers were facing when it comes
Speaker 1: to supporting updates to Android, and the goal was to
Speaker 1: cut down on the delay between an OS update coming
Speaker 1: out from Google and the release that the handset manufacturers
Speaker 1: could commit to. And again this gets down to like
Speaker 1: very minute stuff. Largely we're talking about processor level concerns,
Speaker 1: and typically you would have a handset manufacturer they would
Speaker 1: have to work with its chip set, UH supplier, whatever
Speaker 1: company was making the chips that were in those handsets
Speaker 1: to make sure that it could interoperate with the Google
Speaker 1: Android system and then rolling that out to all of
Speaker 1: its users. So there were a lot of delays. Now,
Speaker 1: there were other technical improvements to Android as well, but
Speaker 1: it was largely small evolutionary improvements to a wide range
Speaker 1: of features on the operating system. With Oreo, Android nine
Speaker 1: point oh has the extremely generic name Pie. It was
Speaker 1: released about a year after Oreo came out. The user
Speaker 1: interface got another update with some elements like the clock
Speaker 1: moving to a different default position on the display. It
Speaker 1: was also a move away from the material design philosophy
Speaker 1: Duarte had introduced a few years earlier, or at least
Speaker 1: a refinement of that philosophy. So that philosophy had helped
Speaker 1: create a more cohesive look to Android and the apps
Speaker 1: on Android, but it had also created the effect of
Speaker 1: making things look a little too homogenized. They all look
Speaker 1: a little too similar. So to correct the course, Google
Speaker 1: now has an updated set of design principles and a
Speaker 1: suite of developer tools to help take the basic ideas
Speaker 1: behind material design, but to apply them more intelligently to
Speaker 1: apps and services. Designers are able to apply customized designs
Speaker 1: on top of the fundamental material design approach. So ideally
Speaker 1: apps built using these tools will look like they belong
Speaker 1: to the Android ecosystem, but they won't look like all
Speaker 1: the other Android apps out there. It won't be a
Speaker 1: cookie cutter kind of approach. This brings us up to
Speaker 1: the most recent version of Android, at least as of
Speaker 1: the recording of this podcast. Android ten point oh has
Speaker 1: eschewed the convention of using dessert names as code names
Speaker 1: for the operating system. The next letter would have been Q,
Speaker 1: so I guess quins the fruit was just out of consideration.
Speaker 1: Google has several Android statues on its campus commemorating the
Speaker 1: various releases of Android with appropriate versions of the Android
Speaker 1: bug droid like sometimes it's posing with doughnuts or a
Speaker 1: Claire's or whatever, you know, whatever the code name for
Speaker 1: the operating system was, I guess moving forward, that won't
Speaker 1: be necessary. The finn version of Android ten point oh
Speaker 1: launched on September three, two thousand nineteen. The latest version
Speaker 1: of the operating system adds in more protections for the
Speaker 1: end user in the form of granting apps permission to
Speaker 1: use stuff like location data or to gain access to
Speaker 1: media and photo files on the device. Now apps have to,
Speaker 1: you know, send those alerts to you when they want
Speaker 1: to make use of it, and it makes you more
Speaker 1: conscious of what your apps are actually trying to do.
Speaker 1: Another cool feature is that you can use an option
Speaker 1: to change background blur in a photo after you've already
Speaker 1: taken the picture. And there were already apps that would
Speaker 1: let you do this, whether your intent was artistic expression,
Speaker 1: maybe you just wanted to blur something that was kind
Speaker 1: of objectionable or distracting that out of the background, and
Speaker 1: and you want to have the focus be on whatever
Speaker 1: is in the foreground. Well, whatever the case, it's now
Speaker 1: natively supported by the operating system itself. Android ten also
Speaker 1: introduced a more pervasive dark mode, meant to help save
Speaker 1: battery life and use less light to illuminate the screen
Speaker 1: when the user is in a low light environment, thus
Speaker 1: the name. There's also a new feature called live Caption ing,
Speaker 1: which can dynamically add captions to videos that have been
Speaker 1: sent to you. So if a friend shoots a quick
Speaker 1: video and sends it as a video message, Android ten
Speaker 1: can actually attempt to create subtitles for the video dynamically.
Speaker 1: And I appreciate that feature a lot because my hearing
Speaker 1: is not as good as it used to be. Darn
Speaker 1: you punk rock shows. I haven't had a chance to
Speaker 1: see this actually used in action yet, so I have
Speaker 1: no idea how accurate it is. I'm just reminded of
Speaker 1: how terrible Google Voice was at transcribing language, at least
Speaker 1: at first, and I'm really curious if my mom sent
Speaker 1: me a video if Google would be able to caption
Speaker 1: it appropriately. Android ten also builds in more support for
Speaker 1: new form factors of smartphones, namely devices that have foldable screens.
Speaker 1: A large incentive to do this came in the form
Speaker 1: of the Samsung Galaxy Fold, which is a squar ish
Speaker 1: kind of tablet from Samsung that, as the name implies,
Speaker 1: has a hinge in the middle of this that goes
Speaker 1: down vertically along this sort of squarish tablet, and then
Speaker 1: you can fold it in half and you're meant to
Speaker 1: use it as a phone when it's folded long ways,
Speaker 1: and when it is done like that, it's closer to
Speaker 1: the dimensions of a typical smartphone, though much much much thicker,
Speaker 1: because you know you've just uh folded it on itself.
Speaker 1: When it's unfolded, it's again more like a small tablet.
Speaker 1: I think it looks pretty funky and weird, but it
Speaker 1: could very well be that the future of smartphones will
Speaker 1: be on foldable technology. So it's a good thing that
Speaker 1: Android now supports it, and that brings us more or
Speaker 1: less up to date with Android so far. Now, while
Speaker 1: I'm wrapping up, I want to give a recommendation for
Speaker 1: an article. It's titled the Updated History of Android, and
Speaker 1: it's on the amazing site Ours Technica. If you're not
Speaker 1: familiar with Ours Technica and you're a fan of this show,
Speaker 1: you should definitely check out that site. They have incredible
Speaker 1: articles on all sorts of technological topics. It's highly recommended.
Speaker 1: This particular article was written by Ron Amadeo, and Ron
Speaker 1: has done a phenomenal and exhaustive job going into way
Speaker 1: more detail about the development, the rollout, the evolution and
Speaker 1: the features of the various Android operating system versions. More
Speaker 1: more than I could ever do unless I wanted to
Speaker 1: just do you know, seven episodes about it. In fact,
Speaker 1: he's got thousands of words written about the beta versions
Speaker 1: of Android before Android Version one point oh ever came out.
Speaker 1: I didn't even really touch on that. So if you
Speaker 1: want to learn even more about what went on behind
Speaker 1: the scenes to create and develop Android, go check out
Speaker 1: that article. I will tell you it does leave off
Speaker 1: in sixteen that's when the last update was written for
Speaker 1: this article. But I figure after you've read thirty three
Speaker 1: pages of material, you're okay taking a short break. As
Speaker 1: for me, well, I recommend that you send me messages
Speaker 1: related to what you would like to hear on tech Stuff.
Speaker 1: If you've got a topic that you would like me
Speaker 1: to tackle, whether it's a company, a technology concept in tech,
Speaker 1: whatever it may be, send me a message. You can
Speaker 1: do so via email the addresses tech stuff at how
Speaker 1: stuff works dot com, or you can pop on over
Speaker 1: to Facebook or Twitter handle we use this tech stuff
Speaker 1: hs W send me a message there. Pop on over
Speaker 1: to tech stuff podcast dot com to check out the
Speaker 1: archive of all of our past episodes that have ever published.
Speaker 1: Plus you'll find a link to our online store where
Speaker 1: every purchase you make goes to help the show, and
Speaker 1: we greatly appreciate it, and I'll talk to you again
Speaker 1: really soon. Text Stuff is a production of I Heart
Speaker 1: Radio's How Stuff Works. Or more podcasts from my heart Radio,
Speaker 1: visit the i heart Radio app, Apple Podcasts, or wherever
Speaker 1: you listen to your favorite shows. H