WEBVTT

1
00:00:00.160 --> 00:00:03.200
<v Speaker 1>Have you ever peered beyond the apps and the sleek

2
00:00:03.240 --> 00:00:06.839
<v Speaker 1>interface of your Android phone and wondered what truly makes

3
00:00:06.879 --> 00:00:11.000
<v Speaker 1>it tick? Today, we're not just scratching the surface. We're

4
00:00:11.000 --> 00:00:13.960
<v Speaker 1>taking a deep dive into Android's core internals.

5
00:00:14.080 --> 00:00:16.519
<v Speaker 2>Yeah, getting into the nuts and bolts exactly.

6
00:00:16.760 --> 00:00:19.719
<v Speaker 1>We're going straight to the source with insights from Jonathan

7
00:00:19.800 --> 00:00:25.079
<v Speaker 1>Levin's Android Internals, a Confectioner's cookbook, Volume one. And this

8
00:00:25.160 --> 00:00:28.559
<v Speaker 1>book it's written specifically for you, the power user, right.

9
00:00:28.879 --> 00:00:31.280
<v Speaker 2>And what's truly fascinating about this source, I think is

10
00:00:31.320 --> 00:00:34.920
<v Speaker 2>that it's not some dry technical manual just for developers,

11
00:00:35.159 --> 00:00:37.560
<v Speaker 2>not at all. No, it's more of a conceptual journey.

12
00:00:37.960 --> 00:00:41.000
<v Speaker 2>It's rich with illustrations, and it's really designed to give

13
00:00:41.000 --> 00:00:44.600
<v Speaker 2>you a profound understanding without getting totally lost and lines

14
00:00:44.640 --> 00:00:47.439
<v Speaker 2>and lines of code. Okay, So our mission here is

15
00:00:47.479 --> 00:00:51.359
<v Speaker 2>to distill those essential nuggets of knowledge, basically offer you

16
00:00:51.399 --> 00:00:55.320
<v Speaker 2>a shortcut to mastering the very foundations of well, the

17
00:00:55.359 --> 00:00:57.200
<v Speaker 2>world's most popular operating system.

18
00:00:57.439 --> 00:01:00.520
<v Speaker 1>And what a mission it is. So, whether you're maybe

19
00:01:00.560 --> 00:01:03.320
<v Speaker 1>brushing up for a meeting, exploring a new field, or

20
00:01:03.399 --> 00:01:09.400
<v Speaker 1>just driven by insatiable curiosity, prepare for some genuine aha

21
00:01:09.680 --> 00:01:13.959
<v Speaker 1>moments will navigate Androids a unique design. It's sophisticated file system,

22
00:01:14.400 --> 00:01:19.480
<v Speaker 1>the intricate boot process, and those silent services that keep

23
00:01:19.519 --> 00:01:22.640
<v Speaker 1>it all running smoothly, always with its Linux foundations in mind.

24
00:01:22.680 --> 00:01:24.120
<v Speaker 2>Of course, Absolutely, you're.

25
00:01:23.959 --> 00:01:28.000
<v Speaker 1>About to gain a thorough understanding, hopefully without the information overload.

26
00:01:28.159 --> 00:01:28.959
<v Speaker 2>Yeah, that's the plan.

27
00:01:29.239 --> 00:01:32.840
<v Speaker 1>So to begin, let's consider the unique lens we're getting here.

28
00:01:33.000 --> 00:01:36.120
<v Speaker 1>Jonathan Lovin, our author, He brings a remarkable journey to

29
00:01:36.159 --> 00:01:40.200
<v Speaker 1>this book. We're talking Unix, Linux, Windows, OSX and deep

30
00:01:40.239 --> 00:01:43.480
<v Speaker 1>into security, right, a broad background, and he recognized that

31
00:01:43.640 --> 00:01:48.239
<v Speaker 1>understanding security is and I quote largely a projection of internals,

32
00:01:48.840 --> 00:01:51.640
<v Speaker 1>which is well a profound insight when you think about it,

33
00:01:51.640 --> 00:01:52.159
<v Speaker 1>it really is.

34
00:01:52.239 --> 00:01:54.319
<v Speaker 2>It shapes how you look at security problems.

35
00:01:54.519 --> 00:01:58.079
<v Speaker 1>He's tackled Apple's operating systems before, but this Android book

36
00:01:58.200 --> 00:02:01.840
<v Speaker 1>it's his first self published work, and it's crafted specifically

37
00:02:01.920 --> 00:02:06.760
<v Speaker 1>to give you the power user, this deeper conceptual understanding.

38
00:02:07.280 --> 00:02:10.560
<v Speaker 1>It's a perspective rooted in like decades of hands on

39
00:02:10.719 --> 00:02:11.759
<v Speaker 1>system analysis.

40
00:02:12.080 --> 00:02:16.240
<v Speaker 2>That background is so crucial because it immediately helps us

41
00:02:16.240 --> 00:02:20.240
<v Speaker 2>tackle a common misconception when people say Android is built

42
00:02:20.319 --> 00:02:23.919
<v Speaker 2>on Linux. I mean, how true is that really question.

43
00:02:24.080 --> 00:02:27.520
<v Speaker 2>Levin makes it super clear, it's not just another Linux distribution.

44
00:02:27.639 --> 00:02:28.000
<v Speaker 1>Okay.

45
00:02:28.080 --> 00:02:30.199
<v Speaker 2>Well, the kernel, the absolute core of the OS, it

46
00:02:30.240 --> 00:02:32.520
<v Speaker 2>shares a lot with standard Linux, yes, But the user

47
00:02:32.520 --> 00:02:34.919
<v Speaker 2>mode side, so everything above the kernel, that's where it

48
00:02:34.960 --> 00:02:40.439
<v Speaker 2>diverges significantly. Well, we see two entirely new components that

49
00:02:40.439 --> 00:02:44.159
<v Speaker 2>are pure androidisms, as he calls them. First the Delphic runtime,

50
00:02:44.199 --> 00:02:47.680
<v Speaker 2>which has since evolved into art the Android runtime, and

51
00:02:47.879 --> 00:02:51.120
<v Speaker 2>second the hardware distraction layer usually called the HL. It

52
00:02:51.159 --> 00:02:54.199
<v Speaker 2>basically provides a uniform interface to all the different device

53
00:02:54.240 --> 00:02:55.159
<v Speaker 2>hardware out there.

54
00:02:55.080 --> 00:02:59.000
<v Speaker 1>Like a translator between the software and the specific chips exactly.

55
00:02:59.120 --> 00:03:02.360
<v Speaker 2>And on top of that, Android uses a custom in

56
00:03:02.439 --> 00:03:05.400
<v Speaker 2>it process, not the traditional Linux one, and the BIONICC

57
00:03:05.560 --> 00:03:08.960
<v Speaker 2>library instead of the standard glib. These aren't just minor tweaks.

58
00:03:09.240 --> 00:03:10.879
<v Speaker 1>All sounds fundamental they are.

59
00:03:10.919 --> 00:03:16.840
<v Speaker 2>They're fundamental architectural choices that make Android distinct and uniquely

60
00:03:16.879 --> 00:03:20.400
<v Speaker 2>optimized for the constraints of mobile devices. I think battery

61
00:03:20.439 --> 00:03:22.039
<v Speaker 2>life memory limits.

62
00:03:21.840 --> 00:03:25.960
<v Speaker 1>That distinction Linux foundation, but with its own unique, highly

63
00:03:26.000 --> 00:03:29.599
<v Speaker 1>specialized architecture that's really key. It makes you wonder how

64
00:03:29.599 --> 00:03:34.479
<v Speaker 1>did these early architectural choices shape androids incredibly rapid evolution.

65
00:03:34.759 --> 00:03:35.680
<v Speaker 2>Yeah, it's been fast.

66
00:03:35.879 --> 00:03:38.319
<v Speaker 1>I mean we've seen a dozen major versions, twenty one

67
00:03:38.360 --> 00:03:41.280
<v Speaker 1>API levels in just what seven years since it started?

68
00:03:41.719 --> 00:03:44.120
<v Speaker 1>From a power users standpoint? What were some of those

69
00:03:44.199 --> 00:03:47.000
<v Speaker 1>pivotal system level changes that really made a difference?

70
00:03:47.439 --> 00:03:50.400
<v Speaker 2>Okay, yeah, we connect this to Android's bigger story. Several

71
00:03:50.479 --> 00:03:54.479
<v Speaker 2>versions definitely stand out. They introduce core innovations that fundamentally

72
00:03:54.520 --> 00:03:57.919
<v Speaker 2>altered how Android worked and well how we interact with it.

73
00:03:58.039 --> 00:04:02.000
<v Speaker 2>Which ones Let's start with Froyo twenty ten. This release

74
00:04:02.120 --> 00:04:05.159
<v Speaker 2>wasn't just about giving users more space by letting them

75
00:04:05.159 --> 00:04:07.159
<v Speaker 2>install apps on sd cards tho.

76
00:04:07.240 --> 00:04:08.639
<v Speaker 1>That was big at the time, it.

