Android Dumps Desserts

four point Oh. But before I go any further with that story, I thought I might take some time to describe what an operating system actually does from a high level, since I kind of skipped over that in the last episode. But in my defense, I really wanted to get to the actual Android stuff, all right, So let's go from the most basic explanations here and work our way up from there. A computer is essentially a machine that, through processing tons of complex calculations in a short amount of time,

can produce all sorts of different end results. Some of them can be pretty intuitive, like calculating a formula that's embedded in a spreadsheet program. That's very clearly a mathematical process. It's easy to understand. Some are a little less intuitive, like allowing you to make a video call to someone

who's on the other side of the world. But ultimately, a computer is taking information in the forms of zeros and ones, and it is performing various operations on that data to get results, which are then fed back to you in some appropriate way, depending upon whatever it is you're trying to do, but you know you'll be able to see it in a way that makes sense to you, as opposed to just a different string of zeros and ones, which would be useless to us. We run programs on

computers to get these results. So in the examples I've already mentioned, you would have some sort of spreadsheet program like Microsoft Excel, or some sort of video calling program like Skype. Microsoft has nothing to do with this episode, by the way, Obviously I'm talking about androids, so but that's just to give you an example of programs that exist on computers. These programs need to interface with the hardware that's actually doing all of those calculations and gathering

that information. Now, in the old old days of computers, programmers would build their programs into the machines themselves. They would program on what we would call bare metal, and computers would only do very specific tasks. By the time we got to general programmable computers, we could run different programs on the same machines. Programmers would write these four specific computers, and the program instructions were essentially telling the

hardware what to do. And this goes all the way from the era where you would actually physically unplug parts of the computer system and plug it into different parts, up to where you might program it in a series of punch cards that would be read by computer, and then the computer would follow whatever the instructions were that

the punch cards indicated. These are all various examples of programs and computers, but as computers and programs evolved, it became necessary to create some sort of liaison between the bare metal of the hardware underneath and the programs that would run on top of it. And the operating system

is kind of like a foreman or a supervisor. It's in charge of managing stuff like computer memory and the order of operations, and with modern computer devices that also handles stuff like multitasking, making sure each instance of a program has the resources it needs to run, or in some cases even throttling those resources that are going to a program that might be in the background while another program is taking center stage. It's sort of dynamically managing

all these different resources. Most of the operating systems we encounter today incorporate a graphical user interface or gooey, in which little icon represent computer processes. Now, in the old days and with some modern line command systems, you would actually type out a command to start a program dot e x C file. So, for example, I remember using our old two eight six PC back when I was

a kid. We had MS DOSS running on it. That was a line command operating system, and you would type in commands to go to a particular file directory in order to run a program like say Wolfenstein. The gooey for home PCs became popular after the introduction of the Macintosh computer from Apple and the Windows operating system from Microsoft the following year, though really Windows truly took off

after Windows three point one. Now for pretty obvious reasons, the operating systems we find on smartphones feature gooey's, Apple's iOS, Android and other smartphone OS flavors. All of us interface with programs through touch screen controls, or, as was the case with older Android phones, with physical keyboards and maybe even a track ball controller. The old g one had one of those those icons on the screen represent processes, programs,

initiation programs, executable files. So selecting one of these icons initiates the sequence to start a program sending instructions to the operating system underneath to manage the resources that are required to make the program go. Computer programmers and engineers describe operating systems as existing as a stack of various functions. Now these are not physical layers or anything like that.

It's more of a way for us to think about the different functions the operating system must perform and grouping those functions together in a way that makes sense. So in general, you can think of if you think of a stack like a vertical stack, almost like a stack of wooden blocks. At the very bottom or the foundation of the stack, the part that's against the bare metal or the hardware of the device itself would be the

kernel that is the core of the operating system. These are the functions that are are most directly interfacing with the hardware stuff like processors and circuits and all the stuff that's doing all the number crunching androids. Foundation is based specifically around the Linux kernel. So, as I said, the kernel is the core of the operating system. It has complete control over the hardware. Lenox is an open source operating system, has a large community of developers and

programmers contributing to it. And because of this huge community, things like security vulnerabilities and bugs are typically discovered pretty quickly and they can be fixed pretty quickly too. Now an Android that's just the kernel. Android itself is not Lennox. So the next layer up from the Lenox kernel and Android is called the hardware abstraction layer or how which is an ominous at all. Sorry, I can't do that, Dave.

