Android Internals::Power User's View

Have you ever peered beyond the apps and the sleek interface of your Android phone and wondered what truly makes it tick? Today, we're not just scratching the surface. We're taking a deep dive into Android's core internals.

Yeah, getting into the nuts and bolts exactly.

We're going straight to the source with insights from Jonathan Levin's Android Internals, a Confectioner's cookbook, Volume one. And this book it's written specifically for you, the power user, right.

And what's truly fascinating about this source, I think is that it's not some dry technical manual just for developers, not at all. No, it's more of a conceptual journey. It's rich with illustrations, and it's really designed to give you a profound understanding without getting totally lost and lines

And what a mission it is. So, whether you're maybe brushing up for a meeting, exploring a new field, or just driven by insatiable curiosity, prepare for some genuine aha moments will navigate Androids a unique design. It's sophisticated file system, the intricate boot process, and those silent services that keep it all running smoothly, always with its Linux foundations in mind.

Of course, Absolutely, you're.

About to gain a thorough understanding, hopefully without the information overload.

Yeah, that's the plan.

So to begin, let's consider the unique lens we're getting here. Jonathan Lovin, our author, He brings a remarkable journey to this book. We're talking Unix, Linux, Windows, OSX and deep into security, right, a broad background, and he recognized that understanding security is and I quote largely a projection of internals, which is well a profound insight when you think about it, it really is.

It shapes how you look at security problems.

He's tackled Apple's operating systems before, but this Android book it's his first self published work, and it's crafted specifically to give you the power user, this deeper conceptual understanding. It's a perspective rooted in like decades of hands on system analysis.

That background is so crucial because it immediately helps us tackle a common misconception when people say Android is built on Linux. I mean, how true is that really question. Levin makes it super clear, it's not just another Linux distribution.

Okay.

Well, the kernel, the absolute core of the OS, it shares a lot with standard Linux, yes, But the user mode side, so everything above the kernel, that's where it diverges significantly. Well, we see two entirely new components that are pure androidisms, as he calls them. First the Delphic runtime, which has since evolved into art the Android runtime, and

Like a translator between the software and the specific chips exactly.

And on top of that, Android uses a custom in it process, not the traditional Linux one, and the BIONICC library instead of the standard glib. These aren't just minor tweaks.

All sounds fundamental they are.

They're fundamental architectural choices that make Android distinct and uniquely optimized for the constraints of mobile devices. I think battery life memory limits.

That distinction Linux foundation, but with its own unique, highly specialized architecture that's really key. It makes you wonder how did these early architectural choices shape androids incredibly rapid evolution.

Yeah, it's been fast.

I mean we've seen a dozen major versions, twenty one API levels in just what seven years since it started? From a power users standpoint? What were some of those pivotal system level changes that really made a difference?

Okay, yeah, we connect this to Android's bigger story. Several versions definitely stand out. They introduce core innovations that fundamentally altered how Android worked and well how we interact with it. Which ones Let's start with Froyo twenty ten. This release wasn't just about giving users more space by letting them install apps on sd cards tho.

That was big at the time, it.

Was huge, but it was also a critical response to the exploding app ecosystem, and crucially, it introduced Android Secure Containers accacs.

Yeah.

I think of ATC as like a secure encrypted vault for those app files, especially when they're on typically less secure removable storage. It helped mitigate the new security risks that came with that flexibility.

Ah, okay, makes sense. What came next?

Then you have Jellybean around twenty twelve twenty thirteen. This brought multi user support, initially just for tablets, but it was a massive.

Shift like different logins on one device, exactly.

Separate user interfaces, isolated data just on a desktop. And for security, it also introduced selnicx to Android. That's a mandatory access control framework.

Mandatory access control. How's that different from regular permissions?

Well, unlike traditional Linux permissions which are kind of voluntary, selinicx proactively forces a really strict policy. It's like an omnipresent security guard, making sure every process only does exactly what it's explicitly allowed to do, no exceptions.

Wow, okay, sounds strict.

It is and very effective. Jellybean also closed a significant USB debugging hole by forcing authentication over ADB, another security.