77
00:04:08.560 --> 00:04:11.000
<v Speaker 2>Was huge, but it was also a critical response to

78
00:04:11.039 --> 00:04:15.680
<v Speaker 2>the exploding app ecosystem, and crucially, it introduced Android Secure

79
00:04:15.719 --> 00:04:17.160
<v Speaker 2>Containers accacs.

80
00:04:17.199 --> 00:04:17.360
<v Speaker 1>Yeah.

81
00:04:17.399 --> 00:04:20.560
<v Speaker 2>I think of ATC as like a secure encrypted vault

82
00:04:20.720 --> 00:04:24.000
<v Speaker 2>for those app files, especially when they're on typically less

83
00:04:24.040 --> 00:04:28.480
<v Speaker 2>secure removable storage. It helped mitigate the new security risks

84
00:04:28.560 --> 00:04:29.959
<v Speaker 2>that came with that flexibility.

85
00:04:30.120 --> 00:04:32.600
<v Speaker 1>Ah, okay, makes sense. What came next?

86
00:04:32.759 --> 00:04:36.040
<v Speaker 2>Then you have Jellybean around twenty twelve twenty thirteen. This

87
00:04:36.079 --> 00:04:39.399
<v Speaker 2>brought multi user support, initially just for tablets, but it

88
00:04:39.439 --> 00:04:40.279
<v Speaker 2>was a massive.

89
00:04:40.000 --> 00:04:43.120
<v Speaker 1>Shift like different logins on one device, exactly.

90
00:04:42.759 --> 00:04:46.040
<v Speaker 2>Separate user interfaces, isolated data just on a desktop. And

91
00:04:46.079 --> 00:04:48.720
<v Speaker 2>for security, it also introduced selnicx to Android. That's a

92
00:04:48.759 --> 00:04:50.480
<v Speaker 2>mandatory access control framework.

93
00:04:50.720 --> 00:04:54.000
<v Speaker 1>Mandatory access control. How's that different from regular permissions?

94
00:04:54.079 --> 00:04:57.519
<v Speaker 2>Well, unlike traditional Linux permissions which are kind of voluntary,

95
00:04:58.360 --> 00:05:02.720
<v Speaker 2>selinicx proactively forces a really strict policy. It's like an

96
00:05:02.720 --> 00:05:06.600
<v Speaker 2>omnipresent security guard, making sure every process only does exactly

97
00:05:06.639 --> 00:05:09.319
<v Speaker 2>what it's explicitly allowed to do, no exceptions.

98
00:05:09.519 --> 00:05:11.920
<v Speaker 1>Wow, okay, sounds strict.

99
00:05:11.759 --> 00:05:16.279
<v Speaker 2>It is and very effective. Jellybean also closed a significant

100
00:05:16.360 --> 00:05:21.959
<v Speaker 2>USB debugging hole by forcing authentication over ADB, another security.

101
00:05:21.480 --> 00:05:24.399
<v Speaker 1>Plus good move. What about KitKat twenty thirteen?

102
00:05:24.600 --> 00:05:28.160
<v Speaker 2>KitKat brought some really clever under the hood optimizations focus

103
00:05:28.199 --> 00:05:28.759
<v Speaker 2>squarely on.

104
00:05:28.759 --> 00:05:31.720
<v Speaker 1>Battery life, always important on mobile definitely.

105
00:05:31.560 --> 00:05:35.160
<v Speaker 2>The implemented timer coalescing and sensor batching. These are intelligent

106
00:05:35.240 --> 00:05:38.959
<v Speaker 2>strategies to basically group together multiple small system events or

107
00:05:39.120 --> 00:05:42.399
<v Speaker 2>sensor readings into single, less frequent operations.

108
00:05:41.879 --> 00:05:43.240
<v Speaker 1>So waking the phone up less.

109
00:05:43.000 --> 00:05:46.199
<v Speaker 2>Often, precisely, instead of waking the system constantly for individual

110
00:05:46.240 --> 00:05:48.360
<v Speaker 2>little updates. Yeah, it would collect them and process them

111
00:05:48.399 --> 00:05:52.480
<v Speaker 2>all at once. Saved significant power Kitcat also introduced dm verity.

112
00:05:52.560 --> 00:05:55.720
<v Speaker 2>Dm verity Yeah, it provides cryptographic integrity checking for the

113
00:05:55.759 --> 00:05:59.720
<v Speaker 2>system partition. It's essentially a digital fingerprint that ensures the

114
00:05:59.720 --> 00:06:02.040
<v Speaker 2>core operating system hasn't been tampered.

115
00:06:01.680 --> 00:06:04.720
<v Speaker 1>With, So checking if the OS files are still the

116
00:06:04.759 --> 00:06:06.040
<v Speaker 1>original trusted.

117
00:06:05.720 --> 00:06:08.240
<v Speaker 2>Ones exactly a really important security feature, okay.

118
00:06:08.240 --> 00:06:11.439
<v Speaker 1>And then Lollipop in twenty fourteen that felt like a huge.

119
00:06:11.160 --> 00:06:16.079
<v Speaker 2>Overhaul, monumental visually, yes, it was material design, but internally

120
00:06:16.480 --> 00:06:19.399
<v Speaker 2>the big news was it fully adopted the Android Run

121
00:06:19.439 --> 00:06:24.759
<v Speaker 2>Time RT, replacing delvic correct and RT was a huge shift.

122
00:06:25.079 --> 00:06:29.040
<v Speaker 2>It compiles application code ahead of time AOT, meaning meaning

123
00:06:29.040 --> 00:06:32.519
<v Speaker 2>it translates the app's code into native machine instructions before

124
00:06:32.560 --> 00:06:34.800
<v Speaker 2>the app even runs, usually during installation.

125
00:06:34.959 --> 00:06:37.959
<v Speaker 1>Ah okay, not just in time like Delva right.

126
00:06:38.120 --> 00:06:41.439
<v Speaker 2>This results in significantly faster application launch times and much

127
00:06:41.439 --> 00:06:44.519
<v Speaker 2>smoother performance overall, especially when paired with its new sixty

128
00:06:44.560 --> 00:06:48.720
<v Speaker 2>four bit architecture support. Lollipop also launched Project.

129
00:06:48.439 --> 00:06:50.360
<v Speaker 1>Volta Volta Battery Improvements again.

130
00:06:50.519 --> 00:06:53.040
<v Speaker 2>Yep, the whole set of improvements for better battery life,

131
00:06:53.120 --> 00:06:55.959
<v Speaker 2>plus more detailed power monitoring tools so you can get

132
00:06:56.000 --> 00:06:58.600
<v Speaker 2>more insight into what's draining your device useful.

133
00:06:59.160 --> 00:07:03.519
<v Speaker 1>And finally, the M Preview in twenty fifteen, M, which.

134
00:07:03.319 --> 00:07:08.000
<v Speaker 2>Became Marshmallow, built further on power management. It introduced dose mode.

135
00:07:08.319 --> 00:07:08.639
<v Speaker 1>Dose.

136
00:07:08.839 --> 00:07:11.519
<v Speaker 2>Yeah, this clever feature detects when your device has been

137
00:07:11.560 --> 00:07:13.920
<v Speaker 2>idle for a long time, like sitting on your nightstand overnight.

138
00:07:14.279 --> 00:07:16.839
<v Speaker 2>It puts it into a much deeper sleep state. Okay,

139
00:07:17.160 --> 00:07:21.439
<v Speaker 2>it only allows brief periodic wakeups for really essential app sinking,

140
00:07:21.959 --> 00:07:25.879
<v Speaker 2>dramatically improving battery life during those long idle periods. M

141
00:07:25.959 --> 00:07:30.040
<v Speaker 2>also extended full data encryption to external storage, boosting overall

142
00:07:30.120 --> 00:07:30.920
<v Speaker 2>data security.

143
00:07:31.199 --> 00:07:33.959
<v Speaker 1>That's a fascinating evolution. You can really see it being

144
00:07:34.000 --> 00:07:37.240
<v Speaker 1>driven by both user demands like more storage and better battery,

145
00:07:37.279 --> 00:07:39.959
<v Speaker 1>and also the unique constraints of mobile computing.

146
00:07:40.040 --> 00:07:41.759
<v Speaker 2>Absolutely, it's a constant balancing act.

147
00:07:42.000 --> 00:07:45.759
<v Speaker 1>So with all these unique components RTHL, the specialized services

148
00:07:45.759 --> 00:07:48.600
<v Speaker 1>and the apps we install, where do they actually live

149
00:07:48.639 --> 00:07:52.759
<v Speaker 1>on the device? Let's crack open? Metaphorically speaking, Android's internal

150
00:07:52.759 --> 00:07:55.439
<v Speaker 1>filing system you said is far more sophisticated than a

151
00:07:55.480 --> 00:07:56.600
<v Speaker 1>simple desktop OS.

152
00:07:56.959 --> 00:08:01.519
<v Speaker 2>It really is. Android uses a complex moultipartition storage scheme.

153
00:08:01.879 --> 00:08:05.199
<v Speaker 2>The specifics might vary a bit between manufacturers or even devices.