This layer provides a software environment through which the programs higher up on the stack can interface to access the components they need, such as let's say it's the handset speaker. Let's say that it's a music program. Well it the program would then send messages to the hardware abstraction layer to say I need to get access to the speaker

and play this audio file through the speaker. So how would kind of handle that and then relay the specific requirements further down to the Linux kernel to get all the way down to the speaker level. So other examples would be the Bluetooth devices. You know, Bluetooth devices connect to a phone via the Bluetooth transmitter. Well, the hardware abstraction layer provides the resources needed for an app that needs to have access to a Bluetooth transmitter to actually

get that access. So this way, developers don't have to create stuff for specific handsets, but rather for any Android handset. They don't have to worry if one Android phone is built in a very different way to another Android phone. Now two blocks share the next layer in the stack. They are the Android run time block and the native c C plus plus libraries. Okay, so the Android run Time or a RT serves as a kind of envelope

for processes. Alright, think of like every program that you're running on a phone, like you're actually running that program on the phone. It exists in kind of a think of it as like a box. It keeps each process separate. So let's say that you've got your photo app running and you're also listening to something on the I Heart radio app, for example, shameless Plug. Let's say you're listening to both of those, so you've got both processes running

at the same time. Well, you don't want them just running on the phone with no division between them, because if something were to happen to one of those processes, it could affect the other one. Let's say that the photo app has a failure for some reason, something goes wrong and it freezes. Well, you don't want that to affect the other apps running on your device. So the best thing you could do is create what are called virtual machines, which I've talked about quite a bit in

recent episodes. These virtual machines act as silos. They act as as uh, separated and protected areas in which a process can run without it affecting anything else, and each of them will get the resources needed to run that process.

So again, the operating system has to look at the requirements of each of those processes, the photo app and the I Heart Radio app, and say, all right, well, I need to dedicate this much memory and processing power to run this one, and this much memory processing power to run this other one, and that all that stuff

is happening in the background. We as users are completely not you know, aware of this, unless something were to go wrong, in which case we might say, oh, the photo app crashed, but at least I'm still listening to my music, so really you don't notice it happening. Now I should add that this particular feature was really added in starting with Android version five point oh also known as Lollipop. So this is technically jumping ahead in our story a little bit, but this is the part of

the stack that lets stuff run independently of one another. Now, before Android run time, before that was the virtualization strategy that Google was using, they did rely on a different virtualization strategy with a process virtual machine software called dal vic d A l v I K. That's what did essentially the same sort of job as the Android run time component up through Android version four point four, also

known as get cat. So Android did have this earlier, but I figured it would be more and make more sense to talk about Android runtime because that's what's currently being used in Android operating system phones today. Now, as for the libraries I mentioned earlier, In programming, a library is a collection of pre compiled routines that programs can

take advantage of. So when you think of a program, a program is really a series of instructions for a computer, and some of those instructions are going to be common ones, ones that you would use in lots of different types of programs. So it doesn't make a whole lot of sense to have to go back and re established that path every single time you want to build a program. It would be time consuming, it would be wasteful. So libraries are these pre compiled routines that mean that you

you just plug those in for that part. And this is a very, very granular approach. We'll get into a slightly larger version of this in just a second. Library is dramatically reduced the amount of work programmers have to do to build out applications. So if a program needs to access a particular process, a module in the library can be plugged into the program as a kind of shortcut. So it's an invaluable resource and pretty much all programming

environments take advantage of them. Now, next up in the stack we have the Java a p I framework. This includes all the basic components you need to build out apps. So it's kind of like taking that concept I just talked about with the library, you know, these these little

pre compiled routines and building on that. Now we're talking about larger building blocks, not super teeny tiny ones, but that can still be used to put together basic functions of various applications and it's a huge help to developers. The framework has the building blocks or puzzle pieces that programmers can use to to build out those apps. And

this is the environment in which programmers actually operate. They rely on the a p I, which stands for Application Programming Interface in order to build out the apps, whether it's a video editing app or a puzzle game or whatever it might be. Now, the topmost layer of this stack is what it tends to be that well, it

is the system apps themselves. So again, if you think of that bottom layer of the stack as the foundation that rests against the bare metal of the handset, this topmost layer, you can think of, is the layer that actually faces the end user. It's it's what we interact with when we're using our phones. So this is the side that we actually see. It includes stuff like the dialer application, you know, in case we want to use our smartphone as a phone, or maybe the email app