Plus good move. What about KitKat twenty thirteen?

KitKat brought some really clever under the hood optimizations focus squarely on.

Battery life, always important on mobile definitely.

The implemented timer coalescing and sensor batching. These are intelligent strategies to basically group together multiple small system events or sensor readings into single, less frequent operations.

So waking the phone up less.

Often, precisely, instead of waking the system constantly for individual little updates. Yeah, it would collect them and process them all at once. Saved significant power Kitcat also introduced dm verity. Dm verity Yeah, it provides cryptographic integrity checking for the system partition. It's essentially a digital fingerprint that ensures the core operating system hasn't been tampered.

With, So checking if the OS files are still the original trusted.

Ones exactly a really important security feature, okay.

And then Lollipop in twenty fourteen that felt like a huge.

Overhaul, monumental visually, yes, it was material design, but internally the big news was it fully adopted the Android Run Time RT, replacing delvic correct and RT was a huge shift. It compiles application code ahead of time AOT, meaning meaning it translates the app's code into native machine instructions before the app even runs, usually during installation.

Ah okay, not just in time like Delva right.

This results in significantly faster application launch times and much smoother performance overall, especially when paired with its new sixty four bit architecture support. Lollipop also launched Project.

Volta Volta Battery Improvements again.

Yep, the whole set of improvements for better battery life, plus more detailed power monitoring tools so you can get more insight into what's draining your device useful.

And finally, the M Preview in twenty fifteen, M, which.

Became Marshmallow, built further on power management. It introduced dose mode.

Dose.

Yeah, this clever feature detects when your device has been idle for a long time, like sitting on your nightstand overnight. It puts it into a much deeper sleep state. Okay, it only allows brief periodic wakeups for really essential app sinking, dramatically improving battery life during those long idle periods. M also extended full data encryption to external storage, boosting overall data security.

That's a fascinating evolution. You can really see it being driven by both user demands like more storage and better battery, and also the unique constraints of mobile computing.

Absolutely, it's a constant balancing act.

So with all these unique components RTHL, the specialized services and the apps we install, where do they actually live on the device? Let's crack open? Metaphorically speaking, Android's internal filing system you said is far more sophisticated than a simple desktop OS.

It really is. Android uses a complex moultipartition storage scheme. The specifics might vary a bit between manufacturers or even devices. But you will primarily encounter three critical partitions.

Okay, what are they?

First, there's system. This is the heart of Android. It's home to the core OS, all the Google supplied binaries, the core frameworks, everything that makes Android androids right. Crucially, it's designed to be mounted read only for security.

So apps can't just change core OS file exactly.

And as we mentioned with KitKat, dm verity, which is actually a feature of the Linux device map or subsystem, acts like that, cryptographic checks them. It ensures the system partition hasn't been tampered with. It's a significant defense and depth measure.

Okay, system is the read only OS core. What else?

Then? You have data. This is your space. It houses all your user data, your installed applications, their private data settings, everything.

My photos, my app settings.

All that stuff. And within data data, each app gets its own unique reverse DNS name subdirectory like comm dot example dot myapp. This provides script isolation between app.

So one app can't easily peek into another's private files.

Not easily, No, that's the point. And to protect your privacy further, this entire data partition can be encrypted. This feature was enabled by default starting with Lollipop using another device mapp or mechanism called dmcrypt. It encrypts data before it's even written to the physical.

Storage, so even if someone physically gets the storage chip, the data is scrambled pretty much.

Yes, without the key, it's just.

Noise, okay, system data. What's through one.

The third main one is cash. It's often overlooked, but it's vital for things like over the air or OTA updates and system recovery. It's where validated update packages are temporarily stored before they get installed.

Ah, temporary storage for updates.

Right and beyond these main partitions, we also have something called opaque binary blobs or obb's.

OBB sounds mysterious, ah a little.

They weren't true partitions themselves. They basically allow developers to package up large amounts of additional data up to two GB for their apps. Think big game assets, high res maps, multimedia files.

Stuff that doesn't fit easily in the main app package exactly.