154
00:08:05.519 --> 00:08:08.319
<v Speaker 2>But you will primarily encounter three critical partitions.

155
00:08:08.439 --> 00:08:09.360
<v Speaker 1>Okay, what are they?

156
00:08:09.639 --> 00:08:13.560
<v Speaker 2>First, there's system. This is the heart of Android. It's

157
00:08:13.600 --> 00:08:16.319
<v Speaker 2>home to the core OS, all the Google supplied binaries,

158
00:08:16.480 --> 00:08:20.079
<v Speaker 2>the core frameworks, everything that makes Android androids right. Crucially,

159
00:08:20.120 --> 00:08:23.680
<v Speaker 2>it's designed to be mounted read only for security.

160
00:08:23.279 --> 00:08:26.519
<v Speaker 1>So apps can't just change core OS file exactly.

161
00:08:26.720 --> 00:08:29.160
<v Speaker 2>And as we mentioned with KitKat, dm verity, which is

162
00:08:29.160 --> 00:08:31.600
<v Speaker 2>actually a feature of the Linux device map or subsystem,

163
00:08:32.039 --> 00:08:35.080
<v Speaker 2>acts like that, cryptographic checks them. It ensures the system

164
00:08:35.120 --> 00:08:38.200
<v Speaker 2>partition hasn't been tampered with. It's a significant defense and

165
00:08:38.240 --> 00:08:38.960
<v Speaker 2>depth measure.

166
00:08:39.159 --> 00:08:41.759
<v Speaker 1>Okay, system is the read only OS core. What else?

167
00:08:41.879 --> 00:08:44.240
<v Speaker 2>Then? You have data. This is your space. It houses

168
00:08:44.279 --> 00:08:48.559
<v Speaker 2>all your user data, your installed applications, their private data settings, everything.

169
00:08:48.279 --> 00:08:50.080
<v Speaker 1>My photos, my app settings.

170
00:08:49.720 --> 00:08:52.279
<v Speaker 2>All that stuff. And within data data, each app gets

171
00:08:52.320 --> 00:08:56.480
<v Speaker 2>its own unique reverse DNS name subdirectory like comm dot

172
00:08:56.480 --> 00:09:00.480
<v Speaker 2>example dot myapp. This provides script isolation between app.

173
00:09:00.519 --> 00:09:03.639
<v Speaker 1>So one app can't easily peek into another's private files.

174
00:09:03.879 --> 00:09:06.759
<v Speaker 2>Not easily, No, that's the point. And to protect your

175
00:09:06.759 --> 00:09:10.799
<v Speaker 2>privacy further, this entire data partition can be encrypted. This

176
00:09:10.840 --> 00:09:14.399
<v Speaker 2>feature was enabled by default starting with Lollipop using another

177
00:09:14.440 --> 00:09:18.679
<v Speaker 2>device mapp or mechanism called dmcrypt. It encrypts data before

178
00:09:18.720 --> 00:09:20.519
<v Speaker 2>it's even written to the physical.

179
00:09:20.120 --> 00:09:24.080
<v Speaker 1>Storage, so even if someone physically gets the storage chip,

180
00:09:24.360 --> 00:09:26.840
<v Speaker 1>the data is scrambled pretty much.

181
00:09:26.919 --> 00:09:28.200
<v Speaker 2>Yes, without the key, it's just.

182
00:09:28.200 --> 00:09:30.399
<v Speaker 1>Noise, okay, system data. What's through one.

183
00:09:30.480 --> 00:09:33.720
<v Speaker 2>The third main one is cash. It's often overlooked, but

184
00:09:33.799 --> 00:09:37.440
<v Speaker 2>it's vital for things like over the air or OTA

185
00:09:37.519 --> 00:09:41.320
<v Speaker 2>updates and system recovery. It's where validated update packages are

186
00:09:41.320 --> 00:09:43.279
<v Speaker 2>temporarily stored before they get installed.

187
00:09:43.360 --> 00:09:45.480
<v Speaker 1>Ah, temporary storage for updates.

188
00:09:45.600 --> 00:09:48.120
<v Speaker 2>Right and beyond these main partitions, we also have something

189
00:09:48.120 --> 00:09:51.240
<v Speaker 2>called opaque binary blobs or obb's.

190
00:09:51.600 --> 00:09:54.360
<v Speaker 1>OBB sounds mysterious, ah a little.

191
00:09:54.600 --> 00:09:58.279
<v Speaker 2>They weren't true partitions themselves. They basically allow developers to

192
00:09:58.320 --> 00:10:01.080
<v Speaker 2>package up large amounts of additional data up to two

193
00:10:01.120 --> 00:10:04.600
<v Speaker 2>GB for their apps. Think big game assets, high res maps,

194
00:10:04.679 --> 00:10:06.120
<v Speaker 2>multimedia files.

195
00:10:05.840 --> 00:10:09.159
<v Speaker 1>Stuff that doesn't fit easily in the main app package exactly.

196
00:10:09.320 --> 00:10:13.759
<v Speaker 2>These are typically encrypted vfat filesystem images. They get mounted

197
00:10:13.799 --> 00:10:16.679
<v Speaker 2>on demand by a background service, a demon called vold,

198
00:10:17.039 --> 00:10:20.480
<v Speaker 2>again leveraging the kernel's device mapper. It all happens pretty

199
00:10:20.480 --> 00:10:22.279
<v Speaker 2>transparently to the application itself.

200
00:10:22.440 --> 00:10:26.000
<v Speaker 1>Interesting. So we have these real storage partitions backed by

201
00:10:26.039 --> 00:10:30.480
<v Speaker 1>physical flash memory. But you also mentioned pseudo filesystems. That

202
00:10:30.720 --> 00:10:34.919
<v Speaker 1>sounds different. What exactly are those and what vital role

203
00:10:35.080 --> 00:10:35.720
<v Speaker 1>do they play.

204
00:10:35.799 --> 00:10:40.159
<v Speaker 2>Pseudo filesystems are indeed fascinating and really important for understanding

205
00:10:40.159 --> 00:10:44.120
<v Speaker 2>how Android works under the hood. Unlike system or data,

206
00:10:44.240 --> 00:10:46.200
<v Speaker 2>they aren't backed by physical storage at all.

207
00:10:46.320 --> 00:10:48.200
<v Speaker 1>No files on a chip somewhere, nope.

208
00:10:48.440 --> 00:10:52.200
<v Speaker 2>Instead, they're maintained dynamically directly by the kernel using in

209
00:10:52.320 --> 00:10:55.879
<v Speaker 2>memory data structures and special functions called callbacks. Think of

210
00:10:55.879 --> 00:10:58.679
<v Speaker 2>them as dynamic windows into the kernel's live operations in

211
00:10:58.759 --> 00:11:02.320
<v Speaker 2>current state, like a live That's a great analogy. For instance,

212
00:11:02.639 --> 00:11:05.080
<v Speaker 2>prof SIMS. The process file system is essential for tools

213
00:11:05.120 --> 00:11:07.519
<v Speaker 2>like top or profits. It gives you a live view

214
00:11:07.559 --> 00:11:10.720
<v Speaker 2>and all the running processes and threads, their memory usage,

215
00:11:10.799 --> 00:11:15.320
<v Speaker 2>CPU time, et cetera. Then there's CYFTS. This allows userspace programs,

216
00:11:15.480 --> 00:11:19.360
<v Speaker 2>even simple shell commands, to directly query and sometimes interact

217
00:11:19.360 --> 00:11:22.919
<v Speaker 2>with hardware devices managed by the kernel like how well.

218
00:11:22.919 --> 00:11:26.440
<v Speaker 2>For example, you could potentially control your device's vibrator by

219
00:11:26.440 --> 00:11:30.679
<v Speaker 2>simply writing a millisecond value to a specific file within CIFTS.

220
00:11:31.240 --> 00:11:34.360
<v Speaker 2>Maybe something like cysclass dons output vibrator or noble.

221
00:11:34.480 --> 00:11:36.879
<v Speaker 1>Seriously, you can just write to a file to make

222
00:11:36.919 --> 00:11:37.519
<v Speaker 1>the phone.

223
00:11:37.360 --> 00:11:41.080
<v Speaker 2>Vibrate in many cases. Yes. Other important ones include debugs

224
00:11:41.080 --> 00:11:44.840
<v Speaker 2>for debugging kernel features and selenics for interacting with the

225
00:11:44.879 --> 00:11:48.840
<v Speaker 2>Selenic security subsystem. The key thing is these file systems

226
00:11:48.879 --> 00:11:51.440
<v Speaker 2>always reflect the most up to date data from the kernel,

227
00:11:51.960 --> 00:11:55.679
<v Speaker 2>and changes made to writeable files here often take effect immediately,

228
00:11:55.960 --> 00:11:58.159
<v Speaker 2>though they usually don't persist across reboots.

229
00:11:58.240 --> 00:12:00.759
<v Speaker 1>So wow, we have these distinct partitions for the OS

230
00:12:00.759 --> 00:12:04.399
<v Speaker 1>and user data, physical storage obbs for extra app data

