# Androids ## Metadata * Author: [Chet Haase](https://www.amazon.comundefined) * ASIN: B09QPMNWS5 * ISBN: 1737354829 * Reference: https://www.amazon.com/dp/B09QPMNWS5 * [Kindle link](kindle://book?action=open&asin=B09QPMNWS5) ## Highlights the beginning, Android was building a digital camera platform called FotoFarm. — location: [844](kindle://book?action=open&asin=B09QPMNWS5&location=844) ^ref-59890 --- provide an operating system for digital cameras. The software they envisioned would enable better UIs and networking, along with the ability to run apps. Combined with superior camera hardware, they would push the boundaries of photographic and imaging functionality and experience. — location: [849](kindle://book?action=open&asin=B09QPMNWS5&location=849) ^ref-3575 --- In November of 2004, Andy was at another meeting with VCs. His pitch for the camera OS met with the same lack of interest. So he mentioned phones as a possibility and saw ears in the room perk up. Andy gave up. He got back in touch with both Nick and — location: [872](kindle://book?action=open&asin=B09QPMNWS5&location=872) ^ref-21643 listen to feedback --- Rich and told them that he was now ready to do a phone OS. — location: [874](kindle://book?action=open&asin=B09QPMNWS5&location=874) ^ref-24417 --- This was one of the cool parts of Android: Out of the first hundred people, almost everybody had done this before. I was working on things that I had already made mistakes on and learned from. Everybody was. —Joe Onorato — location: [882](kindle://book?action=open&asin=B09QPMNWS5&location=882) ^ref-58030 team culture --- Android happened because so many other efforts happened first. Or, more precisely, Android exists because the people who built it worked together previously at various other companies, in an ever-shifting Venn diagram of mobile and desktop platform companies. — location: [888](kindle://book?action=open&asin=B09QPMNWS5&location=888) ^ref-49637 that is for were idea comes from chapter 1 --- The companies that had the biggest impact on the early Android team were Be/PalmSource,1 WebTV/Microsoft, and Danger. None of them fed directly into Android, and most of them failed to make a large dent in the marketplace. But all of them provided a fertile proving ground where engineers learned critical skills that they would capitalize on when they later built the Android OS. — location: [893](kindle://book?action=open&asin=B09QPMNWS5&location=893) ^ref-28944 --- By mid-2006, ex-Be employees made up a third of the Android team. — location: [935](kindle://book?action=open&asin=B09QPMNWS5&location=935) ^ref-56084 after going to palm --- Most of the early Android team worked at one or more of these companies: Be/PalmSource, WebTV/Microsoft, and Danger. Through mid-2006, those people represented at least 70 percent of the team, and continued to be a majority of the team until 2007. — location: [999](kindle://book?action=open&asin=B09QPMNWS5&location=999) ^ref-26277 good in speed up / acquisition opportunity --- Not all of these other companies or their products were — location: [1022](kindle://book?action=open&asin=B09QPMNWS5&location=1022) ^ref-40625 knowledge carry between attempt cross company - chapter 8 failure example --- successful. But the knowledge gained in building them contributed hugely to the Android teams’ ability to build a working platform later. Steve Horowitz, who worked at Be and the WebTV team at — location: [1022](kindle://book?action=open&asin=B09QPMNWS5&location=1022) ^ref-24765 --- “That’s part of this world: you learn probably more from the failures than you do from the successes.” — location: [1024](kindle://book?action=open&asin=B09QPMNWS5&location=1024) ^ref-45992 --- Fadden’s first job when he joined was solidifying the demo, a prototype phone system that Swetland and Chris had been working on. It wasn’t actually functional (for example, it showed a stock ticker on the home screen which used a set of hard-coded symbols and stale data). But the demo represented a vision of what the product could be when it was actually implemented. The original demo, written by Brian Swetland and Chris White and later enhanced by Fadden, showing a home screen and several apps (most of which were not implemented). It’s a far cry from a modern Android home screen. — location: [1253](kindle://book?action=open&asin=B09QPMNWS5&location=1253) ^ref-56001 tracer bullet example --- As the team honed their vision, they created a slide deck to explain it. These slides painted a picture of the opportunities that they saw for Android in the marketplace, as well as a picture of how Android would make money for the investors. The slide deck in March of 2005 had fifteen slides, which was enough to capture the attention of VCs as well as Google. The pitch deck got interesting by the second slide, which compared PC and phone markets. In 2004, there were 178 million shipments of PCs worldwide. During the same period, there were 675 million phones shipped; nearly four times as — location: [1263](kindle://book?action=open&asin=B09QPMNWS5&location=1263) ^ref-1723 --- many units as PCs, but with processors and memory that were as capable as PCs were in 1998. This potential in mobile hardware was a point that Dianne Hackborn, then at PalmSource and eventually on the Android team, was also thinking about. The mobile industry was ready to pop because there was finally enough power for there to be a real, capable computing platform: Dianne said, “You could see the writing on the wall. The hardware was getting more powerful, and the market was already bigger than PCs.” — location: [1268](kindle://book?action=open&asin=B09QPMNWS5&location=1268) ^ref-40949 --- Android wanted to provide the world’s first complete open handset platform solution. It — location: [1311](kindle://book?action=open&asin=B09QPMNWS5&location=1311) ^ref-15296 network effect --- cloud-based data services to their customers for Android-based handsets. The carriers would pay Android for providing these services. Swetland explained: “Rather than running and hosting the services [like Danger did for its Hiptop phones], we would build the services and sell them to the carriers.”3 — location: [1329](kindle://book?action=open&asin=B09QPMNWS5&location=1329) ^ref-58899 --- In parallel with these VC meetings, the team was also meeting with Google. In early January, Larry Page5 asked Andy to come to Google for a meeting. Larry was a huge fan of his T-Mobile Sidekick (the Danger Hiptop) phone, which Andy’s previous company had made, so he wanted to talk to Andy about the mobile space. — location: [1340](kindle://book?action=open&asin=B09QPMNWS5&location=1340) ^ref-36711 --- the Android side and Larry, Sergey Brin,6 and Georges Harik (an early Google employee) from the Google side. Nick remembered the meeting as very casual, but also that Google was clearly interested in what Andy and Android were up to. “That meeting started out with Larry saying the Sidekick’s the best phone that’s ever been done. Larry very much wanted to see an even better phone get made, and he knew that’s what Andy and the group of us were working on. At the end of that meeting they said, ‘We’d like to help you guys.’” That meeting was encouraging, but nothing substantive came out of it. In fact, Andy wondered whether they were just using the meeting as a way to pick Andy’s brain about Danger, the company he’d founded and left back in 2003. He thought that Google might have been interested in purchasing Danger. — location: [1345](kindle://book?action=open&asin=B09QPMNWS5&location=1345) ^ref-56336 --- Then in March, they went to Google for another meeting. This time, they showed a demo and shared more of their plans. Nothing significant happened at that meeting either, but Google made it clearer that they wanted to help the startup. The team was also meeting with potential manufacturing partners at this time. They took a trip to Korea and Taiwan to visit Samsung and HTC. The meeting with Samsung started with the CEO of the mobile phone unit, K.T. Lee, saying he’d missed his chance with Danger and didn’t want to see that happen again, so he was interested in getting on board with Android. Nick described the meeting: “K.T. Lee told his team to make it happen, so we thought it was a done deal. But then we met with his team of 10+ mid-level managers, who said, ‘Who is going to build your OS?’ When we said ‘Brian,’ they laughed. They had 300 people working on their own OS.” — location: [1353](kindle://book?action=open&asin=B09QPMNWS5&location=1353) ^ref-3587 --- Samsung asked the team if they were dreaming. Nick said, “‘No, really, Brian and a few other people are going to build the OS.’ They asked how this would be possible and we responded that not only is it possible, but he already did it on Sidekick.” After the business meetings, Samsung hosted a dinner to celebrate the new partnership. But the Android team later learned the deal was contingent upon securing an order from a carrier, which Nick admitted, “wasn’t really a deal at all. It took about 18 months to convince T-Mobile to become our Android launch partner.” — location: [1360](kindle://book?action=open&asin=B09QPMNWS5&location=1360) ^ref-24799 --- The team didn’t come away with a deal, but they did get a device name from it. When they later picked the device that would become the G1, they gave it the code name “Dream” in memory of that meeting. — location: [1365](kindle://book?action=open&asin=B09QPMNWS5&location=1365) ^ref-60088 dream as product name : good anecdote --- This time, there were more people in the room, and Google was ready to talk specifics. Andy and his team had assumed they were coming to give an update on the company’s — location: [1373](kindle://book?action=open&asin=B09QPMNWS5&location=1373) ^ref-31601 --- progress since the last meeting. But in the middle of the presentation, Nick remembered, “They just said, ‘Let us interrupt you there. We just want to buy you.’” — location: [1375](kindle://book?action=open&asin=B09QPMNWS5&location=1375) ^ref-23651 --- Google turned what Andy’s team thought was a meeting of Android — location: [1376](kindle://book?action=open&asin=B09QPMNWS5&location=1376) ^ref-63275 --- Google had revenue from search that they might be able to share with carriers. So rather than having to sell carriers on something, they’d be able to form partnerships with them. — location: [1380](kindle://book?action=open&asin=B09QPMNWS5&location=1380) ^ref-7686 this the critical bit a new revenue model : that subside a free os --- Nick remembered that it was a powerful argument for getting carriers on board: “We were actually going to help them make money by doing a partnership deal with us.” — location: [1381](kindle://book?action=open&asin=B09QPMNWS5&location=1381) ^ref-2212 --- When Android met with Google, Larry Page observed that it would make sense for Google to acquire the small company, to help them build a platform that would enable Google to enter the mobile market. — location: [1415](kindle://book?action=open&asin=B09QPMNWS5&location=1415) ^ref-57510 that is what is chapter 2 but maybe android is better elsewhere this chapter is pretty packed we already have waymo --- ‘This isn’t strategic to Google. You guys haven’t even started focusing on WAP1 or any mobile stuff. We think this is going to be a lot of work, require resources. What happens if you don’t want to do this? How do we know we’re going to get the resources we need to be successful?’” — location: [1426](kindle://book?action=open&asin=B09QPMNWS5&location=1426) ^ref-36810 --- from other companies. A lot of other companies, when projects aren’t going well, they throw a lot of resources at it. At Google, we like to give resources to things that are going well. So if you do what you’re going to do and you’re executing, you’ll get more resources.’ That was, in essence, his Leap of Faith talk; why we should, if we believe in ourselves, do this because we’ll get the resources if we’re executing.” The Android — location: [1430](kindle://book?action=open&asin=B09QPMNWS5&location=1430) ^ref-61693 --- A few weeks after the Android team started at Google, they were again presenting the pitch deck. This time, it was at an internal meeting at Google, pitching to a group of executives. Andy and others were showing what this newly acquired team was planning to do. Swetland described the meeting: “We showed the demo we had. Andy was running through the deck. I remember when he got to the monetization thing, Larry cut him off and said ‘Don’t worry about that. I want you guys to build the best possible phone and we’ll figure out the rest later.’” — location: [1435](kindle://book?action=open&asin=B09QPMNWS5&location=1435) ^ref-17563 --- how to find our feet. We moved from a ten person startup to a 4,500 person company. We spent the first two weeks camping out in conference rooms because they didn’t have permanent offices allocated to any of us. Where do we work? How do we hire people?” Hiring was the next step: Android needed more people. But hiring Android engineers proved to be difficult at Google. — location: [1457](kindle://book?action=open&asin=B09QPMNWS5&location=1457) ^ref-43298 the android team from various previous os and specialized contribution is perfect for the get the right people in the bus - note also deep mind adhocracy which is symbolized by mission hub this goes both in chapter 1 for location maybe and to part 3 --- Around that time, there were billboards up and down the main artery of Silicon Valley, Highway 101, displaying a cryptic math puzzle: — location: [1462](kindle://book?action=open&asin=B09QPMNWS5&location=1462) ^ref-7786 fun story that goes with the right people in the bus --- One of the legends of Brian Swetland was how he “found” extra memory on the G1 shortly before it shipped. He submitted a fix in the run-up to the release, expanding the available RAM on the device from 160MB to 192MB, giving the OS and all applications 20 percent more memory to play with, which was a significant boost on this very memory-constrained system. — location: [1639](kindle://book?action=open&asin=B09QPMNWS5&location=1639) ^ref-39048 --- Nick Pelly, who joined the team later to work on Bluetooth, remembered that not everyone was happy how this worked out: “OMG the drama this caused. The Browser team had been pulling extra Sundays to fit into the (false) memory budget. I remember one of them storming into Brian’s office with some loud and choice words when he ‘found’ that extra memory.” — location: [1649](kindle://book?action=open&asin=B09QPMNWS5&location=1649) ^ref-55978 --- Chris DiBona (who dealt13 a lot with open source projects) remembers talking to people from the community at a Linux conference around that time. “There was one guy who was spitting mad, ‘I can’t believe you’re doing this!’ — location: [1687](kindle://book?action=open&asin=B09QPMNWS5&location=1687) ^ref-65405 get Chris feedback --- Another important aspect of security on the platform was treating all applications as separate “users” on the device. On other operating systems, users would be protected from each other, but not from themselves. So, for example, you could create a user account on a PC and the data that you created in that account would be protected from other users on the system. However, any application that you installed would run as you, so all of your applications would have access to all data in your account. There was an implicit trust between any user and all of the applications they installed. But the Android engineers felt (rightly so) that the applications on the device should not be inherently trusted. So rather than having apps running as the user who installed them, Brian’s design had each app run as a separate, unique user on the device. This approach guaranteed (through the Linux kernel mechanism of user IDs, or UIDs) that apps had no automatic access to the data of any other application on the same device, even though those other applications were installed by the same device owner. Brian provided a low level service to create, destroy, or run-as-a-user. Dianne Hackborn, on the framework team, integrated this service with higher-level application permissions and built out the policies for application UID management. — location: [1948](kindle://book?action=open&asin=B09QPMNWS5&location=1948) ^ref-19658 this and Chromebook dual boots are two good security innovation to put in the book --- ordered a new license plate for his car, JAVA SUX. “When you go to get the license plate, they [the Department of Motor Vehicles] ask you what it stands for. I said that I used to work for Sun and we made this Java thing, and it stands for Secondary User Extensions, and they said ‘Okay.’” — location: [2257](kindle://book?action=open&asin=B09QPMNWS5&location=2257) ^ref-632 --- Bob credits Zygote for Android being at all functional at that time: “The Zygote thing helped a lot, just being able to share memory, going from having just a couple Java processes running to having dozens running on a really small device. And rather than having to wait for a whole VM to start up, our apps actually looked faster; they would launch instantly, because we’d just fork a process and start right there. Everything was already warmed up.” Eventually, Zygote contained not just code, but also shared data such as images, and continued providing memory and startup benefits to Android as the platform grew. — location: [2367](kindle://book?action=open&asin=B09QPMNWS5&location=2367) ^ref-11480 good technical anecdote to add somewhere maybe --- writing PixelFlinger’s virtual GPU was an example of the product versus platform approach that Android took in the early days.13 A product approach, where the team simply got the initial phone to work as quickly as possible, wouldn’t have taken as long. But the platform approach that Mathias took, building up layers of software that scaled way beyond that initial release, proved useful to Android in the long run. “It was necessary to go through that step to be ready for when the hardware was there. But also to convince people that that’s what needed to happen.” — location: [2796](kindle://book?action=open&asin=B09QPMNWS5&location=2796) ^ref-47850 --- But instead of just being another licensee of Skia’s rendering engine, Google acquired Mike’s company. Android was, after all, in hiring mode, and acquisitions can be an effective way (if you have the money) to hire multiple people quickly. The acquisition was announced on November 9, 2005, and the four engineers from Skia (Mike, Cary, Leon Scroggins, and Patrick Scott) started in December. — location: [2869](kindle://book?action=open&asin=B09QPMNWS5&location=2869) ^ref-34025 chapter 4 accelerators via acquisition --- The original HTC audio drivers for that device were so buggy that even doing something as simple as trying to play a second sound while one was already playing would reboot the device. The Android team didn’t have access to the source code for that driver, so they worked around the problem by introducing a layer on top of the driver called AudioFlinger. Mathias came up with the name, based on his experience writing SurfaceFlinger. SufaceFlinger solved a related problem on the graphics side, where many applications produced buffers of pixel data that SurfaceFlinger displayed on the screen. Similarly, AudioFlinger combined multiple audio streams across the system into a single stream which would then be sent to the driver without (and this is the key part) causing the device to reboot. Mathias worked with Marco, Arve, and Ficus to get it working for the G1. It was only supposed to be a temporary workaround in the platform for that specific device, but as often happens in software, it lived on far past its usefulness until it was finally rewritten so that the system could talk more directly to drivers that didn’t have those historical problems. — location: [3006](kindle://book?action=open&asin=B09QPMNWS5&location=3006) ^ref-31456 in 20/80 or scale as example of getting it down and then see --- Handling video is complicated. For one thing, video needs codecs4 to load and save video files. Video software also needs the capability to play content that has been loaded by a codec. And once you have all of that working, you need to optimize it to happen quickly, because a video that can’t play smoothly is less “video” and more “frustrating.” Meanwhile, the software needs to be able to talk to the hardware, which is tricky because video-specific hardware can vary widely between devices. With such a small team, it would have been difficult to implement everything that video required. So Andy made the decision to buy the necessary technology instead of writing it in-house. He asked Ficus Kirkpatrick to check out some options, but had him focus on a company called PacketVideo. PacketVideo, at the time, licensed an entire suite of software to do all of what Android needed. The deal was going to happen; Ficus’s investigation was more like a sanity-check than a deep analysis. Ficus remembered, “Andy told me he was going to do the deal no matter what.” Like the rest of the team, he was busy with other things at the time, and it seemed like a foregone conclusion, so he didn’t spend a lot of time evaluating the situation: “I didn’t think it mattered. I didn’t think the code was good, but didn’t speak up.” He briefly investigated other options. He vetoed one of the alternatives because of the state of their code. That other company was so focused on making their product work on Windows that they baked assumptions into the software that made it unusable on any other OS (such as Linux, which was what Android needed). Comparatively, PacketVideo was a better choice. “It was probably the least awful of the media frameworks I looked at.” The deal that Andy was proposing was awkward for PacketVideo; he was proposing to give away the core of their business. The company made its money from licensing their video software. Android needed not only the functionality of their code, but also the code itself. Android was planning to open source all of the code for the platform, including PacketVideo’s code. So the deal Andy proposed was that Android would take their software and publish it in the open, essentially destroying any future licensing possibilities they might have had, because any potential clients could just copy the Android code. Ficus said, “Andy’s pitch to them was, ‘Your business is going to change from licensing to professional services. We will give you some money to bridge the transition.’” The deal was done (with the help of Tom Moss5), the code was integrated, and the Android team was . . . not happy.6 Ficus remembered, “The code was not very good. Optimizing it was really hard.” Mathias Agopian agreed. “It was a disaster, from a technical standpoint. PacketVideo on paper was really good: tons of codecs, playback, recording, video, audio. On paper, problem solved. But we spent many, many, many years fixing and eventually rewriting everything.”… — location: [3016](kindle://book?action=open&asin=B09QPMNWS5&location=3016) ^ref-26330 perfect example of accelerator again and good enough in tracer bullet --- its main() method, and then just starts doing things in a loop (drawing, polling for input, doing any necessary calculations, and so on). On Android, an application is broken down into one or more “activity” pieces, each of which has its own window. Activities (and applications) have no main() method, but instead are called by the OS in response to events, like activity creation/destruction and user input. Another important element of Activities is that they define specific entry points that can be called from other applications, like notifications or shortcuts in the system UI that can take the user to a place inside of the application. Dianne said, “Palm had a really good understanding of mobile devices. One of the things we learned there was that mobile apps are fundamentally different from desktop apps: the user can only be in one at a time, and they tend to be small and focused on a particular task. Out of this grew a need to easily have apps work together. Palm OS had this hack called ‘sublaunching’ that allowed one app to effectively call in to another app, to do something like show a UI for the user to add a contact. — location: [3157](kindle://book?action=open&asin=B09QPMNWS5&location=3157) ^ref-36804 comme from previous ideas - design innovation maybe this one or chrome dual boot as example of innovation type --- “There were a lot of hotheads, a lot of conflict. Not only did you have the PalmSource/Danger thing, you had Googlers coming in saying ‘This is the way you must do it.’ But I think that conflict helped — location: [3384](kindle://book?action=open&asin=B09QPMNWS5&location=3384) ^ref-33684 --- It was a classic ‘second system effect’ where a lot of us had done something similar before and thought we could do it again without all the mistakes from the first time. Those of us coming from Danger wanted to make another user interface toolkit based on Java class inheritance, but get it right this time with a real operating system underneath and a robust service architecture on the other side of the network. The people coming from PalmSource wanted to do their activity lifecycle model and interprocess communication model again, but get it right this time. The people coming from Skia wanted to do QuickDraw GX again, but get it right this time. We were all wrong, and wrong in ways that clashed badly with each other. It took years of work to straighten out the consequences of all our bad early decisions and the interactions between them.” — location: [3618](kindle://book?action=open&asin=B09QPMNWS5&location=3618) ^ref-3979 --- 10-Year Visual History”7 The Verge had this to say: “It was almost universally acknowledged that Android nailed the notification system on day one. It would take iOS another three — location: [3893](kindle://book?action=open&asin=B09QPMNWS5&location=3893) ^ref-53341 notification as a visual innovation --- 7. https://www.theverge.com/2011/12/7/2585779/android-10th-anniversary-google-history-pie-oreo-nougat-cupcake — location: [3960](kindle://book?action=open&asin=B09QPMNWS5&location=3960) ^ref-45239 --- One of the important elements in the final design was the shape itself. “The logo was inspired by an international symbol. There is a very simple symbol of a human. I tried to come up with the equivalent symbol for Android.” — location: [3991](kindle://book?action=open&asin=B09QPMNWS5&location=3991) ^ref-2080 --- Google’s main mission has been supplying results to search queries. So investing more broadly in web technology like browsers made sense; the better the vehicles are that deliver those results, the better experience Google could offer for those results. This was especially important to Google back in the early 2000s, with the state of web browsing enabled by browser companies at that time. — location: [4130](kindle://book?action=open&asin=B09QPMNWS5&location=4130) ^ref-18108 --- ensure that all users had access to great web experiences, including new web technologies that were being introduced, Google started funding web browser development. At first, Google worked with the Mozilla foundation, helping out with the Firefox browser. In particular, Google contributed engineering resources by implementing or helping out with some of the improvements in that browser, including things like performance improvements, inline spell-checking, the software update system, and browser extensions. Google didn’t have an operating system on which to bundle a browser, like Microsoft or Apple, but it could provide a better browser alternative and encourage people to switch to it. — location: [4143](kindle://book?action=open&asin=B09QPMNWS5&location=4143) ^ref-35261 --- Unlike the situation with desktop browsers, the Android platform was being built from scratch. They didn’t need a better browser; they needed any browser. — location: [4157](kindle://book?action=open&asin=B09QPMNWS5&location=4157) ^ref-55553 --- Rich lobbied Google execs Eric Schmidt (CEO) and Alan Eustace (VP of engineering) to start an engineering site. It was a hard sell. “Eric had had a bad experience with the East Coast. Sun Microsystems, under his watch, had started an eng office here. But they put it way out in the periphery, outside of the city. I had to convince him that a place near the universities could attract the best talent. We could build a great office.” — location: [4232](kindle://book?action=open&asin=B09QPMNWS5&location=4232) ^ref-31347 --- For example, they worked on creating and implementing the web standard for geolocation. They also made the video element11 (another feature in HTML5) work in the browser. In 2008, during the run-up to Android 1.0, the VP of the mobile team (Vic Gundotra) disbanded the mobile effort, including Dave Burke’s London team. — location: [4462](kindle://book?action=open&asin=B09QPMNWS5&location=4462) ^ref-6259 --- we could do it, that we could keep a connection open and to have the server tell us, ‘You have new mail.’ For J2ME, we did not have that; you needed to refresh constantly. But at some point, I was able to send an email and I saw my phone react. The first thing I did was to run to Steve Horowitz’s office and show him. His jaw dropped. He knew we were working on it, but he didn’t know if we could do it.” Romain Guy said, “What I loved about the first Android phone, about 1.0, is that we had push notifications for email and chat, which was huge back then, because the iPhone didn’t have any of that. I remember that my phone would get the emails faster than my desktop. My phone would beep, and then a few seconds or minutes later my desktop would finally show the new email.” — location: [4614](kindle://book?action=open&asin=B09QPMNWS5&location=4614) ^ref-51278 --- For the most part, the Android team operated separately from the rest of Google. Google funded the project and checked in with the leadership team, but otherwise left them alone. The Android team kept their heads down, writing the operating system, the tools, the apps, and everything else they needed, without interacting with the larger engineering organization in Google. Except for the services team. — location: [4666](kindle://book?action=open&asin=B09QPMNWS5&location=4666) ^ref-16114 skunk work - but better to start with how I joined emerald sea and maybe go take a picture of the painting - discuss also that bard was a small channel and then talk about skunk work in general and how most projects at google where secret in a Trix at the beginning --- Launch day: October 22, 2008. One of Android’s servers had already gone down earlier in the week, but was fortunately working again in time for the launch. On launch day, a second server went down due to “unplanned maintenance.” Google wanted to work on it, so they just took it out of the system. So immediately, on launch day, Android was down to two servers. Fortunately, two was still enough for a robust, fail-safe system. Then one of those servers caught fire. There was an overheating issue in the data center that day, so they had to shut down the system to work on it. Michael said, “We were really sweating bullets—we were down to a single data center! We just lost two; if that third one went down, none of the sync stuff would work properly—there would be no chat or whatever. We were really panicked.” — location: [4793](kindle://book?action=open&asin=B09QPMNWS5&location=4793) ^ref-28611 --- First of all, the team divided the bits on the device into system and data. The system partition contained the Android platform itself as well as pre-installed apps, which was read-only (except for the OTA updates). — location: [4854](kindle://book?action=open&asin=B09QPMNWS5&location=4854) ^ref-36434 --- “We were using raster maps, which were PNGs.6 If you rotated the map, the text was upside down. If you wanted to tilt the map, you couldn’t.” Also, the images used for the maps were large and required large bandwidth to download. — location: [5115](kindle://book?action=open&asin=B09QPMNWS5&location=5115) ^ref-20340 talk about map being too early on desktop and pushed back --- Keith built a demo of these new vector-based maps and sent it to Charles, in Mountain View, who took it to Andy’s office: “Larry was in the office. I showed them the vector maps. You could tilt and zoom. Before, we had discrete zoom levels. Now you could zoom in a little or a lot, and the text wouldn’t distort.” But there was a trade-off: performance. “To do it on a G1 was so hard because we were rendering it.” That is, it requires more effort and time to draw a map’s geometry, vector by vector, than it does to display an image. But it was a thousand times less data. Andy knew that it would be important for the upcoming Verizon device. “Turn-by-turn navigation, on Droid, became one of the marquee features.” Keith continued working with Charles on both productizing vector maps and on the turn-by-turn navigation feature. — location: [5124](kindle://book?action=open&asin=B09QPMNWS5&location=5124) ^ref-19642 add to the map turn by turn part in chapter 2 --- One of the fascinating things about Google is that there are so many people at the company that are famous for doing a particular thing . . . which is completely unrelated to what they end up doing at Google. I’ve known famous classic game developers, inventors of fundamental graphics algorithms, and 3D graphics experts, none of whom worked on software at Google remotely related to the software achievements that made them famous. Other companies hire people for what they’ve done, then ask them to do more of it. Google hires people for who they are and asks them to do whatever needs to be done. What these people have done in the past is a great example — location: [5467](kindle://book?action=open&asin=B09QPMNWS5&location=5467) ^ref-3684 --- what they can do, but does not limit them, in Google’s eyes, to what they are capable of. That’s how Google found itself with one of the world’s great font rendering experts, working on the Android emulator. — location: [5472](kindle://book?action=open&asin=B09QPMNWS5&location=5472) ^ref-28212 --- It was all about writing optimal code because every cycle, every kilobyte, takes away resources or spends battery life that is needed elsewhere. — location: [5626](kindle://book?action=open&asin=B09QPMNWS5&location=5626) ^ref-60305 example of metric unique to android chapter 4 --- remember everybody—me, Dianne, Dan [Bornstein]—would be in this war room, because over the course of a release there’d be all these places where people were using too much memory. We didn’t have swap,1 because it didn’t make sense to have swap. Things would run out of memory and crash. It was this kind of heroic session in a war room where we’d just go on for days sometimes, and you would never know when the end was going to be, just trying to stamp out memory problems. — location: [5634](kindle://book?action=open&asin=B09QPMNWS5&location=5634) ^ref-49147 metric chapter 4 --- The mindset of the entire platform team was performance-first. This came from a combination of the limited memory on those early devices, along with slower CPUs, the lack of GPU rendering — location: [5645](kindle://book?action=open&asin=B09QPMNWS5&location=5645) ^ref-37639 Northstar chapter 4 --- second, and arguably more important, element of Android’s open source model is that Android’s partners have free and easy access to all of it. This was actually the original reason for Android open sourcing the platform; it was a mechanism to make Android available for any prospective device manufacturer to get everything they need. There is no licensing and there are no protracted contract negotiations; partners can simply go to the website and get the bits they need to ship an Android-based device. And in so doing, they help to enable a consistent ecosystem of compatible Android implementations, because everyone is starting from the same common implementation. If they want to get Google services like the Play Store and Maps and Gmail, then there’s more to it, but the core code for building a phone platform is available for anyone to download and use as is. Romain Guy explained: “That’s what we all think when we think ‘open source’ for Android. Partners don’t necessarily care about contributing, but they have everything they need.” Brian Swetland agreed: “One of the goals of Android, before they ever had contact with Google, was to give people an alternative to that dire future of a single company owning the mobile computing platform. The thinking was, how do you get people to adopt it? It’s gotta be open. Otherwise, how can they trust that they have any level of control?” Dianne Hackborn agreed, comparing Android’s open source model to the licensing model she’d seen fail in previous experiences: “One of the things we struggled with at PalmSource in getting others to use our platform was that they were deathly afraid of someone doing to the mobile space the same thing that Microsoft did to PCs. For example, Motorola had a really hard time thinking about licensing Rome [PalmSource’s UI toolkit built for Palm OS 6] but were all-in on buying the company and owning it. Being able to make Android open source made it a lot more comfortable for OEMs to adopt, since they could share some ownership of it, as well as making it extremely flexible for the rapid evolution of mobile devices.” It is this second element, opening up the platform for device makers, that distinguished Android from other platform offerings out there. Not only was the platform available to use, but the code was available to understand and play with as companies got it working on their devices. And, in the meantime, this open source platform was also a complete, production-quality implementation, verified on actual hardware products and ready for manufacturers to take and use. — location: [5710](kindle://book?action=open&asin=B09QPMNWS5&location=5710) ^ref-37369 open source as a scaling strategy avoid Microsoft type lock in that and accelerator might go to scale th instead of chapter 4 note Android don't expect many contribution OSs is here to drive adoption and increase trust --- Michael Morrissey was working at Microsoft prior to Android and got to see that process first-hand. “When you were trying to bring up a new OS, whether it was Win CE or Pocket PC or whatever on a new phone, trying to integrate those things and debug bringing that up was incredibly painful. You had this thing called the ‘Board Support Package,’ which was all the low-level code that came from the OEM. And then you had all the higher-level Windows code. So if phone calls were failing, or the network was bad, or whatever, where did the problem lie? Nobody could figure out where that was. — location: [5731](kindle://book?action=open&asin=B09QPMNWS5&location=5731) ^ref-35336 --- “This was my favorite running gag at Microsoft: There was a team whose job it was to work with these OEMs to bring up new hardware. Except neither side was allowed to see each other’s code, because it was secret. Samsung or HTC or whoever would send somebody over to Seattle, and they would sit next to somebody in this team. They would try to debug it without really letting each other see each other’s code. They would just lean over and say, ‘… — location: [5736](kindle://book?action=open&asin=B09QPMNWS5&location=5736) ^ref-30759 --- Of course, there’s more to being open source than simply saying that the code is open source. The team had to put the project together in such a way that external developers and companies could get to it, download it, build it, and understand how to do all of that. It took effort to pull it together in the time leading up to the initial release. — location: [5750](kindle://book?action=open&asin=B09QPMNWS5&location=5750) ^ref-50270 --- we made it free without open sourcing it, it would have been just as successful.” That is, having the source code available in open source wasn’t the important part; simply making the source code available would have been enough. Open source was just a natural and transparent way to achieve that goal. — location: [5775](kindle://book?action=open&asin=B09QPMNWS5&location=5775) ^ref-2365 --- “Day one, Hiroshi handed me an electronic Gantt chart of hundreds of tasks, stretching out way past our delivery date. He accompanied it with an ‘Aagh, help!’ I think. In retrospect, it was a classic project management challenge, but it was all new to me. I talked with all the developers, about 30 at the time. It helped to come from being a developer with a startup background. “I started off helping the software engineers organize their work into a series of milestones that led up to the 1.0 launch. That was a wild time, since we had to figure out how to stabilize the code base while the business and product plans were still up in the air. In those early days, I was pretty excited about Agile development,10 but there was deep-seated skepticism within Android. Bad experiences of poorly run Agile groups at other companies had soured a lot of the leadership. But with an evolving product definition, the project actually lent itself to time-boxed development. No one knew when we’d be done since it wasn’t clear yet what ‘done’ meant. “I created a few initial milestones, ‘m1,’ ‘m2,’ etc., and flipped the question around: ‘What could we get done by each milestone?’ I cautiously asked the developers for rough estimates in ‘Ideal Engineering Days’ (IEDs) but avoided traditional Agile terminology as much as possible. IEDs largely worked for those first few milestones, and we figured out how to burn down feature work and see progress towards some goals. The biggest win was moving feature work tracking over from that Gantt chart into where bug work was already being tracked. Over the years, we migrated away from estimating in IEDs but a lot of the rhythm of the release—things like Zero Bug Bounce,11 Feature Complete, etc.—stuck around. — location: [5987](kindle://book?action=open&asin=B09QPMNWS5&location=5987) ^ref-3582 anecdote for tracer bullet - do what you can in timeboxed time if its changing too fast --- recall a lot of early debates about what ‘1.0’ meant. Dianne, Swetland, and others felt really passionate about that definition. To move the conversation on, I suggested we use code names and figure out which one would be 1.0 later on. Dianne agreed on the condition they were alphabetical, so Astro Boy12 and Bender13 were obviously going to be our first Android code names! We were set for C3PO to be the third, and that looked like it would end up being 1.0 . . . which turned out to be problematic.14 Dealing with licensing issues would just slow us down, and we realized that could happen for a lot of future releases also. We needed something else, and I was (still am) pretty obsessed with cupcakes. I loved the idea too that we could celebrate our release with Sprinkles,15 so the dessert thing kicked off for realz!” — location: [6005](kindle://book?action=open&asin=B09QPMNWS5&location=6005) ^ref-6300 dessert as a fun innovation anecdote. maybe in org in part 3 --- The reason we use dessert names is that desserts can’t be trademarked. Of course, we have used trademarked names for a couple of the releases (K and O), but those involved agreements between companies. I don’t think that anyone wanted to get into negotiating trademark agreements for every Android release back in the early days. Besides, there are a lot more dessert names to choose from than robots. Wouldn’t it have — location: [6084](kindle://book?action=open&asin=B09QPMNWS5&location=6084) ^ref-7376 --- He also worked on a strategy of how to connect all the different stakeholders: app developers, handset manufacturers, carriers, and platform software teams. One of the tricks with open source software is motivation; why would any of these partners care about the Android platform except Google? “How do you get everybody incentivized and invested into this ecosystem in a way that would maintain compatibility?” Of course, app developers would care deeply about compatibility. Being able to run the same application across different implementations of Android would be a far cry better than what developers faced on platforms like Symbian and Java ME, where apps would frequently need to be rewritten to work across different devices. But the dynamics for manufacturers were different, and they were used to a world where they were responsible only for their own devices and implementations. Fortunately, Google had popular apps that manufacturers wanted on their devices, including Maps, YouTube, and the web browser. So Tom hammered out a system where access to those apps was an incentive for partners to maintain compatibility by shipping Android as-is, rather than shipping a forked version of it.2 Moving Around — location: [6118](kindle://book?action=open&asin=B09QPMNWS5&location=6118) ^ref-25422 good example of a legal innovation - add to chapter 2 --- Jeff Hamilton noted that this approach to global partnerships was how Android got to the scale that it has. “There are like two billion4 devices out there. One company can’t build that many devices and support them all. Especially the variety of things: different devices that people want, different price points, configurations, all that kind of stuff. It’s a huge variety. By doing the open source thing and having one stack that supported that and having partners set up the factories that build out the things required—for networks in Turkey or whatever, the different requirements—one company can’t take all of that on. There are different requirements in different regions. We scaled that by having different companies pick that up and take that on.” — location: [6150](kindle://book?action=open&asin=B09QPMNWS5&location=6150) ^ref-61605 scale chapter. 4 with previous quote --- That’s why it’s called ANDroid not ORdroid. Because if we are deciding between two alternatives, we always pick both. —Team Saying (Anonymous) — location: [6170](kindle://book?action=open&asin=B09QPMNWS5&location=6170) ^ref-22808 ,🤣 --- The product-versus-platform debates on the team were represented by the different companies that people came from: Danger, Be/PalmSource, and WebTV/Microsoft. The people from Danger preferred simpler solutions, which gave them more of a product focus. The people from Be/PalmSource and WebTV/Microsoft had more of a platform mindset and preferred that approach for Android as well. — location: [6190](kindle://book?action=open&asin=B09QPMNWS5&location=6190) ^ref-42850 --- The debate was also happening in the Google boardroom. Executive reviews at the time showed Google’s top execs fell at different ends of the spectrum: some prioritized Android building a phone, some favored the platform approach, and some fell somewhere in the middle. Dianne summed up the debates: “Platform or Product: That was always the Danger versus Palm OS people. Andy’s answer was, of course, ‘Both.’ Which was the right answer.” — location: [6208](kindle://book?action=open&asin=B09QPMNWS5&location=6208) ^ref-20032 --- Brian Jones commented on the Android culture and the singularity of mission that it endowed on the team. “We were a little startup within Google. We were shielded from the rest of the big company. We were this little enclave, and we had a lot of autonomy. Once you were in, everybody knew that you were on board towards that mission. — location: [6238](kindle://book?action=open&asin=B09QPMNWS5&location=6238) ^ref-36139 in skunk work --- Brian Jones explained: “In Android, there’s a hardware component, there’s a manufacturing component, there’s a carrier component, there are partnerships. You can launch and iterate a search algorithm. You can’t launch and iterate a piece of hardware. You have to set a date and work backwards.” Brian Swetland agreed: “The reality is, when you’re trying to ship consumer electronics, and somebody’s committing a factory line, or they’re lining up a big marketing campaign to hit their sales targets, you can’t miss or you really mess up things for your partners. You get a little crazy when you’re trying to hit those deadlines, because the consequences if you miss the window . . . you might not be able to ship that product three months later. You might never be able to ship that product, because now you have to build a whole different product.” Swetland compared this approach to that of Google teams outside of Android: “It’s all web stuff: you ship it, and if it doesn’t work, you roll it back. It’s not quite as easy when you’re burning images at the factory.”3 Chiu-Ki Chan, who had transferred onto the Android team from elsewhere in Google, talked about this hardware-driven dynamic: “Android was the first team that taught me that Christmas ends in October. If you want your device to hit the market — location: [6258](kindle://book?action=open&asin=B09QPMNWS5&location=6258) ^ref-8796 --- This date-driven mentality ended up creating the hard-working, deadline-driven culture that defined Android in those early days. — location: [6273](kindle://book?action=open&asin=B09QPMNWS5&location=6273) ^ref-45251 --- Tom Moss remembered, “We burned a lot of bridges. But we kind of had to. We — location: [6326](kindle://book?action=open&asin=B09QPMNWS5&location=6326) ^ref-31994 --- Dan filed a work request to have the networking infrastructure team look into it, with the subject, “Why is there a USB port in the wall of B44-2?” Google takes security, both physical and technological, very seriously. A bare, cryptically labeled USB port caused concern. Tickets were filed, security personnel were alerted, and an operation was started to remove it. An electrical team took over the room on the other side of that outlet and a guard was posted outside. The electricians cut out the drywall behind the plate, which showed what was really going on. Behind the wall plate was . . . nothing. It was just a USB port embedded in the wall. It was a prank. Or, rather, it was engineers (specifically, Brian Jones, Joe Onorato, and Bruce Gay) with more hardware than plans. They carefully cut a hole in the drywall, and with a mixture of hot glue and inspiration, they inserted a USB port borrowed from an old workstation. Bruce added a label to make it look more official. They had no plans for anything more elaborate; they just thought it was funny sitting there, doing nothing. Google Security didn’t share that feeling. The electrician replaced the existing wall plate with a blank one, which provided the same functionality, but with less room for hijinks. Switch Statement The temptation of the blank wall plate left behind from the USB port fix was too great; it cried out for something more. The team didn’t want to freak out Google Security again. But they had to do something. There’s always tons of random hardware lying around in the Android department, especially around Brian Jones’s desk. So Joe and Brian scrounged around for the parts that resulted in a switch to control the internet. Flipping the switch1 caused the light to turn green and the switch to buzz (the team found some haptic hardware to make the plate vibrate when it was switched off). — location: [6361](kindle://book?action=open&asin=B09QPMNWS5&location=6361) ^ref-49082 --- Putting in a shitload of hours was very valuable, culturally, in Android. —Ficus Kirkpatrick — location: [6415](kindle://book?action=open&asin=B09QPMNWS5&location=6415) ^ref-63487 --- working really, really hard. Ficus Kirkpatrick called it “The currency of Android.” — location: [6418](kindle://book?action=open&asin=B09QPMNWS5&location=6418) ^ref-9494 --- really wanted to do as much as we possibly could. I always compared it to some endurance athletic event; miserable in the moment, and you’re glad when it’s over, but you — location: [6428](kindle://book?action=open&asin=B09QPMNWS5&location=6428) ^ref-57301 --- How many times were Swetland and other people like, ‘I’m fucking going to quit!’ Then we’d launch and we’d have a party and we’d all feel good, and we’d all sign up for it again. “It was great. I loved it. We all loved it. We felt like we were the special forces of the Marines, working on this amazing project. It’s us against the world and we get there by the grit of our teeth and camaraderie. Yeah, we were all depressed and overworking and not sleeping. But turnover was actually incredibly low, for as much as we complained and as much as we said, ‘bad morale.’” — location: [6444](kindle://book?action=open&asin=B09QPMNWS5&location=6444) ^ref-10633 --- late 2009, a year after 1.0 shipped, Android institutionalized extra working hours by starting the tradition of Bacon Sundays. — location: [6473](kindle://book?action=open&asin=B09QPMNWS5&location=6473) ^ref-60851 --- So toward the end of a release, management encouraged people to come to the office on Sunday morning with the promise of a big breakfast buffet spread (along with plenty of work). Participation wasn’t required, and not everybody came in on those Sundays. But there was an understanding that there was a lot of work to do, and a team effort would help. — location: [6476](kindle://book?action=open&asin=B09QPMNWS5&location=6476) ^ref-50529 --- Hiroshi Lockheimer came up with the idea. “We were behind schedule for the Droid—we were probably behind our fourth schedule—and that was a Big Deal. There was a big launch, with a lot of marketing behind it, so we were like ‘Shit, what do we do? Gotta come in on weekends and make it happen.’ — location: [6479](kindle://book?action=open&asin=B09QPMNWS5&location=6479) ^ref-44029 --- was clear we needed more time. The only way I could think of to get more time was to work on weekends. So Sundays—not every Sunday—but in the summer it became kind of a . . . in retrospect, kind of a sad tradition.” By 10:00 in the morning (it’s difficult to get most engineers in the office earlier than that, breakfast or no), there would be a full, catered spread with brunch goodies, including a large tray of bacon. People wandered into the cafeteria, ate their fill and caught up with co-workers, then headed to their desks to continue working on the product. — location: [6486](kindle://book?action=open&asin=B09QPMNWS5&location=6486) ^ref-5500 --- Bacon Sundays went away by the time the team shipped KitKat, in the Fall of 2013. — location: [6498](kindle://book?action=open&asin=B09QPMNWS5&location=6498) ^ref-36426 --- These annual episodes were known as Postcards from Barcelona, where Andy would casually send in feature requests that were entirely too late to make a release . . . but which the team rushed to implement anyway, because it was Andy. — location: [6517](kindle://book?action=open&asin=B09QPMNWS5&location=6517) ^ref-47298 culture --- “It would be me sending these emails saying, ‘I just had a meeting with Andy and he really wants these things fixed before we ship.’ It always coincided with MWC. There are two reasons for that. One, that’s when our maintenance release1 schedule usually was, so we would do our release in the Fall, and we’d have our big follow-up maintenance release at that time. So it was towards the end of the release cycle, when we’re trying to get launch approvals. Back then, Andy was the big approver. The other reason was because I was with him in Barcelona, I could show him: ‘Andy, we gotta launch this thing. Take a look, are you ready?’ And then always, almost on principle, he would point out at least one or two things, just because that was his style.” Andy’s late requests were also a consequence of the release schedule and the inherent latency of software development cycles. “There’s a lag from where we’re done with the software to when it actually shows up in some consumer’s hands. He didn’t like that lag, so he didn’t want to wait. When we said ‘next release’ he knew that meant like six months, nine months, a year from now, and he was like, ‘I don’t want to wait that long. Do it now before you launch.’ “So then I would like, tuck my tail, email the team saying, ‘Sorry, but. . . .’” — location: [6520](kindle://book?action=open&asin=B09QPMNWS5&location=6520) ^ref-16812 --- the Android team at that time that has appeared in various places since: “As a consumer I was blown away. I wanted one immediately. But as a Google engineer, I thought ‘We’re going to have to start over.’”2 This quote implies that the iPhone caused Android to change everything and reboot its development plans. But it’s not quite correct. It’s true that Android’s plans changed, but the team didn’t have to start over. Rather, they needed to re-prioritize and change product schedules. When the iPhone was announced, the Android team was very much heads-down in development. The device they were working on was called Sooner, so named because they wanted it to come out sooner than the real target device for Android, the Dream (which was based on the HTC Dream hardware). Sooner had no touchscreen. Instead, it relied on a hardware keyboard for UI navigation, which was a common user experience on phones . . . before touchscreens became must-have features. The Dream device did have a touchscreen, and the Android platform was being designed to incorporate that capability. But Dream was slated to launch later while the team focused on shipping 1.0 with the Sooner device, well, sooner. Suddenly, touchscreen capability had to be prioritized and shifted from a future device to the first device. And that first device had to change accordingly. The Sooner was dropped, and development pivoted to the Dream device (which was eventually launched in the US as the T-Mobile G1). Brian Swetland remarked on the team’s pivot: “When the iPhone happened, the decision was: We’re going to skip shipping Sooner and we’re gonna ship Dream as soon as it’s ready. Because it didn’t make sense to ship a BlackBerry wedge after Steve3 shipped the iPhone.” Dianne Hackborn liked the change in plans and saw it as an opportunity to finish the platform. “If it would have shipped, there wouldn’t have been multiprocess. I was so stressed about that. I was glad that we dropped Sooner. The software schedule just didn’t line up with the hardware schedule.” — location: [6551](kindle://book?action=open&asin=B09QPMNWS5&location=6551) ^ref-49034 reluctant pivoting in chapter 8 --- Swetland talked about the rumors that Android completely restarted development because of touch. “I feel like we should be honored that they believe we could completely reset and rebuild the entire world in three months, and not that we spent years ahead of time building up adaptive UI and the tooling that let us rejigger the world and had all this work done ahead of time.” But there were some misgivings on the team about the change. Mike Fleming said, “I was upset that we hadn’t shipped. I thought that we could’ve gotten out before the iPhone had we shipped the Sooner product.” — location: [6574](kindle://book?action=open&asin=B09QPMNWS5&location=6574) ^ref-59167 --- The phone rings off the hook after Steve’s iPhone demo. Because Apple’s not going to license you any of that shit—now what do you do? —Brian Swetland — location: [6587](kindle://book?action=open&asin=B09QPMNWS5&location=6587) ^ref-18223 --- The iPhone announcement affected all of the mobile manufacturers, rippling through the entire mobile industry, causing fear and, ultimately and rather ironically, creating a major reason that Android was able to establish itself in the market. When the iPhone was announced, users saw a new expression of the smartphone, with more capabilities and a touchscreen-driven user interface. But carriers and manufacturers saw a potential monopoly being formed, one that would exclude them. — location: [6590](kindle://book?action=open&asin=B09QPMNWS5&location=6590) ^ref-39620 --- chip vendors, were also afraid of being excluded; if Apple didn’t happen to choose their chips for iPhone hardware, then they too would be left out. Suddenly, companies that had previously feared or disregarded Google were not only returning Google’s calls; they were approaching Google all on their own. They needed a comparable smartphone product, and Android offered a way to have one much sooner than they could have had otherwise. The iPhone launch “scared the industry,” said Iliyan Malchev. “Nobody had anything remotely as good at the time. Frankly, neither did we; it took us time to converge. But there was no other game in town.” — location: [6597](kindle://book?action=open&asin=B09QPMNWS5&location=6597) ^ref-64263 --- Bob was able to nail down the timeframe for some of those rumors because he had a meeting with Google at that time. “October of 2006. I remember, because the first meeting I had [at Google] with the team that we were negotiating with, the lead product manager showed up in a nun’s costume. The first Apple, iPhone, Google, Maps coming-together moment was Halloween of 2006. I sat in a meeting room for 2 hours with a nun. A male nun at that.” — location: [6642](kindle://book?action=open&asin=B09QPMNWS5&location=6642) ^ref-3723 Google playful culture --- Android beat Apple to the application marketplace, and Android 1.0 shipped with the Android Market app that allowed developers to distribute their own applications. The iPhone had originally shipped without any App Store at all, and no intention to provide one. After the iPhone was available, there was mounting interest in having more apps. “There was so much developer desire and so many requests. The first step was to go build web apps. That was perfect, because nobody was actually installing any software on the phone, but you can have an app-like experience. Our hope was that web apps were going to be the thing.” — location: [6661](kindle://book?action=open&asin=B09QPMNWS5&location=6661) ^ref-3104 --- On November 5, Google announced the formation of the Open Handset Alliance.2 The OHA was an important step toward the ecosystem that the team envisioned. In stark opposition to the traditional model exemplified by Apple and Microsoft, where a single company controls the platform, the OHA promised to provide an open source platform that could be used by all companies. It was a collection of carriers, hardware manufacturers, and software companies, including: — location: [6709](kindle://book?action=open&asin=B09QPMNWS5&location=6709) ^ref-52624 --- November 7–8: Industry Reception Existing players in the mobile space who weren’t part of the OHA didn’t appear to think much of the announcement. On November 7, two days after the — location: [6719](kindle://book?action=open&asin=B09QPMNWS5&location=6719) ^ref-29367 --- The following day, Steve Ballmer (then CEO of Microsoft) said during a news conference, “Their efforts are just some words on paper right now, it’s hard to do a very clear comparison [with Windows Mobile]. Right now they have a press release, we have many, many millions of customers, great software, many hardware devices.” There seemed to be a general sense of vaporware4 in the air. Press releases are one thing, but shipping a phone platform is a different kettle of software fish. — location: [6726](kindle://book?action=open&asin=B09QPMNWS5&location=6726) ^ref-62076 --- On November 11, six days after the OHA announcement, the Android SDK was released, with a build that was lovingly labeled m3.5 When the original OHA announcement went out, the SDK was completely ready. But the decision was made to do the press release first and let it float out there a few days before dropping the code. This allowed time for industry sentiment and general misbelief to fester. Six days later, the team shipped the actual software, making the announcement very real indeed. — location: [6732](kindle://book?action=open&asin=B09QPMNWS5&location=6732) ^ref-3005 --- “We shipped out a laptop to every one of the judges around the world. It was crazy! Most of these laptops never came back. One came back in a box packed with all kinds of stuffed animals, for some reason.” — location: [6794](kindle://book?action=open&asin=B09QPMNWS5&location=6794) ^ref-35014 --- When the G1 went on sale at the T-Mobile store on Market Street in San Francisco, Romain Guy was there, taking a picture of the first buyer. Nowadays, it’s hard to imagine caring who is buying what phone where, but at the time, this first purchase was the culmination of years of hard work by the development team; it was exciting to see their efforts make it into the real world and to see people line up to purchase them. Someone else who was at the store that day was Bob Borchers, the Senior Director of Product Marketing for the iPhone. He was purchasing one for his team to play around with back at Apple. — location: [7002](kindle://book?action=open&asin=B09QPMNWS5&location=7002) ^ref-18731 --- about the G1: “The impression was: ‘Wow, this thing is sophisticated, it can do a lot. If anything . . . it can do almost too much.’ It had a keyboard and it had a trackpad and a rollerball and touch. It had everything. All these sensors. You got a feeling initially that Android was trying to do everything. — location: [7028](kindle://book?action=open&asin=B09QPMNWS5&location=7028) ^ref-27160 --- T-Mobile reported2 that it had reached sales of over a million units in the US six months later. This was, coincidentally, the number of devices needed in that timeframe to convince the Google networking team to not take back its dedicated VIP resource — location: [7044](kindle://book?action=open&asin=B09QPMNWS5&location=7044) ^ref-59002 --- Hiroshi said, “The G1 made Android. Commercially, G1 wasn’t a huge success. The G1 was good but wasn’t a huge volume driver and didn’t really get that much attention outside of the tech industry. But launching it made it real for the OEMs: ‘OK these people can actually ship. It’s a real thing. It’s not vaporware.’ By the time G1 launched, we were already in discussions with all the major OEMs, who eventually became our partners.” — location: [7053](kindle://book?action=open&asin=B09QPMNWS5&location=7053) ^ref-25066 tracing bullet example the whole chapter --- For the next year, the team worked furiously on smaller bug-fix releases as well as larger “dessert” releases, culminating in the Eclair release that shipped with the Droid device at the end of 2009. In one year alone, the team shipped four major releases 1.1 (Petit Four), 1.5 (Cupcake), 1.6 (Donut), and 2.0 (Eclair). Tom Moss noted that this frantic pace was intentional: “Two reasons: Andy’s a perfectionist, and he wanted the product to get better. It really upsets him personally when the product is not good enough. But it was also an intentional strategy to stop OEMs from trying to fork by saying, ‘By the time you get your fork up, we’ll have the new version of Android out, and you’re going to have to start over again.’ — location: [7072](kindle://book?action=open&asin=B09QPMNWS5&location=7072) ^ref-22600 this goes into scale or red queen : you need to run to not be outpaced - reuse the android dessert doodle but on one line add timeline date to it to show the cadence --- “He intentionally pushed us to have multiple releases per year in order to disincentivize or disable people from forking.” — location: [7078](kindle://book?action=open&asin=B09QPMNWS5&location=7078) ^ref-30783 --- Petit Four was also the first time a dessert name was used for an Android release, although it was clearly not following the convention of starting with successive letters in the alphabet; that tradition would start with the next release, Cupcake. — location: [7093](kindle://book?action=open&asin=B09QPMNWS5&location=7093) ^ref-25309 --- Throughout Android’s history, one of the most important dynamics about Nexus, and other devices that Google helped launch, was that they were made by different manufacturers. This was very intentional, as a way to get the entire partner community invested in Android. Early devices from Google included phones by HTC, Motorola, LG, and Samsung. — location: [7200](kindle://book?action=open&asin=B09QPMNWS5&location=7200) ^ref-51976 --- Charles Mendis said, “A lot of credit to Andy and biz dev. We didn’t just partner with one; we’d switch between them. We managed to get some of the biggest players in the hardware space invested in Android, where it became their platform, and now all this phone hardware is done by them. We made them feel like everybody else owned Android, too; Android wasn’t owned by Google.3 I think that really helped the success of it.” — location: [7203](kindle://book?action=open&asin=B09QPMNWS5&location=7203) ^ref-16206 --- And then the second day was very similar to the first, it was maybe like 65,000 [devices sold]. But then it was like, ‘Oh God, what’s going to happen now? Is that it? Were these just super-excited early adopters, and it’s going to go away?’ But the numbers continued to be pretty good. My recollection of numbers is bad, but it was like 30,000 a day for a long time. Once that kept going and the Droid — location: [7282](kindle://book?action=open&asin=B09QPMNWS5&location=7282) ^ref-52906 --- Meanwhile, the Nexus One would have more co-branding support than the Droid. Verizon wanted the Droid to be a Verizon device, and the main brands associated with it were Verizon (the carrier) and Motorola (the manufacturer). The Google brand was not on the Droid. Not only was the Droid suffering from a branding and ownership standpoint, it was . . . ugly. Tom Moss said, “It was all sharp edges. You could cut yourself on the corners.” But marketing can help, and the marketing campaign for Droid did just that. The campaign capitalized on the unique aspects of the device, and made that potential weakness its strength, pitching it as a robotic device that did so much more than the competition. It apparently worked, and people bought Droids in much larger quantities in the US than had bought any other Android phones before. The days of Android being outsold hugely by the competition were over, as the market share of Android continued to grow, overtaking iPhone sales completely by the end of 2010. — location: [7297](kindle://book?action=open&asin=B09QPMNWS5&location=7297) ^ref-56542 the droid is a good story for be in a position to be helped. it show that Verizon was able to bring their own view And need as they didn't have the iphone. it is important to highlight that it was the hockey stick moment for Android and we pushed passion / nexus one later to support it. it also tie back to rotating career to do nexus/pixel device to make everyone feel included. really android early days / oss is the best story for being in a position to be helped. --- Charles Mendis said, “One of the biggest problems [on the G1] we had in Maps was the cache would blow up. We’d get ‘Out of Memory’ exceptions, and the app would die while you were using it. We did a bunch of stuff to get around it, but there just wasn’t enough RAM to work with. When the Droid came in, we could actually deliver the experience. — location: [7329](kindle://book?action=open&asin=B09QPMNWS5&location=7329) ^ref-12635 --- Another aspect of the Droid hardware that was significant for Android was the screen. The Droid was the first device with a screen size (480 × 854) that differed from that of the original G1 (320 × 480). Also, the Droid had a higher pixel density than the earlier devices (265 versus 180 pixels per inch). This meant that developers could, for the first time, see the advantage of building their apps in a way that scaled to different screen form factors automatically. — location: [7335](kindle://book?action=open&asin=B09QPMNWS5&location=7335) ^ref-23647 --- The Droid was the hockey stick4 moment for Android, where the adoption curve of Android hit a swiftly increasing slope. Hiroshi recalled: “I remember reading an article that came out maybe a day or two after the Droid had launched, where the reporter had interviewed some app developer who had published on iPhone, iOS and had already published on Market. They were saying, ‘Wow, we’re noticing the Droid already.’ Like two days in, the developer saying, ‘Our installs are going way up on Android.’ It was also a moment, not only a consumer moment, but also for developers, — location: [7339](kindle://book?action=open&asin=B09QPMNWS5&location=7339) ^ref-62051 --- It’s impossible to deny the positive impact that Samsung has had on Android; they are the largest manufacturer of Android-based devices, and their Samsung Galaxy devices are the brand name in Android phones. Even the “exploding phone” problem with the Note 7 batteries,1 an issue that would have decimated smaller companies, didn’t keep people from rushing to buy new devices when they were available. — location: [7374](kindle://book?action=open&asin=B09QPMNWS5&location=7374) ^ref-9527 --- “In Japan, I know they licensed Darth Vader from Lucasfilm, they had Ken Watanabe2 as their spokesman. They hired thousands of engineers, designers . . . everything. JK Shin3 bet the farm on Android for smartphones. They were the first to really spend on the last mile. They were the first to think about having Samsung sales reps in stores to help promote it, having little areas in the store. They did brilliant execution. — location: [7389](kindle://book?action=open&asin=B09QPMNWS5&location=7389) ^ref-51629 --- I think in a nutshell that’s why Android worked: Everyone’s in it together. We never would have reached the scale and the success that Android reached without that approach of partnership. —Ficus Kirkpatrick — location: [7467](kindle://book?action=open&asin=B09QPMNWS5&location=7467) ^ref-30428 opening quote ? at least in a position to be helped --- The thing we were always really proud of—Apple looming in the background—we were fast. The speed of this team was nothing I’ve ever seen anywhere. Before or after. —Joe Onorato The Android team consisted, from the beginning, of people with the right skills and drive to build what was needed. Creating an entire platform, along with the applications, services, and infrastructure that Android — location: [7482](kindle://book?action=open&asin=B09QPMNWS5&location=7482) ^ref-5605 in team culture on getting the right people --- needed, was a huge effort, and demanded strenuous effort by people who could dive in quickly to make things work. It wasn’t a large team . . . but it was the right team. The Right Experience Most of the team came in with exactly the right experience, which allowed them to hit the ground running. Having worked on related platform and mobile projects at companies like Be, Danger, PalmSource, WebTV, and Microsoft, gave them the technical grounding in exactly the right domains to know how to approach similar problems that Android presented. The Right Attitude The Android team grew as it approached 1.0, but only to a size of about 100 people by the time of that first release. This meant that everyone had more than enough work to do to ship the product. But people did what they needed to — location: [7487](kindle://book?action=open&asin=B09QPMNWS5&location=7487) ^ref-55078 --- large areas of functionality as well as working across multiple areas, wherever help was needed. Coupled with the startup environment that pushed everyone to work insanely hard in those early years, the team was able to write Android from scratch and deliver a robust platform and device in time to become relevant in the nascent smartphone industry. The Right Size The small size of the team meant that everyone had to work incredibly hard to finish the project, but it also meant that they were much more efficient. Ficus talked with Brian Swetland after he started leading the Play Store team, years after 1.0: “He asked how big my team was. I told him 300 people. His eyes popped out, ‘With 300 people you could do a new Android!’ “I said ‘No. With 300 people, you couldn’t—you need 20 people.’ That larger team is riding on the code and practices built by the individuals that had consensus by default. In the early days, with all of the communication and coordination. . . . If you start with a big team, you spend all of your time debating.” The Right Leadership Great teams benefit from great leadership to help everyone gel and drive forward together. One aspect of that leadership was sheltering Android and running it like a startup inside the big mothership of Google. Another aspect was having decisions being made by a single person, not by a group of people. San Mehat said, “Much like Apple, it really helped to have that visionary asshole type. The one person. Not a committee. Not five people.… — location: [7495](kindle://book?action=open&asin=B09QPMNWS5&location=7495) ^ref-29641 --- distinguished Android from the other smartphone platforms. Notifications The system of notifications on Android helped bring the whole system together, as applications cooperated with the underlying system to propagate information to the user about things that they wanted to know about. Multitasking Allowing users to easily and quickly switch between applications with UI elements like the Back and Recents buttons foresaw the new dynamic of mobile — location: [7523](kindle://book?action=open&asin=B09QPMNWS5&location=7523) ^ref-47546 --- Android allowed developers to write and provide their own applications, helping to create a rich ecosystem for users to be able to do much more than they ever could with just the apps that Google provided. Enabling this app ecosystem was critical to the platform; any platform trying to enter the market now that doesn’t offer a rich selection of apps simply doesn’t have a chance. The team provided developers with a rich toolbox of capabilities that enabled these applications, and the entire application ecosystem, to exist. — location: [7539](kindle://book?action=open&asin=B09QPMNWS5&location=7539) ^ref-11652 in a position to be helped --- Open source Prior to Android, the only options that device manufacturers had were either building a platform themselves, licensing one for a significant cost, or cobbling something together from existing, but incomplete, solutions. Android provided a powerful, free, and open option for manufacturers that desperately needed it. — location: [7556](kindle://book?action=open&asin=B09QPMNWS5&location=7556) ^ref-37562 --- Compatibility One of the key elements to make Android work across a diverse ecosystem was compatibility of implementations, ensuring that developers could write apps that worked everywhere, instead of having to rewrite them for the plethora of available devices. To solve this problem, the Android team provided the Compatibility Test Suite (CTS) for manufacturers to ensure that they are providing a compatible implementation on every new device. — location: [7562](kindle://book?action=open&asin=B09QPMNWS5&location=7562) ^ref-20449 --- One of the aspects that worked for Android at Google was autonomy. Keeping themselves separate from the rest of the company gave the team that startup dynamic that they felt Android needed in those early days to ship the first product. At the same time, being a part of Google gave Android more leverage with partner companies than it would have had as an actual startup company. Meanwhile, Google had exactly the right kind of existing technical infrastructure that Android needed as it grew. Not only did the services team have the right experience to connect the Google apps to backend servers, but the team also had the advantage of relying on an infrastructure that could scale to their needs. A company that could handle the extreme download requirements of YouTube was able to deal with OTA updates for the small but growing base of Android users. — location: [7577](kindle://book?action=open&asin=B09QPMNWS5&location=7577) ^ref-42361 in culture --- Competition and Collaboration After the iPhone was announced, manufacturers were desperate for a touchscreen offering of their own to compete in the evolving smartphone market. Given the closed ecosystem of the iPhone, these other companies were on their own to create a compelling system, but nobody was in a good place to do that. Meanwhile, Android had been working on a platform that was intended to support different kinds of devices and requirements including, for example, a touchscreen. — location: [7632](kindle://book?action=open&asin=B09QPMNWS5&location=7632) ^ref-25675 --- The timing was right for those other companies to — location: [7636](kindle://book?action=open&asin=B09QPMNWS5&location=7636) ^ref-22130 --- collaborate with Android and use that open source platform to create their own smartphone devices. — location: [7637](kindle://book?action=open&asin=B09QPMNWS5&location=7637) ^ref-65019 --- Hiring Timing also had an impact on building the original team. Android was staffing up at a time when a core group of OS people from companies like PalmSource, Danger, and Microsoft were available and anxious to take on a new project together. The fact that all of these people joined around the same time meant that Android was jump-started by a group of people who not only had relevant experience, but also had worked together already and didn’t have to spend time building team dynamics. They just got down to work. — location: [7642](kindle://book?action=open&asin=B09QPMNWS5&location=7642) ^ref-9123 --- The final part of timing was that the team was able to move fast enough to capitalize on the opening they were given. For one thing, the team had been able to build up the core Android platform to a reasonable place by the time the iPhone was announced, so it was nearly ready for manufacturers that needed a competing solution quickly. Also, the team was able to pivot in reaction to the new reality of touchscreens, getting 1.0 and the G1 to market before other viable solutions could. — location: [7647](kindle://book?action=open&asin=B09QPMNWS5&location=7647) ^ref-24217 --- Without the unique combination of hardware capabilities that enabled smartphones, and the singular impact that the iPhone had on an industry thrashing about for a way to compete with that new device, Android may not have found a foothold, and would have just been another of the many failures littering the curbside of mobile device history. Instead, it was able to become a viable alternative at the right — location: [7651](kindle://book?action=open&asin=B09QPMNWS5&location=7651) ^ref-36039 --- time for manufacturers across the world to ship their own — location: [7654](kindle://book?action=open&asin=B09QPMNWS5&location=7654) ^ref-27814 --- We’ve hit 2 billion actives, and I guess that’s a form of “We’ve done it.” But man, the competition: it never ends. It’s relentless. Every day we’re competing. It just never feels done. That’s why I’m still here. —Hiroshi Lockheimer — location: [7663](kindle://book?action=open&asin=B09QPMNWS5&location=7663) ^ref-65287 perfect quotes for chapter 2? or infinite mission ---