or well you get the idea. It's all those basic apps. Now, these are intended to be the basic apps that any other third party app could tap into for certain capabilities. Now, Google made the decision to allow users, carriers, and or handset manufacturers the chance to swap out many, but not all, of these system apps for something from a third party. So if you don't like let's say the basic on screen keyboard that comes standard with Android, you could change that.

You could switch it out for a different on screen keyboard created from a different put third party, and that would become the new system level app for that particular feature. Google does restrict this for certain functions. Not every system level app is available to be swapped out. For example, the settings app, you can't do that, and that gives you more fine tune control over a lot of the handsets settings. So that's the reason why Google says, no,

this one is off limits. We're going to keep it as is. But otherwise it's pretty fair game. And that's an overview of what an operating system is and how the Android OS stacks up, so to speak. And it's good to remember that Android is built on top of an older operating system, that being Linux. Because Linux is open source, Reuben and his team of developers Andy Rubin, that is, could tweak the Linux kernel to suit their own needs when they were building out Android. Anyone can

do that because it's open source. And another point that's important to stress. I'm really just talking about the kernel that component just above the bare metal the interfaces directly with the hardware of the handset. And the reason it's important to remember that is you can't just run Linux applications on an Android device, nor can you run Android apps on a Linux computer, at least without not without some sort of emulator. And that's because those layers that

stack on top of the kernel are different. Between Linux and Android, the software libraries necessary to run certain processes are different, and because of those differences, there's been some debate over whether or not you should actually call Android a Linux distribution or dis s trow so. In Linux speak, a distribution is a specific implementation of the Linux operating system, and there are hundreds of different distros out there now.

I think the debate is largely unimportant because it remains that the two different operating systems are different enough that you can't port apps across environments without doing a lot of extra legwork. Now, before I take a quick break, I do want to give a quick recap of what was going on. When I finished the last episode. Google had released Android three point oh a k A Honeycomb, which I'll talk about a little bit more in a second, and this was a version of Android that Google had

designed specifically for Android tablets. It was the first version of Android that UI expert Matthias Duarte really had a hand in, as he had been brought in shortly before its predecessor, Gingerbread, had been pushed out to users. So Duarte didn't have a whole lot of opportunity to put his mark on Gingerbread, but he definitely did a lot

more work on honey Home. Duarte also faced a big challenge because Google is a company built by and arguably some would say four engineers, and the Android phones definitely reflected that. I say that as someone who owned a first generation Android phone. They worked, but they weren't necessarily intuitive. The design didn't establish a coherent aesthetic. There was no defining trait for an Android app apart from the fact that it was running on an Android phone. They all

looked wildly different. There was no cohesive vision. Convincing engineers that design was an important component wasn't always easy, but Duarte figured he was up for the challenge. I'll talk a little bit more about that in just a second, but first let's take a quick break. Okay, let's go back to Honeycomb for a second. The tablet only version of Android. Google itself has admitted that the development of

Honeycomb was rushed. They didn't have a whole lot of time to get it out, and it was a frantic response. You could think to Apple's iPad launch, which managed to do what no other tablet had done up to that point. It was able to capture the attention of the mainstream public. Tablet computers had been around for a while, and they weren't brand new when the iPad came out. They had been a thing for years, but they had previously been fairly niche gadgets used by a few different industries, like

in medicine. Nurses were using them things like that for very specific tasks, and largely they were ignored by the general public. In fact, tablet computers had been such a non component in everyday computing that I famously, and if you want to search the back catalog of tech stuff you can find out where I did this. I famously

predicted the iPad itself would flop. I mean, no one had managed to make tablet computers useful enough for anyone to actually want one, So I was a bit off on that particular prediction, But I don't even know to this day if I was off about them truly being usable. Maybe this speaks more to my inability to incorporate tablets into my day to day life. So I very rarely

use them myself. If I do use a tablet, I typically turn it into a super lightweight laptop computer instead, like I have a Microsoft Surface that I use for that purpose. I love it as a very lightweight laptop, but I don't know that I would get as much use out of it if I used it strictly as a tablet, simply because that's not how I work. However,

I should say I gotta concede. The Apple iPad was, without any qualifiers, a huge success, and Google recognized that too, and so there was a strong incentive to develop a version of Android aimed at the tablet experience. In some ways, this helped the people who were building Honeycomb because the version of Android would only be used for tablets, and that helped cut down on the sheer variety of things that had to consider, like screen size or access to