231
00:12:04.440 --> 00:12:07.559
<v Speaker 1>in these dynamic pseudo filesystems, reflecting the live kernel state

232
00:12:08.080 --> 00:12:10.480
<v Speaker 1>with all its complexity. How does an Android device even

233
00:12:10.519 --> 00:12:13.480
<v Speaker 1>begin to start up? It sounds like an incredibly intricate

234
00:12:13.600 --> 00:12:15.600
<v Speaker 1>dance to bring the whole system online.

235
00:12:15.799 --> 00:12:19.039
<v Speaker 2>It truly is an intricate choreography, as Levin puts it,

236
00:12:19.279 --> 00:12:21.679
<v Speaker 2>and it starts long before you even see the Android

237
00:12:21.679 --> 00:12:22.360
<v Speaker 2>logo pop.

238
00:12:22.240 --> 00:12:23.679
<v Speaker 1>Up, Before Android itself.

239
00:12:23.799 --> 00:12:27.240
<v Speaker 2>Yeah, the process begins deep down to the device's firmware.

240
00:12:27.440 --> 00:12:30.000
<v Speaker 2>This is somewhat like a PC's BIOS or U e

241
00:12:30.159 --> 00:12:34.519
<v Speaker 2>fi on modern system on chip or soaky devices. This

242
00:12:34.720 --> 00:12:38.519
<v Speaker 2>initial phase is actually quite complex. It involves various specialized

243
00:12:38.559 --> 00:12:43.799
<v Speaker 2>subprocessors working together like Qualcom's RPM create cores, Adrino GPU,

244
00:12:44.039 --> 00:12:48.240
<v Speaker 2>Hexagon DSP, each managing critical hardware tasks, making sure the

245
00:12:48.240 --> 00:12:51.480
<v Speaker 2>basic system is stable and ready before the main Android

246
00:12:51.519 --> 00:12:53.320
<v Speaker 2>bootloader even gets loaded.

247
00:12:53.279 --> 00:12:56.240
<v Speaker 1>So the chip itself has its own little startup sequence exactly.

248
00:12:56.559 --> 00:12:59.799
<v Speaker 2>This initial firmware then loads a secondary bootloader, which eventually

249
00:13:00.279 --> 00:13:02.679
<v Speaker 2>control off to Android's own bootloader.

250
00:13:02.879 --> 00:13:05.080
<v Speaker 1>Okay, now we're getting closer to Android.

251
00:13:04.759 --> 00:13:07.759
<v Speaker 2>Right, and most Android bootloaders support the fast boot protocol.

252
00:13:08.159 --> 00:13:10.440
<v Speaker 2>This is a simple text based mechanism that works over

253
00:13:10.480 --> 00:13:11.360
<v Speaker 2>a USB connection.

254
00:13:11.679 --> 00:13:14.759
<v Speaker 1>Ah, I've heard a fast boot for flashing realms and stuff.

255
00:13:14.799 --> 00:13:17.879
<v Speaker 2>Precisely, it's how power users can flash new system images,

256
00:13:18.039 --> 00:13:21.279
<v Speaker 2>update individual components like the radio, firmware, or even oma,

257
00:13:21.360 --> 00:13:22.639
<v Speaker 2>unlock their device.

258
00:13:22.600 --> 00:13:23.639
<v Speaker 1>Unlocking the bootloader.

259
00:13:23.759 --> 00:13:26.879
<v Speaker 2>Kiss and it's important to remember while unlocking, freeze your

260
00:13:26.919 --> 00:13:29.559
<v Speaker 2>phone to load custom firmware and allows for all sorts

261
00:13:29.600 --> 00:13:33.000
<v Speaker 2>of modifications. It also completely wipes your data.

262
00:13:32.759 --> 00:13:34.759
<v Speaker 1>Partition wipes everything wire.

263
00:13:34.600 --> 00:13:37.759
<v Speaker 2>For security, it prevents an attacker from just unlocking your

264
00:13:37.759 --> 00:13:40.799
<v Speaker 2>device to bypass your PI or password and then copying

265
00:13:40.799 --> 00:13:43.600
<v Speaker 2>off all your personal data from data. It's a critical safeguard.

266
00:13:43.759 --> 00:13:46.120
<v Speaker 1>Makes sense so after the bootloader does its thing.

267
00:13:46.480 --> 00:13:49.480
<v Speaker 2>After its work, the bootloader loads the boot image. This

268
00:13:49.559 --> 00:13:52.879
<v Speaker 2>series typically contains two key things, right, the Linux kernel

269
00:13:52.919 --> 00:13:56.799
<v Speaker 2>itself and an initial RAM disc or any tramps.

270
00:13:56.840 --> 00:13:58.879
<v Speaker 1>Any tramps like a temporary file.

271
00:13:58.679 --> 00:14:01.440
<v Speaker 2>System sort of. But unlike traditional Linux, where the an

272
00:14:01.559 --> 00:14:04.200
<v Speaker 2>TRAMS is usually discarded after the real root file system

273
00:14:04.279 --> 00:14:07.679
<v Speaker 2>is mounted, Android keeps this inny trams resident in memory.

274
00:14:07.879 --> 00:14:11.279
<v Speaker 2>It actually provides the initial root file system environment. Okay,

275
00:14:11.600 --> 00:14:14.159
<v Speaker 2>And from within this inne trams environment, the kernel then

276
00:14:14.240 --> 00:14:18.399
<v Speaker 2>launches the pivotal INNY process. This process gets process ID

277
00:14:18.519 --> 00:14:19.600
<v Speaker 2>one or PID one.

278
00:14:19.639 --> 00:14:21.360
<v Speaker 1>PID one the first one.

279
00:14:21.200 --> 00:14:24.440
<v Speaker 2>The very first user space process started by the kernel.

280
00:14:25.000 --> 00:14:27.879
<v Speaker 2>It's responsible for launching basically everything else in the user

281
00:14:27.919 --> 00:14:32.360
<v Speaker 2>mode world, and famously in Unix like systems, PID one

282
00:14:32.639 --> 00:14:36.279
<v Speaker 2>is special. You can't kill it. This marks that critical

283
00:14:36.320 --> 00:14:39.519
<v Speaker 2>transition from kernel mode operation to user mode operation.

284
00:14:39.879 --> 00:14:43.080
<v Speaker 1>Right, that transition from kernel to user mode orchestrated by

285
00:14:43.080 --> 00:14:45.879
<v Speaker 1>in knit as PID one, that's where the Android system

286
00:14:45.919 --> 00:14:49.080
<v Speaker 1>we actually interact with really begins to take shape. You

287
00:14:49.159 --> 00:14:52.320
<v Speaker 1>called it the progenitor of all other processes. What are

288
00:14:52.360 --> 00:14:55.320
<v Speaker 1>the core responsibilities of this innit process? Why is it

289
00:14:55.360 --> 00:14:56.200
<v Speaker 1>so foundational?

290
00:14:56.480 --> 00:14:58.799
<v Speaker 2>In it is absolutely foundational, I mean just like it's

291
00:14:58.919 --> 00:15:02.080
<v Speaker 2>Unix namesake. Its primary job is to bring the rest

292
00:15:02.080 --> 00:15:03.360
<v Speaker 2>of the system up in user mode.

293
00:15:03.399 --> 00:15:04.360
<v Speaker 1>How does it know what to do?

294
00:15:04.720 --> 00:15:08.039
<v Speaker 2>It achieves this by parsing its configuration files. These are

295
00:15:08.080 --> 00:15:10.240
<v Speaker 2>known as dot rc files, typically found in the root

296
00:15:10.279 --> 00:15:13.639
<v Speaker 2>directory and system mets in it. These files are essentially scripts.

297
00:15:13.679 --> 00:15:16.080
<v Speaker 2>They contain commands and declarations that tell an in which

298
00:15:16.080 --> 00:15:20.080
<v Speaker 2>services to start, which filesystems mounting, system read only and

299
00:15:20.159 --> 00:15:23.039
<v Speaker 2>data read write, and what permissions and ownership to set

300
00:15:23.080 --> 00:15:24.679
<v Speaker 2>on various files and device nodes.

301
00:15:24.960 --> 00:15:28.559
<v Speaker 1>So it's like the master script for booting Android pretty much.

302
00:15:28.639 --> 00:15:32.559
<v Speaker 2>Yeah. It also manages system properties. These are dynamic configuration

303
00:15:32.679 --> 00:15:35.759
<v Speaker 2>values kind of like global variables for the system. They

304
00:15:35.759 --> 00:15:39.360
<v Speaker 2>get read initially from files like default dot prop and

305
00:15:39.519 --> 00:15:42.720
<v Speaker 2>system build dot prop. That build dot prop file contains

306
00:15:42.879 --> 00:15:46.039
<v Speaker 2>tons of info about your specific device bill okay and

307
00:15:46.080 --> 00:15:49.399
<v Speaker 2>beyond just starting things, and it takes on additional critical roles.

308
00:15:49.519 --> 00:15:53.120
<v Speaker 2>It acts as evented listening for kernel events, signaling hardware