These are typically encrypted vfat filesystem images. They get mounted on demand by a background service, a demon called vold, again leveraging the kernel's device mapper. It all happens pretty transparently to the application itself.

Interesting. So we have these real storage partitions backed by physical flash memory. But you also mentioned pseudo filesystems. That sounds different. What exactly are those and what vital role do they play.

Pseudo filesystems are indeed fascinating and really important for understanding how Android works under the hood. Unlike system or data, they aren't backed by physical storage at all.

No files on a chip somewhere, nope.

Instead, they're maintained dynamically directly by the kernel using in memory data structures and special functions called callbacks. Think of them as dynamic windows into the kernel's live operations in current state, like a live That's a great analogy. For instance, prof SIMS. The process file system is essential for tools like top or profits. It gives you a live view and all the running processes and threads, their memory usage,

Seriously, you can just write to a file to make the phone.

Vibrate in many cases. Yes. Other important ones include debugs for debugging kernel features and selenics for interacting with the Selenic security subsystem. The key thing is these file systems always reflect the most up to date data from the kernel, and changes made to writeable files here often take effect immediately, though they usually don't persist across reboots.

So wow, we have these distinct partitions for the OS and user data, physical storage obbs for extra app data in these dynamic pseudo filesystems, reflecting the live kernel state with all its complexity. How does an Android device even begin to start up? It sounds like an incredibly intricate dance to bring the whole system online.

It truly is an intricate choreography, as Levin puts it, and it starts long before you even see the Android logo pop.

Up, Before Android itself.

Yeah, the process begins deep down to the device's firmware. This is somewhat like a PC's BIOS or U e fi on modern system on chip or soaky devices. This initial phase is actually quite complex. It involves various specialized subprocessors working together like Qualcom's RPM create cores, Adrino GPU, Hexagon DSP, each managing critical hardware tasks, making sure the basic system is stable and ready before the main Android bootloader even gets loaded.

So the chip itself has its own little startup sequence exactly.

This initial firmware then loads a secondary bootloader, which eventually control off to Android's own bootloader.

Okay, now we're getting closer to Android.

Right, and most Android bootloaders support the fast boot protocol. This is a simple text based mechanism that works over a USB connection.

Ah, I've heard a fast boot for flashing realms and stuff.

Precisely, it's how power users can flash new system images, update individual components like the radio, firmware, or even oma, unlock their device.

Unlocking the bootloader.

Kiss and it's important to remember while unlocking, freeze your phone to load custom firmware and allows for all sorts of modifications. It also completely wipes your data.

Partition wipes everything wire.

For security, it prevents an attacker from just unlocking your device to bypass your PI or password and then copying off all your personal data from data. It's a critical safeguard.

Makes sense so after the bootloader does its thing.

After its work, the bootloader loads the boot image. This series typically contains two key things, right, the Linux kernel itself and an initial RAM disc or any tramps.

Any tramps like a temporary file.

System sort of. But unlike traditional Linux, where the an TRAMS is usually discarded after the real root file system is mounted, Android keeps this inny trams resident in memory. It actually provides the initial root file system environment. Okay, And from within this inne trams environment, the kernel then launches the pivotal INNY process. This process gets process ID one or PID one.

PID one the first one.

The very first user space process started by the kernel. It's responsible for launching basically everything else in the user mode world, and famously in Unix like systems, PID one is special. You can't kill it. This marks that critical transition from kernel mode operation to user mode operation.

Right, that transition from kernel to user mode orchestrated by in knit as PID one, that's where the Android system we actually interact with really begins to take shape. You called it the progenitor of all other processes. What are the core responsibilities of this innit process? Why is it so foundational?

In it is absolutely foundational, I mean just like it's Unix namesake. Its primary job is to bring the rest of the system up in user mode.

How does it know what to do?

It achieves this by parsing its configuration files. These are known as dot rc files, typically found in the root directory and system mets in it. These files are essentially scripts. They contain commands and declarations that tell an in which services to start, which filesystems mounting, system read only and data read write, and what permissions and ownership to set on various files and device nodes.

So it's like the master script for booting Android pretty much.

