WEBVTT 1 00:00:00.120 --> 00:00:04.599 If you've ever written the line of traditional desktop software 2 00:00:04.719 --> 00:00:06.599 or even just basic Java, you know there's a very 3 00:00:06.639 --> 00:00:08.039 comforting predictability to it. 4 00:00:08.080 --> 00:00:09.640 Oh, absolutely, it's very linear. 5 00:00:09.880 --> 00:00:12.560 Right. You walk into the building through a clearly marked 6 00:00:12.560 --> 00:00:17.000 front door, and in the programming world, that front door 7 00:00:17.079 --> 00:00:17.920 is the main method. 8 00:00:18.039 --> 00:00:20.879 Yeah, the classic public static void Maine exactly. 9 00:00:20.960 --> 00:00:24.359 You fire up the application, the operating system basically hands 10 00:00:24.359 --> 00:00:27.800 over the keys, and your code just executes right, step 11 00:00:27.800 --> 00:00:31.280 by step linearly from that main method until the program 12 00:00:31.320 --> 00:00:32.920 finishes its job and shuts down. 13 00:00:33.320 --> 00:00:35.840 It's the universal starting line. I mean, the whole desktop 14 00:00:35.840 --> 00:00:39.079 paradigm relies on the application being in the driver's seat 15 00:00:39.079 --> 00:00:39.880 once it's launched. 16 00:00:40.079 --> 00:00:41.719 Yeah, it's driving the car. 17 00:00:41.520 --> 00:00:44.039 Right, because it assumes it has a relatively stable environment. 18 00:00:44.520 --> 00:00:47.359 You know, plenty of RAM, a persistent connection to a 19 00:00:47.399 --> 00:00:51.520 power source, and a user who will explicitly click an 20 00:00:51.719 --> 00:00:53.359 X when they're actually done. 21 00:00:53.399 --> 00:00:56.079 But then you look at the pocket sized supercomputers we're 22 00:00:56.079 --> 00:00:58.520 all carrying around every single day. If you peel back 23 00:00:58.560 --> 00:01:01.479 the layers of an Android app, you realize that front door, 24 00:01:01.560 --> 00:01:04.480 that main method, it just doesn't exist. 25 00:01:04.760 --> 00:01:06.000 It's completely gone. Right. 26 00:01:06.079 --> 00:01:09.040 Instead of a linear script, you're looking at this invisible, 27 00:01:09.480 --> 00:01:14.239 highly decoupled machinery that feels honestly almost alien if you're 28 00:01:14.239 --> 00:01:18.239 coming from the desktop world. The operating system never really 29 00:01:18.280 --> 00:01:20.920 hands over the keys. It stays in absolute control. 30 00:01:21.079 --> 00:01:24.560 It really is a radical departure from conventional software architecture. 31 00:01:24.959 --> 00:01:30.120 And yet this decoupled, seemingly chaotic system is running on 32 00:01:30.480 --> 00:01:33.439 what an estimated ninety percent of the world's smartphones, which 33 00:01:33.480 --> 00:01:36.719 is just staggering. It is, and it forces developers to 34 00:01:36.760 --> 00:01:40.560 completely rewire how they think about an application's lifespan and 35 00:01:40.599 --> 00:01:41.239 its structure. 36 00:01:41.560 --> 00:01:44.680 Well, welcome to this deep dive into the source material. Today, 37 00:01:44.799 --> 00:01:46.400 you and I are popping the hood on the most 38 00:01:46.480 --> 00:01:48.760 ubiquitous mobile operating system on the planet. 39 00:01:48.840 --> 00:01:50.159 Yeah, were getting right into the weeds. 40 00:01:50.439 --> 00:01:54.159 We are using the Android Cookbook, second edition by Ian F. Darwin, 41 00:01:54.280 --> 00:01:57.239 published by O'Reilly as our guide. So, whether you are 42 00:01:57.400 --> 00:02:01.079 prepping to build your very first mobile, or maybe you're 43 00:02:01.079 --> 00:02:04.319 a veteran developer switching over from enterprise Java, or you're 44 00:02:04.400 --> 00:02:07.519 just insanely curious about the invisible machinery running the device 45 00:02:07.599 --> 00:02:10.840 right there in your pocket. Our mission today is to 46 00:02:10.919 --> 00:02:15.599 extract the foundational aha moments of Android architecture, and. 47 00:02:16.159 --> 00:02:18.360 There are quite a few of those moments in this book. 48 00:02:18.240 --> 00:02:21.560 So many. Okay, let's unpack this. We need to start 49 00:02:21.560 --> 00:02:24.919 at the absolute atomic level, because if there isn't one 50 00:02:25.319 --> 00:02:28.199 massive block of code with a main method, how is 51 00:02:28.199 --> 00:02:30.439 an Android app actually constructed? 52 00:02:30.680 --> 00:02:34.120 Well, it's constructed out of four distinct modular components. You 53 00:02:34.120 --> 00:02:36.280 can almost think of them as specialized organs within a 54 00:02:36.360 --> 00:02:37.039 larger body. 55 00:02:37.120 --> 00:02:38.560 Okay, I like that. What's the first one? 56 00:02:38.800 --> 00:02:41.639 First you have activities. These are the visual components. So 57 00:02:41.719 --> 00:02:43.800 when you open an app and look at a screen 58 00:02:44.560 --> 00:02:47.319 like a log in page, a list of emails, a 59 00:02:47.360 --> 00:02:48.360 settings menu. 60 00:02:48.199 --> 00:02:50.120 You are looking at an activity exactly. 61 00:02:50.479 --> 00:02:55.080 It handles the UI window and direct user interaction. Second, 62 00:02:55.240 --> 00:02:59.560 you have services. These are the invisible workhorses running long 63 00:02:59.639 --> 00:03:00.840 term background tasks. 64 00:03:01.400 --> 00:03:03.000 So like if you're streaming audio. 65 00:03:03.319 --> 00:03:05.560 Right, if you're listening to audio and you switch over 66 00:03:05.599 --> 00:03:08.479 to your web browser, the audio keeps playing because a 67 00:03:08.560 --> 00:03:10.960 service is handling it independently of the UI. 68 00:03:11.120 --> 00:03:14.199 Got it. So the activity is the face and the 69 00:03:14.240 --> 00:03:16.800 service is the heartbeat in the background. What about the 70 00:03:16.800 --> 00:03:17.199 other two? 71 00:03:17.360 --> 00:03:20.840 The third component is the broadcast receiver, and this is 72 00:03:20.879 --> 00:03:24.560 a highly specialized listener. It basically sits dormant until a 73 00:03:24.599 --> 00:03:27.840 system wide event wakes it up, like what kind of event. Well, 74 00:03:27.879 --> 00:03:30.039 it's waiting for the operating system to announce things like 75 00:03:30.280 --> 00:03:33.520 the batteries at ten percent or the device just finished 76 00:03:33.560 --> 00:03:36.039 rebooting or Wi Fi connection loss. 77 00:03:36.080 --> 00:03:38.080 Oh I see, So the app can react to the 78 00:03:38.120 --> 00:03:40.080 phone itself changing states. 79 00:03:40.120 --> 00:03:42.800 Exactly, maybe by pausing a heavy download so it doesn't 80 00:03:42.840 --> 00:03:46.080 kill your battery. And finally, the fourth component is the 81 00:03:46.120 --> 00:03:47.039 content provider. 82 00:03:47.280 --> 00:03:48.280 Right, the data one. 83 00:03:48.360 --> 00:03:51.479 Yeah, because Android enforces a strict sandbox around every app 84 00:03:51.479 --> 00:03:54.800 for security, apps cannot read each other's private data, which 85 00:03:54.840 --> 00:03:57.759 is good, we want that absolutely. Yeah, But if you 86 00:03:57.879 --> 00:04:01.319 build an app that needs to act, say the user's 87 00:04:01.319 --> 00:04:04.319 address book, it has to communicate with the contacts app. 88 00:04:04.879 --> 00:04:09.199 A content provider securely punches a controlled hole through that sandbox. 89 00:04:09.280 --> 00:04:13.400 It exposes specific data via a standardized URI. Right, kind 90 00:04:13.400 --> 00:04:14.879 of like querying a database. 91 00:04:14.960 --> 00:04:16.040 You hit the nail on the head. 92 00:04:16.319 --> 00:04:19.800 That sandbox concept is crucial because it means these components 93 00:04:19.800 --> 00:04:23.160 are heavily isolated, even within the same app. If I'm 94 00:04:23.199 --> 00:04:26.879 picturing this visually, an Android app is like a massive restaurant. Okay, 95 00:04:26.920 --> 00:04:29.639 I'm tracking the activity is the dining room where the 96 00:04:29.680 --> 00:04:33.519 guests actually sit look at the menu and interact. The 97 00:04:33.560 --> 00:04:36.839 service is the kitchen cooking away entirely in the background, 98 00:04:36.920 --> 00:04:37.439 out of sight. 99 00:04:37.680 --> 00:04:38.120 I like this. 100 00:04:38.279 --> 00:04:41.079 The broadcast receiver is the fire alarm on the wall, 101 00:04:41.279 --> 00:04:44.600 just waiting, dormant until a specific environmental trigger goes off. 102 00:04:45.160 --> 00:04:48.199 And the content provider is the delivery dock out back, 103 00:04:48.399 --> 00:04:51.040 managing shipments of ingredients from outside vendors. 104 00:04:51.319 --> 00:04:53.920 That analogy holds up beautifully actually, but you know it 105 00:04:53.959 --> 00:04:57.319 immediately highlights the central engineering challenge of this whole setup. Well, 106 00:04:57.319 --> 00:04:59.519 if the dining room in the kitchen are entirely separate, 107 00:04:59.560 --> 00:05:03.319 isolated components, they can't just yell across the building to communicate. 108 00:05:03.560 --> 00:05:05.439 They need a formalized routing system. 109 00:05:05.600 --> 00:05:08.920 Right, Because in a normal Java program, if the dining 110 00:05:09.000 --> 00:05:12.279 room needs a new menu, it just creates one. It 111 00:05:12.399 --> 00:05:16.240 uses the new keyword to instantly spawn the exact object 112 00:05:16.319 --> 00:05:16.759 it needs. 113 00:05:16.839 --> 00:05:19.040 Yeah, the classic instantiation. 114 00:05:18.439 --> 00:05:22.800 That in Android, you can't just forcefully instantiate another activity 115 00:05:22.839 --> 00:05:25.560 or service. You have to ask the operating system to 116 00:05:25.600 --> 00:05:26.120 do it for you. 117 00:05:26.439 --> 00:05:30.360 What's fascinating here is how Android solves this with its 118 00:05:30.439 --> 00:05:35.160 messaging system. You use it these objects called intense intense. Yeah, 119 00:05:35.199 --> 00:05:38.639 Instead of directly creating a component. You package up an intent. 120 00:05:39.480 --> 00:05:41.720 It is exactly what it sounds like. It's a declaration 121 00:05:41.800 --> 00:05:44.519 of your intention to do something. You hand this intent 122 00:05:44.600 --> 00:05:47.319 to the operating system, and the OS figures out how 123 00:05:47.319 --> 00:05:47.839 to fulfill it. 124 00:05:48.079 --> 00:05:50.480 So the intents are the waiters. They take the order 125 00:05:50.480 --> 00:05:52.560 from the dining room, walk it over to the kitchen, 126 00:05:52.600 --> 00:05:53.560 and bring back the result. 127 00:05:53.680 --> 00:05:54.600 Perfect exactly. 128 00:05:54.839 --> 00:05:57.000 But I got to push back on this architecture for 129 00:05:57.040 --> 00:06:00.720 a second, because adding the operating system as middleman to 130 00:06:00.839 --> 00:06:04.759 every single internal action seems incredibly. 131 00:06:04.120 --> 00:06:05.439 Inefficient and sounds like it. 132 00:06:05.519 --> 00:06:07.519 Yeah, I mean, why design it this way? Why not 133 00:06:07.600 --> 00:06:09.680 just let the dining room talk directly to. 134 00:06:09.639 --> 00:06:12.720 The kitchen Because the restaurant is operating inside a device 135 00:06:12.800 --> 00:06:17.600 with severely restricted resources. We are talking about limited battery life, 136 00:06:17.800 --> 00:06:22.680 limited memory, and limited processing power compared to a desktop computer. 137 00:06:23.040 --> 00:06:25.399 Ah okay, the physical constraint right. 138 00:06:25.639 --> 00:06:29.600 By forcing every interaction through an intent, the Android OS 139 00:06:29.639 --> 00:06:32.959 acts as a ruthless air traffic controller. If the device 140 00:06:33.040 --> 00:06:36.399 is running out of RAM, the OS can quietly assassinate 141 00:06:36.399 --> 00:06:37.199 your background serve. 142 00:06:37.360 --> 00:06:38.399 It just kills the kitchen. 143 00:06:38.480 --> 00:06:40.839 It kills the kitchen. It frees up memory for a 144 00:06:40.879 --> 00:06:44.839 phone call without crashing the dining room. It can selectively 145 00:06:44.920 --> 00:06:48.680 kill and restart these individual components. Because they are completely decoupled, 146 00:06:49.160 --> 00:06:52.959 the OS maintains total authority over the device's resources at 147 00:06:52.959 --> 00:06:53.759 all times. 148 00:06:53.920 --> 00:06:57.600 Okay, so the OS is this hypervigilant manager that can 149 00:06:57.680 --> 00:07:00.319 and will terminate parts of your app without war warning 150 00:07:00.480 --> 00:07:03.720 just to save RAM. But if the OS is constantly 151 00:07:03.759 --> 00:07:07.839 assassinating components, how does the user not lose all their progress? 152 00:07:08.000 --> 00:07:09.600 That is the million dollar question. 153 00:07:09.839 --> 00:07:11.920 Like if I'm filling out a long form in an 154 00:07:11.920 --> 00:07:14.519 activity and the OS kills my app to take a 155 00:07:14.519 --> 00:07:19.040 phone call, that data needs a survival mechanism, which brings 156 00:07:19.120 --> 00:07:22.720 us to what the source material details as the activity. 157 00:07:22.240 --> 00:07:25.800 Life cycle, precisely because Android has the power to rip 158 00:07:25.839 --> 00:07:28.480 the rug out from under your app, and activity doesn't 159 00:07:28.519 --> 00:07:29.720 just have an on and off switch. 160 00:07:29.800 --> 00:07:31.160 It's not just open or closed. 161 00:07:31.279 --> 00:07:36.079 No, it transitions through a highly complex, biological like life cycle. 162 00:07:36.240 --> 00:07:39.959 It basically exists in different states of vulnerability active, paused, 163 00:07:40.000 --> 00:07:40.560 and stopped. 164 00:07:41.000 --> 00:07:43.839 Let's dissect what those states actually mean for the hardware, 165 00:07:44.000 --> 00:07:46.120 because you know, the audience listening knows what the word 166 00:07:46.199 --> 00:07:49.759 paused means in daily life, but in Android architecture, these 167 00:07:49.800 --> 00:07:53.240 states strictly dictate thread allocation and memory priority. 168 00:07:53.319 --> 00:07:53.439 Oh. 169 00:07:53.480 --> 00:07:56.560 Absolutely, Active obviously means the user is directly interacting with 170 00:07:56.560 --> 00:07:58.040 it and at a focus in the screen. 171 00:07:58.399 --> 00:08:02.439 Correct. When an activity is active, it is the very 172 00:08:02.480 --> 00:08:05.680 top of the food chain. The OS will do almost 173 00:08:05.720 --> 00:08:07.519 anything to keep it running smoothly. 174 00:08:08.079 --> 00:08:09.279 But what about paused. 175 00:08:09.839 --> 00:08:14.639 Well, the moment another component steals focus, say a translucent 176 00:08:14.720 --> 00:08:18.600 dial arg box pops up asking for permissions, or a 177 00:08:18.639 --> 00:08:22.720 low battery warning appears over your app, your activity enters 178 00:08:22.759 --> 00:08:23.800 the paused. 179 00:08:23.399 --> 00:08:25.160 State, so you can still see it. 180 00:08:25.319 --> 00:08:27.879 Yes, yeah, it is still partially visible in the background, 181 00:08:28.000 --> 00:08:31.560 but it no longer has direct user input. Finally, if 182 00:08:31.600 --> 00:08:34.159 the activity is completely hidden from view, like when you 183 00:08:34.240 --> 00:08:36.440 hit the home button to check your text messages, it 184 00:08:36.600 --> 00:08:37.720 enters the stop state. 185 00:08:37.799 --> 00:08:39.000 It's out of sight entirely. 186 00:08:39.159 --> 00:08:41.240 Right, It's still in memory, but it's completely dormant. 187 00:08:41.399 --> 00:08:44.799 And to manage these transitions, the book outlines a cascade 188 00:08:44.879 --> 00:08:47.919 of life cycle methods that the developer basically has to 189 00:08:48.080 --> 00:08:49.240 wire up manually. 190 00:08:49.320 --> 00:08:50.519 Yeah, the callback methods. 191 00:08:50.639 --> 00:08:52.759 Right, you start with on create, which is where you 192 00:08:52.759 --> 00:08:55.799 inflate your UI using set content view. Then you hit 193 00:08:55.879 --> 00:08:57.039 on start and on resume. 194 00:08:57.200 --> 00:08:58.440 Then that gets you to the active state. 195 00:08:58.679 --> 00:09:03.320 Exactly. Then when you lose focus, the OS fires on pause. 196 00:09:04.039 --> 00:09:06.879 When you are totally hidden, it fires on stop, and 197 00:09:06.960 --> 00:09:09.480 if the system needs to completely purge you from memory, 198 00:09:09.679 --> 00:09:10.639 you get on destroy. 199 00:09:11.159 --> 00:09:14.360 And this right here is where developers historically run into 200 00:09:14.559 --> 00:09:17.799 massive headaches, particularly around on pause. 201 00:09:18.159 --> 00:09:19.360 Why is that one so bad? 202 00:09:19.720 --> 00:09:22.639 Because on pause executes on the main UI thread. 203 00:09:22.799 --> 00:09:25.399 Ah, meaning if you screw up the code and on 204 00:09:25.559 --> 00:09:28.159 pause the entire screen freezes. 205 00:09:27.879 --> 00:09:29.679 Exactly, you have a fraction of a second when on 206 00:09:29.799 --> 00:09:32.360 pause triggers. You might be tempted to save the user's 207 00:09:32.480 --> 00:09:35.879 massive database entries right then, so they don't lose data. 208 00:09:35.559 --> 00:09:38.240 Which makes logical sense. You want to save their work. 209 00:09:38.159 --> 00:09:40.799 It does make sense. But if that database right takes 210 00:09:40.799 --> 00:09:43.399 too long, you block the UI thread. The system is 211 00:09:43.399 --> 00:09:45.799 trying to transition to an incoming phone call, but your 212 00:09:45.799 --> 00:09:48.840 app is holding the thread hostage. Oh wow, yeah, so 213 00:09:48.879 --> 00:09:52.080 Android will actually throw an application not Responding error an 214 00:09:52.080 --> 00:09:54.159 an R and crash your app just to get it 215 00:09:54.159 --> 00:09:56.159 out of the way. Developers have to learn to save 216 00:09:56.240 --> 00:09:59.080 lightweight state and on pause and push all the heavy 217 00:09:59.120 --> 00:10:01.000 lifting to onstop or a background thread. 218 00:10:01.320 --> 00:10:05.159 It really requires a massive amount of defensive programming and 219 00:10:05.279 --> 00:10:08.360 as if managing that life cycle isn't hard enough. The 220 00:10:08.399 --> 00:10:09.960 book brings up fragments. 221 00:10:10.159 --> 00:10:13.440 Oh, fragments. They amplify the complexity exponentially. 222 00:10:13.519 --> 00:10:14.159 You can imagine. 223 00:10:14.200 --> 00:10:17.279 They were introduced to solve a very specific hardware problem, 224 00:10:17.559 --> 00:10:20.759 which was the rise of tablets. You had developers writing 225 00:10:20.759 --> 00:10:23.600 an activity for a tiny phone screen, but when that 226 00:10:23.679 --> 00:10:26.639 same activity loaded on a ten inch tablet, it just 227 00:10:26.679 --> 00:10:29.080 looked like a stretched out, empty mess, just. 228 00:10:29.080 --> 00:10:31.639 A giant list with miles of white space. 229 00:10:32.039 --> 00:10:34.919 Right. So instead of forcing developers to write two entirely 230 00:10:34.960 --> 00:10:40.879 separate apps, Android introduced fragments as modular subcomponents of an activity. 231 00:10:40.960 --> 00:10:44.039 So on a phone, your activity displays one fragment, say 232 00:10:44.039 --> 00:10:46.320 a list of emails. You tap an email, and a 233 00:10:46.360 --> 00:10:48.720 new activity loads a new fragment to show the email 234 00:10:48.759 --> 00:10:52.279 body exactly. But on a tablet in landscape mode, the 235 00:10:52.320 --> 00:10:54.799 activity is wide enough to load the list fragment on 236 00:10:54.879 --> 00:10:57.320 the left and the body fragment on the right, side 237 00:10:57.320 --> 00:10:57.799 by side. 238 00:10:57.919 --> 00:11:01.679 That's the visual benefit, and it's great, But architecturally, fragments 239 00:11:01.720 --> 00:11:04.360 have their own independent life cycles that have to constantly 240 00:11:04.399 --> 00:11:07.039 synchronize with their host activities life cycle. 241 00:11:07.240 --> 00:11:08.679 Oh that sounds like a nightmare. 242 00:11:08.879 --> 00:11:12.200 You end up with this nested matrix of callbacks. You 243 00:11:12.240 --> 00:11:15.600 have to use a fragment manager to load, swap and 244 00:11:15.679 --> 00:11:19.480 remove them dynamically. It is notoriously difficult to keep the 245 00:11:19.480 --> 00:11:22.080 states perfectly aligned without causing memory leaks. 246 00:11:22.279 --> 00:11:24.960 Okay, I have to play Devil's Advocate here on my laptop. 247 00:11:25.000 --> 00:11:28.639 An application is open or it is closed. It handles 248 00:11:28.679 --> 00:11:32.759 its own memory. Why did Android back developers into this corner? 249 00:11:32.840 --> 00:11:34.600 It seems like a lot, doesn't it it does. 250 00:11:35.159 --> 00:11:39.320 Why engineer a system with so many highly specific middle states, 251 00:11:39.399 --> 00:11:43.159 nested fragments, and constant anxiety over the main thread. It 252 00:11:43.240 --> 00:11:45.679 seems like over engineering at its finest. 253 00:11:46.120 --> 00:11:48.759 If we connect this to the bigger picture, it all 254 00:11:48.799 --> 00:11:51.279 comes back to the fundamental nature of the device itself. 255 00:11:51.519 --> 00:11:54.679 A laptop is a dedicated workstation. A mobile device is 256 00:11:54.960 --> 00:11:57.039 fundamentally an interruption machine. 257 00:11:57.039 --> 00:11:59.360 An interruption machine. That's a great way to put it. 258 00:11:59.360 --> 00:12:03.399 It's primary directive is immediate real time communication. If you're 259 00:12:03.440 --> 00:12:05.960 playing a graphic intensive three D game and a phone 260 00:12:05.960 --> 00:12:08.840 call comes in, the operating system cannot ask the caller 261 00:12:08.879 --> 00:12:11.519 to wait while your game finishes its render cycle. Right. 262 00:12:11.559 --> 00:12:14.279 The phone has to be a phone first, exactly. 263 00:12:14.000 --> 00:12:17.840 The OS must instantly prioritize the radio hardware. The game 264 00:12:17.919 --> 00:12:21.919 must yield the screen perfectly, serialize its exact state into memory, 265 00:12:22.279 --> 00:12:25.840 and go dormant. When the call ends, it must reinflate 266 00:12:25.840 --> 00:12:30.080 that state flawlessly, as if nothing happened. The entire architecture 267 00:12:30.120 --> 00:12:33.320 is built around respecting the user's immediate context and the 268 00:12:33.320 --> 00:12:34.679 physical limits of the battery. 269 00:12:35.000 --> 00:12:38.080 So an Android app isn't really a static program. It's 270 00:12:38.159 --> 00:12:42.080 practically a biological organism that has to constantly adapt to 271 00:12:42.159 --> 00:12:43.879 an incredibly hostile environment. 272 00:12:44.000 --> 00:12:45.039 That's exactly what it is. 273 00:12:45.080 --> 00:12:48.320 And speaking of adaptation, let's zoom out from the individual apps. 274 00:12:48.720 --> 00:12:51.440 Now that we understand how the code survives, let's look 275 00:12:51.480 --> 00:12:54.360 at how the Android OS itself has evolved. Because the 276 00:12:54.440 --> 00:12:57.240 history of this platform is wild, it really is. 277 00:12:57.879 --> 00:13:01.240 Android manages his evolution through a very structured versioning system. 278 00:13:01.360 --> 00:13:05.159 You have major numbers for revolutionary platform changes like Android 279 00:13:05.200 --> 00:13:08.000 four point zero, which finally merged the disparate tablet in 280 00:13:08.039 --> 00:13:09.240 phone code bases. 281 00:13:08.879 --> 00:13:10.440 Together, and then the minor numbers. 282 00:13:10.519 --> 00:13:13.440 You have minor numbers for evolutionary tweaks. But for the 283 00:13:13.480 --> 00:13:16.799 developers actually writing the code, the only metric that truly 284 00:13:16.840 --> 00:13:18.320 matters is the API level. 285 00:13:18.559 --> 00:13:23.039 The Application Programming Interface level, and that's a strictly monotonic number, right, 286 00:13:23.080 --> 00:13:26.960 It just counts up sequentially API one, two, three, all 287 00:13:26.960 --> 00:13:29.159 the way up to API twenty four and twenty five, 288 00:13:29.480 --> 00:13:32.399 which corresponds to the NuGet seven point zero release covered 289 00:13:32.440 --> 00:13:32.879 in this book. 290 00:13:33.000 --> 00:13:36.320 Yes, exactly. The API level is what the compiler actually 291 00:13:36.360 --> 00:13:40.240 cares about. Marketing names and decimal points mean absolutely nothing 292 00:13:40.279 --> 00:13:43.080 to the Java compiler. It needs to know exactly which 293 00:13:43.120 --> 00:13:46.399 set of classes and methods are mathematically guaranteed to exist 294 00:13:46.440 --> 00:13:47.120 on the device. 295 00:13:47.559 --> 00:13:50.559 Here's where it gets really interesting, the marketing names. Google 296 00:13:50.639 --> 00:13:55.399 famously names its Android versions after sweet treats in alphabetical order. 297 00:13:55.480 --> 00:13:57.480 Everybody loves the dessert names, right. 298 00:13:57.639 --> 00:14:04.639 You've got cupcake, donut, eclaire, froi Yeo, gingerbread, honeycomb, ice cream, sandwich, jellybean, KitKat, lollipop, marshmallow, 299 00:14:04.679 --> 00:14:07.639 and nougat. But the great trivia fact hidden in the 300 00:14:07.639 --> 00:14:11.000 early days, versions one point zero and one point one 301 00:14:11.080 --> 00:14:13.320 officially lacked dessert names entirely. 302 00:14:13.440 --> 00:14:14.600 Yeah, a lot of people don't know that. 303 00:14:14.799 --> 00:14:17.120 They didn't start the sugar rush until version one point 304 00:14:17.159 --> 00:14:18.039 five with cupcake. 305 00:14:18.440 --> 00:14:22.519 It's brilliant branding, really giving a highly technical operating system 306 00:14:22.600 --> 00:14:27.200 a friendly, accessible face, but beneath that sugary marketing coding 307 00:14:27.639 --> 00:14:31.600 is a deeply serious open source ecosystem. 308 00:14:31.000 --> 00:14:32.600 Because it's based on Linux, right. 309 00:14:32.759 --> 00:14:35.639 Yeah, Android is built on the Android Open Source Project 310 00:14:35.879 --> 00:14:40.080 or AOSP. Google maintains the core code, but because it 311 00:14:40.120 --> 00:14:42.960 is open source, anyone can take it, modify it, and 312 00:14:43.000 --> 00:14:45.879 compile their own custom version of the operating. 313 00:14:45.480 --> 00:14:50.799 System, which spawned entirely independent, renegade community builds. The book 314 00:14:50.799 --> 00:14:53.399 gives a pretty big nod to cyanogen mod, which became 315 00:14:53.519 --> 00:14:57.639 legendary among power users. Why were developers so obsessed with 316 00:14:57.720 --> 00:15:00.919 installing a custom community built OS instead of just using 317 00:15:00.919 --> 00:15:02.000 the one that came on the phone. 318 00:15:02.039 --> 00:15:05.399 Well, because the versions shipped by hardware manufacturers were usually 319 00:15:05.399 --> 00:15:08.360 locked down and heavily bloated with carrier software. 320 00:15:08.480 --> 00:15:11.320 Ah, all those pre installed apps you couldn't delete exactly. 321 00:15:11.639 --> 00:15:15.960 Signogen mod offered a clean, optimized AOSP experience, But more importantly, 322 00:15:16.200 --> 00:15:20.360 it offered independent root access. It gave developers absolute administrative 323 00:15:20.360 --> 00:15:23.200 control over the Linux kernel running beneath Android. 324 00:15:22.879 --> 00:15:24.320 So you could really mess with the hardware. 325 00:15:24.519 --> 00:15:28.919 Oh yeah, you could overclock the processor, heavily modify the UI, 326 00:15:29.399 --> 00:15:33.759 and totally bypass carrier restrictions. When the corporate entity behind 327 00:15:33.799 --> 00:15:37.600 siygnogen mod eventually collapsed, the open source community simply took 328 00:15:37.639 --> 00:15:40.000 the source code and forked it into what is now 329 00:15:40.039 --> 00:15:41.320 known as linear os. 330 00:15:41.600 --> 00:15:44.840 It highlights the fascinating tension in Android, doesn't it. It 331 00:15:44.879 --> 00:15:48.240 is simultaneously controlled by a corporate giant and shaped by 332 00:15:48.279 --> 00:15:50.159 a rebellious open source tribe. 333 00:15:50.240 --> 00:15:52.559 It's a very unique dynamic in the tech world. 334 00:15:52.720 --> 00:15:55.919 But this incredible diversity, the open source forks, the different 335 00:15:55.919 --> 00:16:00.559 hardware manufacturers, the constant march of API levels, it creates 336 00:16:00.600 --> 00:16:04.480 a massive existential headache for the people actually trying to 337 00:16:04.559 --> 00:16:06.320 build apps for the platform. 338 00:16:06.559 --> 00:16:10.320 You're referring to the dreaded fragmentation issue. Yes, Android's philosophy 339 00:16:10.360 --> 00:16:13.240 is rooted in backward compatibility. If you wrote an app 340 00:16:13.240 --> 00:16:16.440 in twenty ten for API level four, the modern Android 341 00:16:16.519 --> 00:16:19.720 nugaeos will bend over backward to run it perfectly. 342 00:16:19.279 --> 00:16:21.440 Which is great, But time travel only works in one 343 00:16:21.440 --> 00:16:22.399 direction exactly. 344 00:16:22.399 --> 00:16:24.679 The reverse is an absolute nightmare. Right. 345 00:16:24.799 --> 00:16:26.919 If you build a new app today and you use 346 00:16:26.960 --> 00:16:30.320 a shiny new location API that was just introduced in NuGet, 347 00:16:30.759 --> 00:16:31.080 you have. 348 00:16:31.039 --> 00:16:33.039 A problem, a huge problem. 349 00:16:33.279 --> 00:16:36.399 If a user with an older phone running KitKat, downloads 350 00:16:36.440 --> 00:16:39.080 your app and your code calls that new API, the 351 00:16:39.159 --> 00:16:43.039 app will instantly crash. That location feature literally does not 352 00:16:43.200 --> 00:16:47.080 exist in the older operating system's vocabulary. It throws a 353 00:16:47.120 --> 00:16:48.279 no such method error. 354 00:16:48.559 --> 00:16:52.159 So developers walk a perpetual tightrope. They have to declare 355 00:16:52.240 --> 00:16:54.919 a target set version to use the newest features, but 356 00:16:55.039 --> 00:16:57.840 also a mindsteck version to keep the app available to 357 00:16:57.919 --> 00:17:00.679 millions of users on older device. 358 00:17:00.480 --> 00:17:02.320 So they just write two versions of the code. 359 00:17:02.480 --> 00:17:05.720 Pretty much, they end up writing endless blocks of conditional code. 360 00:17:05.799 --> 00:17:08.559 If the phone is running NuGet, do this if it's older, 361 00:17:08.720 --> 00:17:10.480 fall back to this clunky workaround. 362 00:17:10.640 --> 00:17:14.519 Handling that fragmentation requires incredible tooling. You can't just use 363 00:17:14.559 --> 00:17:17.359 notepad to write this stuff anymore. Which brings us to 364 00:17:17.359 --> 00:17:20.319 the final piece of the puzzle, the builder's tools. We 365 00:17:20.359 --> 00:17:23.279 are talking about the evolution from simple text files to 366 00:17:23.720 --> 00:17:25.960 massive industrial development environments. 367 00:17:26.319 --> 00:17:28.920 Yeah, and the book provides a wonderful historical grounding by 368 00:17:28.920 --> 00:17:30.640 mentioning Brian Kernigan and PJ. 369 00:17:30.759 --> 00:17:32.400 Plogger the Hello world guys. 370 00:17:32.680 --> 00:17:35.839 Right. They popularized the Hello World concept back in nineteen 371 00:17:35.880 --> 00:17:39.559 seventy eight with the C programming language. The premise was simple. 372 00:17:40.240 --> 00:17:42.480 If you can get a new system to compile and 373 00:17:42.559 --> 00:17:45.519 print the words hello world to the screen, you have 374 00:17:45.559 --> 00:17:47.640 successfully mastered the basic toolchain. 375 00:17:47.880 --> 00:17:52.720 But the Android toolchain has evolved into basically an ideological battleground. 376 00:17:53.160 --> 00:17:56.519 It really has. For years, the undisputed champion for Android 377 00:17:56.559 --> 00:18:00.559 development was Eclipse, utilizing a plug in cal called ADT 378 00:18:01.079 --> 00:18:02.359 or Android Development Tools. 379 00:18:02.440 --> 00:18:05.200 The CLIPS was the old faithful. It was lightweight, it 380 00:18:05.240 --> 00:18:07.519 was predictable, and developers really understood it. 381 00:18:07.519 --> 00:18:10.880 It was essentially a glorified text editor with a compiler attached. 382 00:18:11.640 --> 00:18:15.680 But as Android grew wildly complex, Google shifted its massive 383 00:18:15.720 --> 00:18:19.200 weight behind a completely new standard Android Studio, which is 384 00:18:19.240 --> 00:18:22.240 built on top of jet Brain's intelligay Idea platform. 385 00:18:22.359 --> 00:18:24.799 And this transition wasn't just a fresh code of paint. 386 00:18:25.000 --> 00:18:28.200 It was a violent structural earthquake for how projects were organized. 387 00:18:28.680 --> 00:18:32.160 Let's dissect that structural shift, because the contrast is staggering. 388 00:18:32.240 --> 00:18:34.799 The file structures are entirely different. The book points out 389 00:18:34.799 --> 00:18:37.720 that Eclipse requires just two main project files to keep 390 00:18:37.720 --> 00:18:40.799 track of your app's architecture. Just a dot project file 391 00:18:40.839 --> 00:18:45.079 and a Dot class path file. Two files. It's incredibly transparent. 392 00:18:45.160 --> 00:18:46.720 Yeah, very simple, but then. 393 00:18:46.599 --> 00:18:49.519 Android's Studio steps into the ring, powered by the Gradle 394 00:18:49.519 --> 00:18:53.440 build automation tool. Suddenly your simple app requires an absolute 395 00:18:53.519 --> 00:18:57.119 maze of over thirty auto generated configuration files, and it 396 00:18:57.200 --> 00:19:00.799 forces everything into a mandatory new subdirector called app. 397 00:19:01.279 --> 00:19:05.200 And that structural mandate caused widespread panic for developers who 398 00:19:05.240 --> 00:19:08.799 had years of legacy codes stored in Eclipse. Google provided 399 00:19:08.799 --> 00:19:11.839 an automatic import tool in Android Studio to migrate old 400 00:19:11.839 --> 00:19:13.200 Eclipse projects. 401 00:19:13.000 --> 00:19:14.599