309
00:15:53.200 --> 00:15:56.279
<v Speaker 2>changes like when you plug in headphones or a USB drive,

310
00:15:56.519 --> 00:16:00.200
<v Speaker 2>and takes appropriate action. It also incorporates watchdog functionality to

311
00:16:00.240 --> 00:16:03.759
<v Speaker 2>monitor system health and potentially reboot if things get stuck.

312
00:16:03.960 --> 00:16:07.559
<v Speaker 1>So it starts everything, manages configuration, and keeps an eye

313
00:16:07.600 --> 00:16:09.200
<v Speaker 1>on hardware and system health.

314
00:16:09.360 --> 00:16:12.559
<v Speaker 2>In essence, yes, and it dictates how the entire Android

315
00:16:12.639 --> 00:16:15.759
<v Speaker 2>system starts up and ensures that vital services are launched

316
00:16:15.759 --> 00:16:19.399
<v Speaker 2>and maintained. It's designed to be incredibly robust, and importantly,

317
00:16:19.440 --> 00:16:22.080
<v Speaker 2>its operation can't be easily altered from user space. Once

318
00:16:22.120 --> 00:16:26.159
<v Speaker 2>the system is running, any significant modification usually requires flashing

319
00:16:26.159 --> 00:16:28.279
<v Speaker 2>a new, properly signed boot image.

320
00:16:28.399 --> 00:16:31.600
<v Speaker 1>Okay, so in it is the grand conductor for the

321
00:16:31.639 --> 00:16:37.000
<v Speaker 1>whole startup orchestra. But beyond that initial orchestrator, Android runs

322
00:16:37.360 --> 00:16:42.000
<v Speaker 1>countless background services. These demons that handle everything from network

323
00:16:42.000 --> 00:16:45.519
<v Speaker 1>connections to crash reports. Let's maybe highlight a few of

324
00:16:45.559 --> 00:16:48.360
<v Speaker 1>the most critical ones that keep your phone running seamlessly

325
00:16:48.440 --> 00:16:49.279
<v Speaker 1>behind the scenes.

326
00:16:49.480 --> 00:16:53.240
<v Speaker 2>Absolutely, these demons are the silent workhourses. You're right, They

327
00:16:53.279 --> 00:16:56.360
<v Speaker 2>operate tirelessly in the background, and you often only notice

328
00:16:56.360 --> 00:16:58.279
<v Speaker 2>them well when something goes wrong.

329
00:16:58.440 --> 00:16:59.519
<v Speaker 1>Which ones are essential?

330
00:16:59.639 --> 00:17:03.759
<v Speaker 2>Okay? First up service manager. Think of this as Android's

331
00:17:03.919 --> 00:17:07.160
<v Speaker 2>central phone book or directory for almost all other operating

332
00:17:07.200 --> 00:17:10.799
<v Speaker 2>system services. The phone book, Yeah, any application or system

333
00:17:10.839 --> 00:17:13.559
<v Speaker 2>component that needs to interact with another core service. Say

334
00:17:13.880 --> 00:17:16.799
<v Speaker 2>asking the location manager for GPS data, or telling the

335
00:17:16.839 --> 00:17:19.960
<v Speaker 2>window manager to draw something, or accessing the camera service,

336
00:17:20.319 --> 00:17:24.240
<v Speaker 2>it must first consult Service Manager. It asks service manager

337
00:17:24.279 --> 00:17:27.440
<v Speaker 2>for a reference like a handle to that specific service,

338
00:17:27.519 --> 00:17:31.000
<v Speaker 2>so it connects everything. It's the central hub for finding services. Yes,

339
00:17:31.680 --> 00:17:36.279
<v Speaker 2>Without it, interprocess communication or IPC would be severely crippled.

340
00:17:36.920 --> 00:17:39.680
<v Speaker 2>Services couldn't even register their presence within the system for

341
00:17:39.759 --> 00:17:43.240
<v Speaker 2>others to find them. Its actual code is surprisingly small,

342
00:17:43.599 --> 00:17:46.759
<v Speaker 2>but its importance to the entire Android framework is immense.

343
00:17:46.960 --> 00:17:50.000
<v Speaker 1>Okay, service Manager is the connector what else next?

344
00:17:50.400 --> 00:17:53.759
<v Speaker 2>Zygote. This is one of Android's most unique and highly

345
00:17:53.799 --> 00:17:57.480
<v Speaker 2>optimized innovations, specifically for launching applications quickly.

346
00:17:57.759 --> 00:17:59.880
<v Speaker 1>Zygote like the biological.

347
00:17:59.319 --> 00:18:03.240
<v Speaker 2>Term exactly because it forks. Instead of each app starting

348
00:18:03.240 --> 00:18:06.640
<v Speaker 2>its own full Java virtual machine from scratch, which would

349
00:18:06.640 --> 00:18:11.119
<v Speaker 2>be slow in memory intensive, Zygote preloads the core libraries

350
00:18:11.559 --> 00:18:14.279
<v Speaker 2>it starts up early in the boat process, initializes a

351
00:18:14.359 --> 00:18:17.720
<v Speaker 2>Dalvic VM or now IRT, and preloads all the common

352
00:18:17.759 --> 00:18:20.039
<v Speaker 2>Android framework classes and resources into.

353
00:18:19.880 --> 00:18:21.920
<v Speaker 1>Memory, so it gets everything ready beforehand.

354
00:18:22.000 --> 00:18:24.359
<v Speaker 2>Precisely, when you tap an app icon to launch it,

355
00:18:24.640 --> 00:18:27.319
<v Speaker 2>the system doesn't start a new VM. Instead it tells

356
00:18:27.400 --> 00:18:30.440
<v Speaker 2>Zygot to fork itself. Forking creates a near instant copy

357
00:18:30.480 --> 00:18:34.200
<v Speaker 2>of the zydote process, inheriting all that preloaded goodness. This

358
00:18:34.240 --> 00:18:36.960
<v Speaker 2>new process then specializes itself into the app you wanted

359
00:18:36.960 --> 00:18:37.359
<v Speaker 2>to run.

360
00:18:37.680 --> 00:18:40.079
<v Speaker 1>Ah, so it's like having a runner already warmed up

361
00:18:40.119 --> 00:18:41.559
<v Speaker 1>and waiting right at the finish line.

362
00:18:41.599 --> 00:18:45.079
<v Speaker 2>That's a perfect analogy. Camping by the finish line. It

363
00:18:45.200 --> 00:18:49.559
<v Speaker 2>dramatically decreases application startup time by maximizing shared memory. This

364
00:18:49.720 --> 00:18:53.440
<v Speaker 2>makes Android incredibly efficient, especially considering its application layer is

365
00:18:53.519 --> 00:18:57.559
<v Speaker 2>largely Java based, and modern Android with sixty four bit

366
00:18:57.599 --> 00:19:01.160
<v Speaker 2>support actually maintains both thirty two and sixty four bit

367
00:19:01.279 --> 00:19:04.880
<v Speaker 2>Zygo instances for compatibility with all the different apps out there.

368
00:19:04.920 --> 00:19:08.559
<v Speaker 1>Oh that's clever. Okay, service manager's zygot. What about when

369
00:19:08.559 --> 00:19:09.279
<v Speaker 1>things go wrong?

370
00:19:10.039 --> 00:19:13.119
<v Speaker 2>Apps crash sometimes inevitably, Yes, yeah, and that's where debugger

371
00:19:13.200 --> 00:19:17.440
<v Speaker 2>comes in. This is androids building crash reporting mechanism. Conceptually,

372
00:19:17.480 --> 00:19:19.880
<v Speaker 2>it's similar to crash reporter on iOS.

373
00:19:19.480 --> 00:19:21.400
<v Speaker 1>Or macOS, so it catches crashes.

374
00:19:21.599 --> 00:19:24.480
<v Speaker 2>Yeah. When an application receives a fatal signal like a

375
00:19:24.519 --> 00:19:27.640
<v Speaker 2>segmentation fault where it tries to access memory it shouldn't,

376
00:19:28.079 --> 00:19:31.400
<v Speaker 2>or an the illegal instruction. Debuggered automatically steps in. It

377
00:19:31.440 --> 00:19:34.960
<v Speaker 2>attaches to the feeling process, inspects its memory state, gathers

378
00:19:35.000 --> 00:19:37.680
<v Speaker 2>information about the threads, registers and the call stack leading

379
00:19:37.759 --> 00:19:41.359
<v Speaker 2>up to the crash. Okay, and then it generates a tombstone.

380
00:19:40.839 --> 00:19:43.720
<v Speaker 1>At tombstone morbid name a.

381
00:19:43.640 --> 00:19:47.039
<v Speaker 2>Little yeah, but it's basically a compact crash report. It

382
00:19:47.039 --> 00:19:50.519
<v Speaker 2>gets saved in a specific directory, usually dated tombstones. It

383
00:19:50.519 --> 00:19:54.440
<v Speaker 2>provides essential autopsy services what went wrong, where and maybe why,

384
00:19:54.799 --> 00:19:58.480
<v Speaker 2>without needing to generate huge, multi megabyte core dump files,