Yeah. It also manages system properties. These are dynamic configuration values kind of like global variables for the system. They get read initially from files like default dot prop and system build dot prop. That build dot prop file contains tons of info about your specific device bill okay and beyond just starting things, and it takes on additional critical roles. It acts as evented listening for kernel events, signaling hardware changes like when you plug in headphones or a USB drive,

So it starts everything, manages configuration, and keeps an eye on hardware and system health.

In essence, yes, and it dictates how the entire Android system starts up and ensures that vital services are launched and maintained. It's designed to be incredibly robust, and importantly, its operation can't be easily altered from user space. Once the system is running, any significant modification usually requires flashing a new, properly signed boot image.

Okay, so in it is the grand conductor for the whole startup orchestra. But beyond that initial orchestrator, Android runs countless background services. These demons that handle everything from network connections to crash reports. Let's maybe highlight a few of the most critical ones that keep your phone running seamlessly behind the scenes.

Absolutely, these demons are the silent workhourses. You're right, They operate tirelessly in the background, and you often only notice them well when something goes wrong.

Which ones are essential?

Okay? First up service manager. Think of this as Android's central phone book or directory for almost all other operating system services. The phone book, Yeah, any application or system component that needs to interact with another core service. Say asking the location manager for GPS data, or telling the window manager to draw something, or accessing the camera service, it must first consult Service Manager. It asks service manager for a reference like a handle to that specific service,

Okay, service Manager is the connector what else next?

Zygote. This is one of Android's most unique and highly optimized innovations, specifically for launching applications quickly.

Zygote like the biological.

Term exactly because it forks. Instead of each app starting its own full Java virtual machine from scratch, which would be slow in memory intensive, Zygote preloads the core libraries it starts up early in the boat process, initializes a Dalvic VM or now IRT, and preloads all the common Android framework classes and resources into.

Memory, so it gets everything ready beforehand.

Precisely, when you tap an app icon to launch it, the system doesn't start a new VM. Instead it tells Zygot to fork itself. Forking creates a near instant copy of the zydote process, inheriting all that preloaded goodness. This new process then specializes itself into the app you wanted to run.

Ah, so it's like having a runner already warmed up and waiting right at the finish line.

That's a perfect analogy. Camping by the finish line. It dramatically decreases application startup time by maximizing shared memory. This makes Android incredibly efficient, especially considering its application layer is largely Java based, and modern Android with sixty four bit support actually maintains both thirty two and sixty four bit Zygo instances for compatibility with all the different apps out there.

Oh that's clever. Okay, service manager's zygot. What about when things go wrong?

Apps crash sometimes inevitably, Yes, yeah, and that's where debugger comes in. This is androids building crash reporting mechanism. Conceptually, it's similar to crash reporter on iOS.

Or macOS, so it catches crashes.

Yeah. When an application receives a fatal signal like a segmentation fault where it tries to access memory it shouldn't, or an the illegal instruction. Debuggered automatically steps in. It attaches to the feeling process, inspects its memory state, gathers information about the threads, registers and the call stack leading up to the crash. Okay, and then it generates a tombstone.

At tombstone morbid name a.

Little yeah, but it's basically a compact crash report. It gets saved in a specific directory, usually dated tombstones. It provides essential autopsy services what went wrong, where and maybe why, without needing to generate huge, multi megabyte core dump files, which just aren't practic on mobile devices with limited storage.

So a quick summary of the crash scene.

Exactly, very useful for developers and sometimes for power users trying to diagnose issues.

Okay, one more critical demon.

Let's talk about Installed. This demon is responsible for the rather intricate process of installing and removing application packages the APK files.

You mean it just copies the APK file.

Oh, it's much more than that. Installed sets up and maintains the complex directory structure needed for each app. For example, it creates the apps private data directory under data data, sets the correct Linux user ID and group ID ownership, and applies the right file permissions. It also handles placing the ATK itself maybe in data app and managing private app libraries.

So it sets up the apps home directory and permissions right, and it.