a cell phone. Those were off the table. Because most tablets were in a pretty small range of sizes, they didn't have to worry about the huge number of variables that they would encounter if they were designing and operating

system for smartphones. But it also meant that Google needed to make sure the hardware manufacturers were gonna play by the rules because previous versions of Android were all open source, so after they were pushed out after a certain amount of time, Google would allow the code to be freely available for anyone to look at, to use, and etcetera.

But Google did not want some manufacturer out there trying to push Honeycomb out on a phone like device was not intended to do that, so they said, while we're going to instead of releasing this as open source, we're going to keep it to ourselves, and manufacturers would have to go through Google to get Honeycomb for their Android

based tablets. Upon its initial release, Honeycomb lacks support for some pretty important processes, like it didn't have support for Adobe Flash, which at the time was still a very important component for web content, and Honeycomb was a bit

buggy when it was first released. There were a lot of little performance issues and that, paired with the lack of open source, would end up hurting the launch of Honeycomb, and so a lot of people didn't really care for the Android tablets that were coming out of that time, and that's not really the fault of the OS necessarily, but it didn't end up doing it didn't do the OS any favors either. The design decisions were largely admired. Duarte had created a more cohesive design approach and he

leaned really hard on sci fi like visuals. A lot of people referred to it as a tron like interface, and it was called a hologram interface. Within Google, Google built in some new features that would give handset manufacturers

more options. Uh the Zoom, the XO o M, the first tablet to feature Honeycomb, had no hardware buttons, so Google had to build in on screen capabilities to do stuff like navigate to the home page of the Android operating system, pull up menus, that kind of stuff, the stuff that previously had dedicated hardware buttons on Android devices, because up to that point that's what you had to have if you had an Android phone. It had a physical menu button, a physical home button, a physical back button.

But starting with Honeycomb, Google was able to get rid of some of that and they built in on screen versions of those functions. That design element would carry over into ice Cream Sandwich, which was the next version for actual Android smartphones, it was toned down a bit. However, The Honeycomb was full on tron but ice Cream Sandwich was sort of tron light. They eased off a bit

on that design approach. This version of Android debut on the Samsung Galaxy Nexus, a phone that had a seven resolution screen, which was a big step up from the earlier Android phones, and the additions in Honeycomb for on screen controls meant the Galaxy Nexus and most Android phones that were to follow no longer needed those physical buttons. Other than maybe a power button and volume controls, those would typically be physical, everything else would be an on

screen button. Uh. This let designers create more sleek and aesthetically pleasing handsets to dedicate more of the space of the phone to the screen itself, and it put the more chunky origins of Android phones deep into the past. Ice Cream Sandwich also had a lot of UI updates, like a system bar for the top of the phone that would hold stuff like notifications, and there was also a system bar at the bottom of the phone that would allow users to navigate home, back and hit the

menu button. Some of the icons got not just a graphical facelift, but also a name change, so what was previously referred to as contacts now became people. For example, it seems a little less cold, so I'm I'm in favor of it. It's an Android that's learning to love. In January two twelve, Duarte led the effort to publish a set of guidelines called Android Design. The site would act as a tutorial for app developers so they can make apps in such a way as to fit within

the overall aesthetic of Android operating system. This was something that Apple had been doing for a while. In fact, over at Apple, it was notorious for the company to deny apps from being able to go into the App Store, and one of the many reasons that Apple might give is that the aesthetic of the app didn't match Apple's overall aesthetic for iOS, and so the designers will have to go back and retool the look and u I of their app. So that was more in line with

Apple's design policies. Google would be a lot more lenient than Apple in those days, but Duarte saw the value of establishing a definable look so that when people saw something they would know, oh, that's an Android app, as opposed to that's on some sort of mobile device. A few months after the introduction of ice Cream Sandwich, Google made some more changes to some of its primary apps.

The company introduced the Google Play banner of apps. So you had Google Play Music, Google Play Books, Google Play Store, etcetera. And you could buy content through the Google Play Store like you Let's say you want to buy a movie or maybe a record album. Anyway, the content would end up going to the appropriate apps library, so was all

the management stuff was done in the background. You didn't have to worry about it, and you didn't have to go through the individual apps in order to access the store. This was the first example of Google doing an out of cycle update for individual apps, and it would mean more freedom to update apps without having to wait for a full operating system cycle update, a full version update in other words. And this approach also managed to do