385
00:19:58.960 --> 00:20:02.319
<v Speaker 2>which just aren't practic on mobile devices with limited storage.

386
00:20:02.440 --> 00:20:04.640
<v Speaker 1>So a quick summary of the crash scene.

387
00:20:04.400 --> 00:20:07.759
<v Speaker 2>Exactly, very useful for developers and sometimes for power users

388
00:20:07.759 --> 00:20:08.880
<v Speaker 2>trying to diagnose issues.

389
00:20:08.960 --> 00:20:10.680
<v Speaker 1>Okay, one more critical demon.

390
00:20:11.039 --> 00:20:14.759
<v Speaker 2>Let's talk about Installed. This demon is responsible for the

391
00:20:15.920 --> 00:20:19.759
<v Speaker 2>rather intricate process of installing and removing application packages the

392
00:20:19.839 --> 00:20:20.759
<v Speaker 2>APK files.

393
00:20:21.000 --> 00:20:23.000
<v Speaker 1>You mean it just copies the APK file.

394
00:20:23.039 --> 00:20:25.480
<v Speaker 2>Oh, it's much more than that. Installed sets up and

395
00:20:25.559 --> 00:20:29.799
<v Speaker 2>maintains the complex directory structure needed for each app. For example,

396
00:20:30.039 --> 00:20:32.880
<v Speaker 2>it creates the apps private data directory under data data,

397
00:20:33.119 --> 00:20:36.279
<v Speaker 2>sets the correct Linux user ID and group ID ownership,

398
00:20:36.599 --> 00:20:40.279
<v Speaker 2>and applies the right file permissions. It also handles placing

399
00:20:40.319 --> 00:20:43.680
<v Speaker 2>the ATK itself maybe in data app and managing private

400
00:20:43.680 --> 00:20:45.000
<v Speaker 2>app libraries.

401
00:20:44.559 --> 00:20:47.799
<v Speaker 1>So it sets up the apps home directory and permissions right,

402
00:20:48.160 --> 00:20:48.559
<v Speaker 1>and it.

403
00:20:48.480 --> 00:20:52.119
<v Speaker 2>Even handles more complex tasks like migrating directory structures when

404
00:20:52.240 --> 00:20:55.519
<v Speaker 2>features like multi user support were introduced back in Jellybean.

405
00:20:56.079 --> 00:21:00.359
<v Speaker 2>A key principle Intalled follows is least privilege, meaning meaning

406
00:21:00.359 --> 00:21:03.000
<v Speaker 2>it starts with high privileges, maybe even root to do

407
00:21:03.039 --> 00:21:07.599
<v Speaker 2>things like create directories owned by specific app UIDs, but

408
00:21:07.759 --> 00:21:10.240
<v Speaker 2>as soon as those tasks are done, it drops those

409
00:21:10.279 --> 00:21:13.839
<v Speaker 2>extra privileges, minimizing the potential attack surface if it were

410
00:21:13.839 --> 00:21:14.680
<v Speaker 2>ever compromised.

411
00:21:14.759 --> 00:21:18.440
<v Speaker 1>Smart Okay, it's clear that Android is this incredibly complex,

412
00:21:18.640 --> 00:21:22.480
<v Speaker 1>finely tuned machine. But with so many moving parts, so

413
00:21:22.599 --> 00:21:26.559
<v Speaker 1>many demons and apps interacting, security has to be paramount.

414
00:21:26.920 --> 00:21:30.039
<v Speaker 1>Android has certainly faced its share of challenges over the years.

415
00:21:30.400 --> 00:21:33.880
<v Speaker 1>So how is androids security model actually structured? Starting from

416
00:21:33.880 --> 00:21:36.079
<v Speaker 1>those Linux foundations we talked about and building.

417
00:21:35.799 --> 00:21:38.039
<v Speaker 2>Up That's right, security is woven in at multiple layers.

418
00:21:38.400 --> 00:21:42.519
<v Speaker 2>Android takes the standard Linux security model user IDs, group IDs,

419
00:21:42.680 --> 00:21:45.799
<v Speaker 2>file permissions and gives it a really novel interpretation, especially

420
00:21:45.839 --> 00:21:48.720
<v Speaker 2>for its time. Instead of Linux users mapping directly to

421
00:21:48.799 --> 00:21:52.880
<v Speaker 2>human users sitting at the device. Android assigns unique users,

422
00:21:52.880 --> 00:21:58.319
<v Speaker 2>specifically application IDs aids to individual applications.

423
00:21:57.720 --> 00:22:00.440
<v Speaker 1>So each app is its own user essentially.

424
00:22:00.519 --> 00:22:03.960
<v Speaker 2>Yes, When an app is installed, the package manager service

425
00:22:04.200 --> 00:22:07.599
<v Speaker 2>working with installed assigns at a unique AID, typically in

426
00:22:07.680 --> 00:22:11.720
<v Speaker 2>arrange like ten thousand to maybe ninety thousand. This automatically

427
00:22:11.759 --> 00:22:14.400
<v Speaker 2>isolates applications from each other at the kernel level.

428
00:22:14.559 --> 00:22:15.920
<v Speaker 1>How does that isolate them?

429
00:22:16.079 --> 00:22:19.400
<v Speaker 2>Because the kernel enforces standard Linux file permissions based on

430
00:22:19.480 --> 00:22:22.759
<v Speaker 2>these aids. By default, an app running with eight one

431
00:22:22.799 --> 00:22:25.920
<v Speaker 2>seven fifty cannot access files owned by eight one seven

432
00:22:26.039 --> 00:22:30.160
<v Speaker 2>five to one unless permissions are explicitly granted somehow. It's

433
00:22:30.200 --> 00:22:32.759
<v Speaker 2>the same principle that keeps different human users separated on

434
00:22:32.799 --> 00:22:35.400
<v Speaker 2>a traditional uniax server, but applied to apps.

435
00:22:35.759 --> 00:22:37.759
<v Speaker 1>Okay, that's the basic Linux level isolation.

436
00:22:37.880 --> 00:22:40.359
<v Speaker 2>What else beyond the foundation? We have selinicx, the mandatory

437
00:22:40.400 --> 00:22:43.319
<v Speaker 2>access control framework which touched on earlier, introduced properly in

438
00:22:43.400 --> 00:22:45.480
<v Speaker 2>Jellybean and made enforcing in later versions.

439
00:22:45.559 --> 00:22:47.559
<v Speaker 1>The strict security guard exactly.

440
00:22:47.960 --> 00:22:51.599
<v Speaker 2>Selenicx operates alongside the traditional permissions, but adds a much

441
00:22:51.640 --> 00:22:55.319
<v Speaker 2>stricter layer. It enforces a system wide policy that dictates

442
00:22:55.359 --> 00:22:59.640
<v Speaker 2>exactly what operations each process or domain in SELinux terms

443
00:22:59.839 --> 00:23:03.599
<v Speaker 2>is allowed to perform on which types of objects like files, sockets,

444
00:23:03.680 --> 00:23:07.680
<v Speaker 2>or other processes, even if traditional permissions would allow an action.

445
00:23:08.039 --> 00:23:10.720
<v Speaker 2>If the CYLINICX policy forbids it, it's blocked.

446
00:23:10.880 --> 00:23:13.720
<v Speaker 1>So it prevents even privileged processes from misbehaving.

447
00:23:13.839 --> 00:23:18.000
<v Speaker 2>Precisely, it prevents processes from operating outside their strictly defined bounds,

448
00:23:18.319 --> 00:23:22.680
<v Speaker 2>even if they somehow get compromised. Samsung's k and Ox platform,

449
00:23:22.720 --> 00:23:26.720
<v Speaker 2>for example, relies heavily on selnics for its enhanced security features.

450
00:23:26.799 --> 00:23:30.119
<v Speaker 1>Okay, user IDs for apps, selnics anything.

451
00:23:29.799 --> 00:23:33.160
<v Speaker 2>Else capabilities are also critical in the Linux kernel. These

452
00:23:33.200 --> 00:23:36.799
<v Speaker 2>break down the traditional all powerful root user privilege into smaller,

453
00:23:36.880 --> 00:23:38.440
<v Speaker 2>more distinct chunks.

454
00:23:38.079 --> 00:23:41.000
<v Speaker 1>Like specific superpowers instead of one big one kind.

455
00:23:40.799 --> 00:23:44.000
<v Speaker 2>Of yeah, so a process like installed doesn't need full

456
00:23:44.079 --> 00:23:46.359
<v Speaker 2>root access all the time. It might only need the

457
00:23:46.400 --> 00:23:51.480
<v Speaker 2>capability to change file ownership cap shen or bypass directory

458
00:23:51.519 --> 00:23:56.039
<v Speaker 2>permissions captain cover ride for specific tasks. By only granting

459
00:23:56.079 --> 00:23:59.519
<v Speaker 2>the necessary capabilities, the potential damage if that process is

460
00:23:59.559 --> 00:24:03.640
<v Speaker 2>compromised is significantly reduced. It adheres to that principle of

461
00:24:03.759 --> 00:24:05.200
<v Speaker 2>least privilege.