Even handles more complex tasks like migrating directory structures when features like multi user support were introduced back in Jellybean. A key principle Intalled follows is least privilege, meaning meaning it starts with high privileges, maybe even root to do things like create directories owned by specific app UIDs, but as soon as those tasks are done, it drops those extra privileges, minimizing the potential attack surface if it were ever compromised.

Smart Okay, it's clear that Android is this incredibly complex, finely tuned machine. But with so many moving parts, so many demons and apps interacting, security has to be paramount. Android has certainly faced its share of challenges over the years. So how is androids security model actually structured? Starting from those Linux foundations we talked about and building.

Up That's right, security is woven in at multiple layers. Android takes the standard Linux security model user IDs, group IDs, file permissions and gives it a really novel interpretation, especially for its time. Instead of Linux users mapping directly to human users sitting at the device. Android assigns unique users, specifically application IDs aids to individual applications.

So each app is its own user essentially.

Yes, When an app is installed, the package manager service working with installed assigns at a unique AID, typically in arrange like ten thousand to maybe ninety thousand. This automatically isolates applications from each other at the kernel level.

How does that isolate them?

Because the kernel enforces standard Linux file permissions based on these aids. By default, an app running with eight one seven fifty cannot access files owned by eight one seven five to one unless permissions are explicitly granted somehow. It's the same principle that keeps different human users separated on a traditional uniax server, but applied to apps.

Okay, that's the basic Linux level isolation.

What else beyond the foundation? We have selinicx, the mandatory access control framework which touched on earlier, introduced properly in Jellybean and made enforcing in later versions.

The strict security guard exactly.

Selenicx operates alongside the traditional permissions, but adds a much stricter layer. It enforces a system wide policy that dictates exactly what operations each process or domain in SELinux terms is allowed to perform on which types of objects like files, sockets, or other processes, even if traditional permissions would allow an action. If the CYLINICX policy forbids it, it's blocked.

So it prevents even privileged processes from misbehaving.

Precisely, it prevents processes from operating outside their strictly defined bounds, even if they somehow get compromised. Samsung's k and Ox platform, for example, relies heavily on selnics for its enhanced security features.

Okay, user IDs for apps, selnics anything.

Else capabilities are also critical in the Linux kernel. These break down the traditional all powerful root user privilege into smaller, more distinct chunks.

Like specific superpowers instead of one big one kind.

Of yeah, so a process like installed doesn't need full root access all the time. It might only need the capability to change file ownership cap shen or bypass directory permissions captain cover ride for specific tasks. By only granting the necessary capabilities, the potential damage if that process is compromised is significantly reduced. It adheres to that principle of least privilege.

Got it, minimize power where possible.

And finally, for data at rest, the data sitting on your phone storage, Android offers robust encryption. We mentioned dmcrypt, using the device mapper to encrypt the entire data partition, which became default and Lollipop and dm verity insures the system partitions integrity, preventing malicious modification of the OS itself.

That's a pretty comprehensive security stack, layers upon layers. But what about rooting. We hear about that all the time, power users, enthusiasts, motters often root their devices. How does that fit into this intricate security picture you just described.

Ah, rooting, It's truly a double edged sword, no question about it. Also well for power users, for moters, for security researchers. Rooting unlocks tremendous advantages. It gives you complete

Lots of power and flexibility, immense power.

However, from a security standpoint, rooting as leven states essentially entirely compromises the device's security as it was designed by Google and the manufacturers entirely compromises.

That sounds bad.

It means that the fundamental security model based on app isolation and restricted privileges is bypassed. If an adversary, maybe through a malicious app you install after routing, gains root access, they can do anything. They can bypass PNS. They can read data from any app, they can copy the entire data partition, install keyloggers, spyware, you name it, so.

The walls between apps crumble completely.

We've seen real world exploits over the years, like Geohat's famous tow root exploit, which cleverly used a bug in the Linux kernel specifically CVE twenty fourteen three one five three to gain root access on many devices with just a tab, or the fake ID vulnerability, which wasn't about getting root, but allowed malicious apps to essentially forge credentials and impersonate trusted applications, so these vulnerabilities pop up, they do,