something that would have a big a big impact on users. Earlier, Google would issue updates in a new version of the operating system, or at least an update to the current version, and it would then make that update available for all the service carriers and handset manufacturers to push out to

users on the network. But that meant that Android phone owners might be waiting for a while to get the latest update, just because the carrier they used had and pushed it out yet, or because there are delays in the handset manufacturers making sure that the chips in their handsets could accommodate the new operating system. But the app updates were different. Google could push those out through the

Play Store and bypass the entire operating system update. If it was just adjusting something, you know, relatively small in one of these apps, those were completely under Google's control, so in that way, Google could deliver new features to users without them getting frustrated while waiting for their carrier to roll out the latest OS update. And in April two twelve, Google would go back to selling devices directly

to customers through the Google Play Store. They had done this with the launch of the Nexus one smartphone, but it essentially discontinued the practice shortly thereafter. Then it would open up a new market for Google, one that would include not just smartphones and tablets, but eventually also stuff

like smart thermostats and Chromebook laptops. So Google started to get more into the business of selling hardware directly to users, more like Apple in that regard, although Google was relying on third party manufacturers to actually design the hardware, at

least until we acquired Nest. The next version of Android to come out of Google was version four point one, also known as jelly Bean, and starting with jelly Bean, Google hidden operating system update cycle that would typically last about half a year, so you could expect to updates each year for several operating system updates in a row. Jelly Bean featured some more updates to the user interface. It also aimed to create more smooth animations and scrolling.

Google managed to make some steps forward with tablets as well. A sous had created a seven inch tablet that would be branded the Nexus seven and that would set a form factor for many Android tablets to follow. It was not so successful in the ten inch tablet size form factor.

I mean, I had it pretty much sewned that up, but they were able to get some traction on this smaller version the seven inch form factor, and in fact they were successful enough that for once, Apple would end up following suit by later launching the iPad many largely as a response to this. Jelly Bean also introduced the Google Now feature a type of predictive search results based

upon user activities and locations. Some people found this to be a bit creepy because Now would serve up cards of information that seemed to anticipate what you wanted before you knew you wanted it. Some folks, like yours, truly found the feature really interesting. However, since they do a ton of research for lots of different stuff. I'm not always really interested in all that stuff. I'm doing it

for my job. But my Now results sometimes feature a lot of news stories about things that aren't really that pertinent to me. I still get news stories about football, for example, and I am not really a football fan, but do keep the baseball updates coming because I am a baseball fan. The card style introduced by Google Now, in which each of these predictive search results sat in their own sort of individual cards, and then you could select a card to learn more about whatever the thing was.

That would become the basis for many of the play apps that Google offered, and this would be a huge contribution of jelly Bean. It shaped the way Android operated and looked from that point. Moving forward, Google also introduced play services, which were extremely important for the company. And for app developers and almost entirely invisible to the end user. It concerns stuff going on in the heart of the

Android operating system. With play Services, Google could send out tweaks to core components of the operating system and add new A p I features without the need for a full system update. Again, this would let Google bypass handset manufacturers and carriers to make these adjustments to the operating system. And why is that important, Well, it meant that app developers could be sure that the stuff they were creating would be able to run on most of the Android

phones out in the market. So by this time, Android was rapidly becoming the dominant operating system for smartphones in the world. Now, again I want to stress this does not mean Android was superior to iOS. Rather, Apple was taking a very different approach in which you had to go through Apple to get a phone that was running iOS on it, and it was a premium experience. Android phones could run on just about anything, so there was a huge range of different hardware and a different price

points out there. So adoption for Android skyrocketed because there was an Android phone for just about every budget, as opposed to the iPhone, which was still kind of a luxury item. So on the one hand, that was great news for developers because it meant they could potentially reach a much larger audience because there are more people with

Android phones. But on the other hand, it also meant that there were folks out there with older handsets running older versions of Android, and the people with the latest, most up to date version might end up being a small sliver of the overall Android population, and that would discourage developers from embracing Android because the fragmentation in the operating system would mean that there was no guarantee someone with an Android phone could even run the app the

developer was making the play Services update. Then Google could address this, creating more assurances that apps would run across a greater number of handsets, though obviously hardware limitations would still mean that some people wouldn't get a great result if they ran particularly demanding apps on their older phones. But this wouldn't stop the operating system updates, mind you. Those would continue on and there would be some important

contributions made by some of them. I'll explain more in just a moment, but first let's take another quick break. Google pushed out a couple of updates still under the jelly Bean designation, so Android versions four point two and four point three were still technically jelly Bean. With four point four, the company again assigned a dessert nickname to the operating system, and this time it was a branded name, kit Cat from Nestley. The launch device for a kit