462
00:24:04.680 --> 00:24:06.960
<v Speaker 1>Got it, minimize power where possible.

463
00:24:07.359 --> 00:24:10.880
<v Speaker 2>And finally, for data at rest, the data sitting on

464
00:24:10.920 --> 00:24:15.079
<v Speaker 2>your phone storage, Android offers robust encryption. We mentioned dmcrypt,

465
00:24:15.200 --> 00:24:17.799
<v Speaker 2>using the device mapper to encrypt the entire data partition,

466
00:24:18.000 --> 00:24:21.160
<v Speaker 2>which became default and Lollipop and dm verity insures the

467
00:24:21.160 --> 00:24:25.319
<v Speaker 2>system partitions integrity, preventing malicious modification of the OS itself.

468
00:24:25.880 --> 00:24:28.480
<v Speaker 2>These ensure that even if someone bypasses the lock screen

469
00:24:28.559 --> 00:24:31.319
<v Speaker 2>or gets physical access to the storage chips, your data

470
00:24:31.359 --> 00:24:34.359
<v Speaker 2>remains confidential and the OS integrity is maintained.

471
00:24:34.559 --> 00:24:38.200
<v Speaker 1>That's a pretty comprehensive security stack, layers upon layers. But

472
00:24:38.480 --> 00:24:40.279
<v Speaker 1>what about rooting. We hear about that all the time,

473
00:24:40.359 --> 00:24:44.160
<v Speaker 1>power users, enthusiasts, motters often root their devices. How does

474
00:24:44.200 --> 00:24:47.519
<v Speaker 1>that fit into this intricate security picture you just described.

475
00:24:47.279 --> 00:24:50.440
<v Speaker 2>Ah, rooting, It's truly a double edged sword, no question

476
00:24:50.440 --> 00:24:55.039
<v Speaker 2>about it. Also well for power users, for moters, for

477
00:24:55.119 --> 00:24:59.920
<v Speaker 2>security researchers. Rooting unlocks tremendous advantages. It gives you complete

478
00:25:00.079 --> 00:25:03.279
<v Speaker 2>unrestricted control over the entire system. You can install custom

479
00:25:03.279 --> 00:25:07.960
<v Speaker 2>operating systems ROMs, use advanced diagnostic tools, perform specialized security

480
00:25:08.000 --> 00:25:11.079
<v Speaker 2>audits block ads at the system level, install apps that

481
00:25:11.119 --> 00:25:14.519
<v Speaker 2>require deep system access for things like backup or firewalling,

482
00:25:14.920 --> 00:25:17.680
<v Speaker 2>things far beyond what stock Android permits, so.

483
00:25:17.759 --> 00:25:20.400
<v Speaker 1>Lots of power and flexibility, immense power.

484
00:25:20.759 --> 00:25:25.240
<v Speaker 2>However, from a security standpoint, rooting as leven states essentially

485
00:25:25.680 --> 00:25:28.920
<v Speaker 2>entirely compromises the device's security as it was designed by

486
00:25:28.920 --> 00:25:31.400
<v Speaker 2>Google and the manufacturers entirely compromises.

487
00:25:31.440 --> 00:25:32.200
<v Speaker 1>That sounds bad.

488
00:25:32.599 --> 00:25:35.160
<v Speaker 2>It means that the fundamental security model based on app

489
00:25:35.200 --> 00:25:39.319
<v Speaker 2>isolation and restricted privileges is bypassed. If an adversary, maybe

490
00:25:39.319 --> 00:25:42.440
<v Speaker 2>through a malicious app you install after routing, gains root access,

491
00:25:42.519 --> 00:25:45.200
<v Speaker 2>they can do anything. They can bypass PNS. They can

492
00:25:45.240 --> 00:25:47.559
<v Speaker 2>read data from any app, they can copy the entire

493
00:25:47.640 --> 00:25:51.400
<v Speaker 2>data partition, install keyloggers, spyware, you name it, so.

494
00:25:51.400 --> 00:25:53.599
<v Speaker 1>The walls between apps crumble completely.

495
00:25:54.359 --> 00:25:58.039
<v Speaker 2>We've seen real world exploits over the years, like Geohat's

496
00:25:58.079 --> 00:26:01.759
<v Speaker 2>famous tow root exploit, which cleverly used a bug in

497
00:26:01.799 --> 00:26:05.359
<v Speaker 2>the Linux kernel specifically CVE twenty fourteen three one five

498
00:26:05.440 --> 00:26:09.160
<v Speaker 2>three to gain root access on many devices with just

499
00:26:09.200 --> 00:26:13.000
<v Speaker 2>a tab, or the fake ID vulnerability, which wasn't about

500
00:26:13.000 --> 00:26:16.519
<v Speaker 2>getting root, but allowed malicious apps to essentially forge credentials

501
00:26:16.559 --> 00:26:20.440
<v Speaker 2>and impersonate trusted applications, so these vulnerabilities pop up, they do,

502
00:26:20.599 --> 00:26:23.599
<v Speaker 2>and while Google works tirelessly to patch these vulnerabilities through

503
00:26:23.599 --> 00:26:27.079
<v Speaker 2>security updates, the act of choosing to root fundamentally changes

504
00:26:27.119 --> 00:26:30.839
<v Speaker 2>the device's security posture. It makes it inherently more vulnerable,

505
00:26:31.119 --> 00:26:33.640
<v Speaker 2>especially if the root access method itself isn't from an

506
00:26:33.640 --> 00:26:36.640
<v Speaker 2>absolutely trusted source, or if the user isn't careful about

507
00:26:36.640 --> 00:26:40.000
<v Speaker 2>what they grant root privileges too. Afterwards. It really highlights

508
00:26:40.000 --> 00:26:43.440
<v Speaker 2>that constant tension and Android between its open, flexible, customizable

509
00:26:43.559 --> 00:26:46.839
<v Speaker 2>nature and the need for robust, reliable security for everyone.

510
00:26:47.039 --> 00:26:50.519
<v Speaker 1>It's a very delicate balance indeed. And you know, if

511
00:26:50.599 --> 00:26:53.440
<v Speaker 1>we connect this back to the broader picture of Android's

512
00:26:53.480 --> 00:26:57.799
<v Speaker 1>internal workings, thinking about Zygo, sharing memory or optimizing code,

513
00:26:58.759 --> 00:27:00.880
<v Speaker 1>it sounds like the system is in this constant battle

514
00:27:00.880 --> 00:27:05.200
<v Speaker 1>for efficiency, especially when it comes to memory, particularly given

515
00:27:05.279 --> 00:27:08.160
<v Speaker 1>its general lack of traditional swap space like a desktop

516
00:27:08.160 --> 00:27:08.880
<v Speaker 1>OS might have.

517
00:27:09.319 --> 00:27:12.039
<v Speaker 2>You've hit on a really crucial point there. Android's design,

518
00:27:12.359 --> 00:27:15.599
<v Speaker 2>especially with Delvic and later art, places a huge emphasis

519
00:27:15.640 --> 00:27:19.720
<v Speaker 2>on maximizing shared memory. This is absolutely vital on devices

520
00:27:19.759 --> 00:27:20.680
<v Speaker 2>with constrained rams.

521
00:27:20.799 --> 00:27:21.640
<v Speaker 1>Zigo is key there.

522
00:27:21.880 --> 00:27:24.359
<v Speaker 2>So I go to central yes by pre loading all

523
00:27:24.359 --> 00:27:27.759
<v Speaker 2>those common framework classes and resources. It ensures that the

524
00:27:27.839 --> 00:27:30.400
<v Speaker 2>vast majority of the memory used by the core Android

525
00:27:30.440 --> 00:27:34.279
<v Speaker 2>system is shared across all running apps. Tools leven mentions

526
00:27:34.319 --> 00:27:36.519
<v Speaker 2>like pro crank or a librank can actually show you this.

527
00:27:36.880 --> 00:27:41.039
<v Speaker 2>They distinguish between an app's total memory usage RSS residence

528
00:27:41.039 --> 00:27:44.359
<v Speaker 2>set size and its unique usage USS unique set side, and.

529
00:27:44.359 --> 00:27:45.319
<v Speaker 1>The unique part is small.

530
00:27:45.480 --> 00:27:49.279
<v Speaker 2>Often yes, you might see that the unique footprint the

531
00:27:49.400 --> 00:27:53.240
<v Speaker 2>USS of many apps is just a few megabytes, maybe

532
00:27:53.279 --> 00:27:56.160
<v Speaker 2>eighty five percent, ninety percent or even more of their

533
00:27:56.200 --> 00:28:00.640
<v Speaker 2>total RSS is actually shared memory pages shared thanks to Zygote,

534
00:28:00.839 --> 00:28:03.480
<v Speaker 2>shared thanks to precompiled art files like boot dot oat

535
00:28:03.519 --> 00:28:06.319
<v Speaker 2>that contained framework code, and even shared things to a

536
00:28:06.319 --> 00:28:10.480
<v Speaker 2>Linux kernel feature called Kernel sain Page Merging or KSM KSM.

537
00:28:10.559 --> 00:28:11.160
<v Speaker 1>What does that do?