It's a very delicate balance indeed. And you know, if we connect this back to the broader picture of Android's internal workings, thinking about Zygo, sharing memory or optimizing code, it sounds like the system is in this constant battle for efficiency, especially when it comes to memory, particularly given its general lack of traditional swap space like a desktop OS might have.

You've hit on a really crucial point there. Android's design, especially with Delvic and later art, places a huge emphasis on maximizing shared memory. This is absolutely vital on devices with constrained rams.

Zigo is key there.

So I go to central yes by pre loading all those common framework classes and resources. It ensures that the vast majority of the memory used by the core Android system is shared across all running apps. Tools leven mentions like pro crank or a librank can actually show you this. They distinguish between an app's total memory usage RSS residence set size and its unique usage USS unique set side, and.

The unique part is small.

Often yes, you might see that the unique footprint the USS of many apps is just a few megabytes, maybe eighty five percent, ninety percent or even more of their total RSS is actually shared memory pages shared thanks to Zygote, shared thanks to precompiled art files like boot dot oat that contained framework code, and even shared things to a Linux kernel feature called Kernel sain Page Merging or KSM KSM.

What does that do?

KSM is a kernel demon that periodically scans physical memory looking for identical pages. If it finds two or more identical pages, it merges them into a single physical page, marks it as copy on right, and frees up the duplicates. It happens transparently to the.

Applications, so more automatic memory saving.

Exactly all these mechanisms work together to make Android remarkably memory efficient. However, you're right about the swap space.

Most Android devices don't use it.

Traditionally no using flash memory the type of storage and phones for frequent swap operations. Writing memory pages out to DISC when RAM gets full would drastically reduce this lifespan. Flash memory has a limited number of right cycles.

Okay, so no swap cushion. What happens when memory runs out right without swap?

Out of memory or OHAM conditions become a much more immediate threat. If the system truly runs out of available RAM, the pernel might start randomly killing processes, or the whole system could become unstable and crash or reboot. Not good, definitely not good for user experience. To prevent this worst case scenario, Android emplays another one of those specific androidisms, the LMANKD or low memory killer demon.

Low memory killer sounds ominous.

It does. The ALMINKD runs as a kernel module or demon and continuously monitors the system's memory pressure based on predefined thresholds and the omscore edge value assigned to each running process, which indicates its importance. The elman kady preemptively kills less important background processes before the system hits a critical om state.

So it sacrifices background apps to save the foreground app and the system.

That's the idea. It's a pragmatic, sometimes aggressive approach. Users might notice apps they haven't used recently need to reload fully when they switch back, but it's deemed necessary to keep the currently active app responsive and prevent the entire system from grinding to a halt or crashing due to memory starvation. It really reflects the practical rea of managing limited resources on mobile devices.

Wow, what an incredible journey we've taken. Guided by Jonathan Levin's unique perspective and Android internals, We've really taken a deep dive, haven't we?

We really have.

We went from Android's Linux foundations, traced its rapid evolution through pivotal versions like Lollipop and kit Kat with all those neat features like artt and Doze.

The filesys details.

Yeah, explored the intricate dance of its filesys system data, those pseudo filesystems, and that complex boot process starting way down in the firmware, and.

The demons in its Zygote service manager installed the unsung.

Heroes exactly unveiled the critical roles of Inausley and those essential demons and navigated the complex layers of security UIDs so Linux capabilities, encryption, and finally the constant battle for memory management that orchestrates it all.

And if we connect all that back to the bigger picture, hopefully you now possess a far richer understanding of of the frankly ingenious engineering that's humming away inside the device,

So what does this all mean for you listening right now? Android? Yeah, it's an open source system, But how many people can really sit down and sift through those millions of lines of Java, c C plus plus XML all the rest to figure out how it actually works, let alone connect those intricate details back to their daily experience with their phone.

It's a huge undertaking, it is.

We hope this deep dive has revealed some of that hitting complexity, maybe some surprising facts that make Android so powerful, so adaptable, and also so resilient despite the challenges. The real question is armed with this new found understanding of its depths, what aspect of androids hidden world will you explore next