Cat was the Nexus five from LG. And one of the things I think is really interesting about Android phones is that you have the Nexus line of devices, both phones and tablets, and they were made by several different manufacturers. So you can have an HTC neck Nexus phone, you can have a Samsung Nexus phone, you can have an LG Nexus phone. They're all made at different times for different operating system versions of Android. It's very interesting to me that you can have one model name spread across

multiple manufacturers. At that point, the Nexus five had the largest screen for an Android phone at five inches, with the resolution of nineteen twenty by ten eighty pixels, so a much better resolution than those early Android phones. With KitKat, Google was able to improve on stuff under the hood

to make memory usage more efficient. This made it possible to run current versions of Android on lower powered devices, which was important because developing countries were building out network infrastructure at that time, and that opened up a lot of opportunities to have Android phones in brand new markets. Also, it gave opportunities for people to get an unprecedented amount of access to connectivity apps. And more so, it was beneficial both for the company and for the people in

those developing countries. Kit Kat was also pretty much transitioning away from the sci fi design that had been introduced with Honeycomb and ice Cream Sandwich. It would also be the uperating system that would power many of the first Android wear products. These are things like Android based smart watches. As far as I can tell, that particular category has never really taken off for Google. I don't think any Android based smart watch has seen enormous success in the market,

not like the Apple Watch dead for Apple. Google would follow up KitKat with Lollipop, which I mentioned earlier in this episode. Lollipop was the first to use the Android run time environment for virtualization. It also introduced a new era at Google, the era of material design. This was not just a set of guidelines, but an actual design

blueprint that Google gave third party developers to follow. This wasn't just for Android, but also for Chrome and all versions of Google apps, even those that would be hosted on other operating systems like iOS. So while Duarte had already shaped the design principles for Android apps, now he was working with a team to do the same thing across all of Google's apps and services, the idea being that if it was from Google, you should be able

to tell. Duarte would actually leave Android and transition to a role in Google itself to help drive this initiative across the company. The material design aesthetic took inspiration from paper. Each layer a person would see would be like a sheet of paper on top of all the ones beneath it, and animation was given very much more focus in this

version of Android. The goal was to have all elements animate onto the screen rather than just appear or pop into place, so they should scroll up into view or fly on into view. They shouldn't just appear. There should never just be a transformation of one screen into another.

The result of all this was that, starting with Lollipop, the UI had a very different look and feel to it, and Lollipop was the first Android release to include the voice recognition feature, in which a user would say okay, follow by the word Google to activate the ability to speak commands to the phone directly. I tried very hard to avoid saying the activation phrase itself to spare all of those listening in or near Google devices from having

to deal with the aftermath. If you listen to my recent episode about how this stuff works, you know that it's not always listening in on with a sense of it, you know, keeping track of what it is you're saying, like the phone is not spying on you. Rather, it's on a constant lookout for a digital footprint of an audio signal that indicates that the activation phrase has been spoken.

So it's like a key sliding into a lock. Around this same time, in Andy Reuben, the guy who had founded Android the company and who was associated with the operating system at Google, thought of as the father of Android, left Google. Now. The official story at the time was that Reuben was leaving to start an incubator company to help startups that were focusing on hardware. He had already

stopped running Android back in two thousand thirteen. He had transitioned over to working in Google's robotics division, and now he was leaving Google completely. Later on, it was revealed that Larry Page had actually asked Reuben to resign, and this was in the wake of sexual misconduct allegations that had been brought against Reuben. The details of those allegations are gross and they are horrible, So I'll just say that if the allegations are accurate, Paige probably should have

just fired Reuben. But perhaps there was a worry of how this might be bad pr around the whole thing, and so I guess it was decided to keep things quiet for the sake of and I really hate this word, but for the sake of optics. And if so, if that were in fact the reason why, that strategy backfired big time because in it was revealed that Uben had left Google with a ninety million dollar exit package as

well as leaving in the wake of these allegations. This sparked an enormous reaction within Google, with employees protesting and walking out upon discovering that a man accused of these horrible acts would end up walking away with nearly a hundred million dollars, and it's a dark stain on both Google and Android. In March, Google rolled out an update to Lollipop and introduced a new version of Android for cars, called Android Auto, so it's designed to work in car