538
00:28:11.480 --> 00:28:14.680
<v Speaker 2>KSM is a kernel demon that periodically scans physical memory

539
00:28:14.759 --> 00:28:17.559
<v Speaker 2>looking for identical pages. If it finds two or more

540
00:28:17.559 --> 00:28:20.440
<v Speaker 2>identical pages, it merges them into a single physical page,

541
00:28:20.599 --> 00:28:23.279
<v Speaker 2>marks it as copy on right, and frees up the duplicates.

542
00:28:23.640 --> 00:28:24.960
<v Speaker 2>It happens transparently to the.

543
00:28:24.960 --> 00:28:27.440
<v Speaker 1>Applications, so more automatic memory saving.

544
00:28:27.599 --> 00:28:31.359
<v Speaker 2>Exactly all these mechanisms work together to make Android remarkably

545
00:28:31.440 --> 00:28:34.440
<v Speaker 2>memory efficient. However, you're right about the swap space.

546
00:28:34.599 --> 00:28:36.119
<v Speaker 1>Most Android devices don't use it.

547
00:28:36.240 --> 00:28:39.559
<v Speaker 2>Traditionally no using flash memory the type of storage and

548
00:28:39.599 --> 00:28:42.640
<v Speaker 2>phones for frequent swap operations. Writing memory pages out to

549
00:28:42.640 --> 00:28:45.920
<v Speaker 2>DISC when RAM gets full would drastically reduce this lifespan.

550
00:28:46.359 --> 00:28:48.480
<v Speaker 2>Flash memory has a limited number of right cycles.

551
00:28:48.559 --> 00:28:51.359
<v Speaker 1>Okay, so no swap cushion. What happens when memory runs

552
00:28:51.359 --> 00:28:52.640
<v Speaker 1>out right without swap?

553
00:28:52.680 --> 00:28:55.880
<v Speaker 2>Out of memory or OHAM conditions become a much more

554
00:28:55.920 --> 00:28:59.680
<v Speaker 2>immediate threat. If the system truly runs out of available RAM,

555
00:28:59.839 --> 00:29:03.200
<v Speaker 2>the pernel might start randomly killing processes, or the whole

556
00:29:03.240 --> 00:29:06.200
<v Speaker 2>system could become unstable and crash or reboot. Not good,

557
00:29:06.519 --> 00:29:09.839
<v Speaker 2>definitely not good for user experience. To prevent this worst

558
00:29:09.839 --> 00:29:13.759
<v Speaker 2>case scenario, Android emplays another one of those specific androidisms,

559
00:29:14.400 --> 00:29:17.039
<v Speaker 2>the LMANKD or low memory killer demon.

560
00:29:17.359 --> 00:29:20.200
<v Speaker 1>Low memory killer sounds ominous.

561
00:29:19.759 --> 00:29:22.240
<v Speaker 2>It does. The ALMINKD runs as a kernel module or

562
00:29:22.279 --> 00:29:26.039
<v Speaker 2>demon and continuously monitors the system's memory pressure based on

563
00:29:26.119 --> 00:29:29.000
<v Speaker 2>predefined thresholds and the omscore edge value assigned to each

564
00:29:29.079 --> 00:29:32.640
<v Speaker 2>running process, which indicates its importance. The elman kady preemptively

565
00:29:32.720 --> 00:29:35.920
<v Speaker 2>kills less important background processes before the system hits a

566
00:29:35.920 --> 00:29:37.240
<v Speaker 2>critical om state.

567
00:29:37.119 --> 00:29:40.119
<v Speaker 1>So it sacrifices background apps to save the foreground app

568
00:29:40.160 --> 00:29:40.839
<v Speaker 1>and the system.

569
00:29:41.200 --> 00:29:45.759
<v Speaker 2>That's the idea. It's a pragmatic, sometimes aggressive approach. Users

570
00:29:45.839 --> 00:29:48.079
<v Speaker 2>might notice apps they haven't used recently need to reload

571
00:29:48.160 --> 00:29:50.960
<v Speaker 2>fully when they switch back, but it's deemed necessary to

572
00:29:51.039 --> 00:29:54.160
<v Speaker 2>keep the currently active app responsive and prevent the entire

573
00:29:54.200 --> 00:29:57.200
<v Speaker 2>system from grinding to a halt or crashing due to

574
00:29:57.240 --> 00:30:01.000
<v Speaker 2>memory starvation. It really reflects the practical rea of managing

575
00:30:01.039 --> 00:30:03.279
<v Speaker 2>limited resources on mobile devices.

576
00:30:03.400 --> 00:30:07.240
<v Speaker 1>Wow, what an incredible journey we've taken. Guided by Jonathan

577
00:30:07.279 --> 00:30:11.000
<v Speaker 1>Levin's unique perspective and Android internals, We've really taken a

578
00:30:11.000 --> 00:30:12.240
<v Speaker 1>deep dive, haven't we?

579
00:30:12.240 --> 00:30:12.720
<v Speaker 2>We really have.

580
00:30:13.079 --> 00:30:17.079
<v Speaker 1>We went from Android's Linux foundations, traced its rapid evolution

581
00:30:17.519 --> 00:30:20.759
<v Speaker 1>through pivotal versions like Lollipop and kit Kat with all

582
00:30:20.759 --> 00:30:23.599
<v Speaker 1>those neat features like artt and Doze.

583
00:30:24.200 --> 00:30:25.240
<v Speaker 2>The filesys details.

584
00:30:25.319 --> 00:30:29.119
<v Speaker 1>Yeah, explored the intricate dance of its filesys system data,

585
00:30:29.240 --> 00:30:33.160
<v Speaker 1>those pseudo filesystems, and that complex boot process starting way

586
00:30:33.200 --> 00:30:34.200
<v Speaker 1>down in the firmware, and.

587
00:30:34.160 --> 00:30:39.599
<v Speaker 2>The demons in its Zygote service manager installed the unsung.

588
00:30:39.279 --> 00:30:43.200
<v Speaker 1>Heroes exactly unveiled the critical roles of Inausley and those

589
00:30:43.279 --> 00:30:47.880
<v Speaker 1>essential demons and navigated the complex layers of security UIDs

590
00:30:47.960 --> 00:30:52.119
<v Speaker 1>so Linux capabilities, encryption, and finally the constant battle for

591
00:30:52.200 --> 00:30:54.160
<v Speaker 1>memory management that orchestrates it all.

592
00:30:54.279 --> 00:30:56.680
<v Speaker 2>And if we connect all that back to the bigger picture,

593
00:30:57.039 --> 00:31:00.119
<v Speaker 2>hopefully you now possess a far richer understanding of of

594
00:31:00.599 --> 00:31:04.680
<v Speaker 2>the frankly ingenious engineering that's humming away inside the device,

595
00:31:04.839 --> 00:31:08.720
<v Speaker 2>likely in your hand or pocket right now. Yeah, this

596
00:31:08.799 --> 00:31:12.480
<v Speaker 2>deep dive, I hope, has illuminated how Android meticulously balances

597
00:31:12.519 --> 00:31:16.200
<v Speaker 2>its open source nature, that flexibility with an unyielding need

598
00:31:16.240 --> 00:31:20.119
<v Speaker 2>for robust security, and how it constantly optimizes resources to

599
00:31:20.160 --> 00:31:23.640
<v Speaker 2>deliver the seamless powerful experience you've come to expect, all

600
00:31:23.680 --> 00:31:26.400
<v Speaker 2>without needing to weidhe through millions of lines of course

601
00:31:26.440 --> 00:31:27.039
<v Speaker 2>code yourself.

602
00:31:27.079 --> 00:31:30.720
<v Speaker 1>So what does this all mean for you listening right now? Android? Yeah,

603
00:31:30.720 --> 00:31:32.720
<v Speaker 1>it's an open source system, But how many people can

604
00:31:32.759 --> 00:31:35.079
<v Speaker 1>really sit down and sift through those millions of lines

605
00:31:35.079 --> 00:31:37.799
<v Speaker 1>of Java, c C plus plus XML all the rest

606
00:31:38.119 --> 00:31:40.839
<v Speaker 1>to figure out how it actually works, let alone connect

607
00:31:40.839 --> 00:31:43.880
<v Speaker 1>those intricate details back to their daily experience with their phone.

608
00:31:43.920 --> 00:31:45.599
<v Speaker 2>It's a huge undertaking, it is.

609
00:31:45.839 --> 00:31:48.279
<v Speaker 1>We hope this deep dive has revealed some of that

610
00:31:48.359 --> 00:31:52.920
<v Speaker 1>hitting complexity, maybe some surprising facts that make Android so powerful,

611
00:31:53.079 --> 00:31:56.880
<v Speaker 1>so adaptable, and also so resilient despite the challenges. The

612
00:31:56.960 --> 00:31:59.759
<v Speaker 1>real question is armed with this new found understanding of

613
00:31:59.799 --> 00:32:02.519
<v Speaker 1>its depths, what aspect of androids hidden world will you

614
00:32:02.559 --> 00:32:03.279
<v Speaker 1>explore next