systems itself. It's the sort of thing that might power the information and entertainment systems within a car. Following Lollipop was Marshmallow in October two fifteen. This version introduced fingerprints scanning for stuff like unlocking the phone and authorizing apps. It was also introducing a feature called Google Now on Tap, and that was a particularly odd feature. The I behind it was you could hold down the home button on any screen that you were in, whether it was an app,

maybe you were watching a video. But if you held down the home button button, what it would do is it would take a screenshot of whatever was on your screen at that second and send it off to Google, and then Google's AI and machine learning technology would analyze the image and return search results based on what it, quote unquote, thought you were interested in. Ultimately, this feature didn't get much traction. It didn't have a refined focus, so the chances of you getting the results you were

hoping for weren't that great. It just made more sense to use the search feature for that kind of stuff, where you could craft a query to return exactly what you were looking for instead of just sending a picture and hoping that Google picks up on the right thing in that picture and doesn't just send you a bunch of random garbage. The Google Assistant service would eventually replace Google Now on Tap. Marshmallow also changed up how per

missions work for apps. So in the past, when you downloaded an app that would need to get access to stuff on your phone's hardware, stuff like your phone's microphone or its camera, whatever that might be, you would get a permissions page listing all of the components the app wanted to have access to, and then you would authorize the app and it would get that access. But starting

with Marshmallow, that changed. Instead, you would install an app and you would never see a permissions page during the installation phase. But the first time the app attempted to make use of one of those phone components, it would then ask permission. A little pop up would appear in front of you, and it would ask you to give permission for the app to access whatever it was it

was trying to get access too. So if you downloaded like a camera app, and you activated it, you would then receive a notification asking you to permit the app access to your phone's camera. Or maybe not just your phone's camera, but maybe your photos file folder, and then you would have to either authorize it or say no, and then maybe even uninstalled the program. After Marshmallow came

Nougat and Google's Pixel phones. Also recently, there was a class action lawsuit against Google that wrapped up around that first generation of Pixel phones, and if you owned one of those first generation Pixels, you could be due a small amount of compensation. As the first generation of Pixel phones suffered a few problems, such as the handsets microphone

occasionally just not working anymore. Interestingly, I have a pixel too, in fact, to have a pixel two XL right next to me that keeps going off because it keeps hearing me say the word Google, and it actually happened with my phone to the main microphone on my phone doesn't work. The speaker phone microphone works, but the main microphone doesn't. Now, as far as I can tell, the pixel two is not covered in that lawsuit, so I'm just out of luck.

Nougat added features like the ability to do picture and picture due to a recizeable app feature now built into Android. This would be more useful for stuff like Android TV or Android on tablet devices. Other updates were behind the scenes, stuff like support for file based encryption, so the things that are important but that we probably wouldn't notice as end users. NUGA would stick around for a good long while.

They would get an update in late and then it would make way for Android version eight point oh also known as OREO another trademark name. Part of this update was something called Project Trouble, and Google released some pretty crazy marketing technos speak to describe what this was about. So I'm going to quote to you how Google described

Project Trouble. Quote. It's Google's ambitious effort to re architect Android in order to establish a modular base in which the lower level code created by Silicon vendors is separated from the main Android operating system framework, so that the device manufacts can update the OS code without having to rely on Silicon vendors to refresh the lower level code

for every release. End quote. Now, what that actually means is that Google was working on ways to smooth out the challenges that handset manufacturers were facing when it comes to supporting updates to Android, and the goal was to cut down on the delay between an OS update coming out from Google and the release that the handset manufacturers could commit to. And again this gets down to like

very minute stuff. Largely we're talking about processor level concerns, and typically you would have a handset manufacturer they would have to work with its chip set, UH supplier, whatever company was making the chips that were in those handsets to make sure that it could interoperate with the Google Android system and then rolling that out to all of

its users. So there were a lot of delays. Now, there were other technical improvements to Android as well, but it was largely small evolutionary improvements to a wide range of features on the operating system. With Oreo, Android nine point oh has the extremely generic name Pie. It was released about a year after Oreo came out. The user interface got another update with some elements like the clock

moving to a different default position on the display. It was also a move away from the material design philosophy Duarte had introduced a few years earlier, or at least a refinement of that philosophy. So that philosophy had helped create a more cohesive look to Android and the apps on Android, but it had also created the effect of making things look a little too homogenized. They all look

a little too similar. So to correct the course, Google now has an updated set of design principles and a suite of developer tools to help take the basic ideas behind material design, but to apply them more intelligently to apps and services. Designers are able to apply customized designs on top of the fundamental material design approach. So ideally apps built using these tools will look like they belong to the Android ecosystem, but they won't look like all

the other Android apps out there. It won't be a cookie cutter kind of approach. This brings us up to the most recent version of Android, at least as of the recording of this podcast. Android ten point oh has eschewed the convention of using dessert names as code names for the operating system. The next letter would have been Q, so I guess quins the fruit was just out of consideration.

Google has several Android statues on its campus commemorating the various releases of Android with appropriate versions of the Android bug droid like sometimes it's posing with doughnuts or a Claire's or whatever, you know, whatever the code name for the operating system was, I guess moving forward, that won't be necessary. The finn version of Android ten point oh

launched on September three, two thousand nineteen. The latest version of the operating system adds in more protections for the end user in the form of granting apps permission to use stuff like location data or to gain access to media and photo files on the device. Now apps have to, you know, send those alerts to you when they want to make use of it, and it makes you more conscious of what your apps are actually trying to do.

Another cool feature is that you can use an option to change background blur in a photo after you've already taken the picture. And there were already apps that would let you do this, whether your intent was artistic expression, maybe you just wanted to blur something that was kind of objectionable or distracting that out of the background, and and you want to have the focus be on whatever is in the foreground. Well, whatever the case, it's now

natively supported by the operating system itself. Android ten also introduced a more pervasive dark mode, meant to help save battery life and use less light to illuminate the screen when the user is in a low light environment, thus the name. There's also a new feature called live Caption ing, which can dynamically add captions to videos that have been

sent to you. So if a friend shoots a quick video and sends it as a video message, Android ten can actually attempt to create subtitles for the video dynamically. And I appreciate that feature a lot because my hearing is not as good as it used to be. Darn you punk rock shows. I haven't had a chance to see this actually used in action yet, so I have

no idea how accurate it is. I'm just reminded of how terrible Google Voice was at transcribing language, at least at first, and I'm really curious if my mom sent me a video if Google would be able to caption it appropriately. Android ten also builds in more support for new form factors of smartphones, namely devices that have foldable screens.

A large incentive to do this came in the form of the Samsung Galaxy Fold, which is a squar ish kind of tablet from Samsung that, as the name implies, has a hinge in the middle of this that goes down vertically along this sort of squarish tablet, and then you can fold it in half and you're meant to use it as a phone when it's folded long ways, and when it is done like that, it's closer to the dimensions of a typical smartphone, though much much much thicker,

because you know you've just uh folded it on itself. When it's unfolded, it's again more like a small tablet. I think it looks pretty funky and weird, but it could very well be that the future of smartphones will be on foldable technology. So it's a good thing that Android now supports it, and that brings us more or less up to date with Android so far. Now, while I'm wrapping up, I want to give a recommendation for an article. It's titled the Updated History of Android, and

it's on the amazing site Ours Technica. If you're not familiar with Ours Technica and you're a fan of this show, you should definitely check out that site. They have incredible articles on all sorts of technological topics. It's highly recommended. This particular article was written by Ron Amadeo, and Ron has done a phenomenal and exhaustive job going into way more detail about the development, the rollout, the evolution and

the features of the various Android operating system versions. More more than I could ever do unless I wanted to just do you know, seven episodes about it. In fact, he's got thousands of words written about the beta versions of Android before Android Version one point oh ever came out. I didn't even really touch on that. So if you want to learn even more about what went on behind the scenes to create and develop Android, go check out

that article. I will tell you it does leave off in sixteen that's when the last update was written for this article. But I figure after you've read thirty three pages of material, you're okay taking a short break. As for me, well, I recommend that you send me messages related to what you would like to hear on tech Stuff. If you've got a topic that you would like me to tackle, whether it's a company, a technology concept in tech,

whatever it may be, send me a message. You can do so via email the addresses tech stuff at how stuff works dot com, or you can pop on over to Facebook or Twitter handle we use this tech stuff hs W send me a message there. Pop on over to tech stuff podcast dot com to check out the archive of all of our past episodes that have ever published. Plus you'll find a link to our online store where every purchase you make goes to help the show, and we greatly appreciate it, and I'll talk to you again

really soon. Text Stuff is a production of I Heart Radio's How Stuff Works. Or more podcasts from my heart Radio, visit the i heart Radio app, Apple Podcasts, or wherever you listen to your favorite shows. H