DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • Google Cloud Messaging with Android
  • Top 13 Mobile App Development Platforms You Need
  • Difference Between Cross-Browser Testing and Responsive Testing
  • Exploring the Salesforce Mobile SDK Using Android Studio

Trending

  • Unleashing the Power of Microservices With Spring Cloud
  • What Is Good Database Design?
  • Agile Estimation: Techniques and Tips for Success
  • Build a Digital Collectibles Portal Using Flow and Cadence (Part 1)
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Android Internals: The Android OS Bootup Process

Android Internals: The Android OS Bootup Process

Learn more about what happens when you boot up your Android device.

Ayusch Jain user avatar by
Ayusch Jain
·
Jul. 17, 19 · Tutorial
Like (3)
Save
Tweet
Share
13.86K Views

Join the DZone community and get the full member experience.

Join For Free

This post is targeted for software engineers wanting to dive deep into the inner workings of Android's Internals. We'll take a look at what happens when your Android device boots up, but specifically Zygote in Android and what is its role in firing up an application.

We'll see how an activity is fired up in Android using ActivityManager and who's responsible for initializing that Activity Manager, as well as what happens in the init.rc file, which starts various daemons in Android. And more such interesting questions.

Knowledge of Android Internals is necessary if you want to build a career as an Android Engineer. Internals will make you aware of all the optimizations that can be used in your regular development tasks. You'll be more cautious while allocating objects and creating new activities. Apart from that, it'll also help you in interviews!

Let's get started.

Prerequisites

There are some prerequisites for this article. You must be familiar with concepts such as:

  • Processes in Linux
  • What is a Virtual Machine?

Extras:

  • What are daemons in Linux?
  • Process vs Thread

How Does Android Boot Up?

Here's the cycle of the bootup process in Android:

android internals

This is how it goes: Boot ROM -> Bootloader -> Kernel -> Init -> Dalvik VM -> Zygote -> System Server -> Managers.

Boot ROM

Boot ROM contains the initial code that's run as soon as the device wakes up. It is a mask ROM or write-protected flash drive. Embedded in the CPU chip, Boot ROM loads the Bootloader into RAM for execution.

Here are some examples of Bootrom that I found on StackOverflow:

  • iPhone boot ROM. Embedded in the mask ROM and can't be modified. Loads the next stage boot loader from flash or USB (in DFU mode) and verifies its signature using built-in RSA implementation. It would also provide accelerated decryption functions for the next stage bootloader.
  • TI's OMAP4 boot ROM. Can load user code from flash (NOR, NAND, OneNAND), external memory, SD/MMC, USB or UART. Boot order and options are set by strap (SYSBOOT) pins. Provides some functionality for later stages (cache/TLB management etc.)
  • NXP's LPCxxxx series Boot ROM. Placed in a hidden portion of the internal flash which is mapped at 0 on power-on. Implements CRP (code read protection), ISP (In-System Programming) which allows to upload and flash new code over UART. If a valid user code is in flash (needs to have proper checksum), maps it to 0 and jumps to it. A part of bootrom remains mapped to provide IAP (In-Application Programming) and some other services.

Bootloader

Bootloader is a piece of code that runs before any operating system. It is responsible for loading an operating system from the device, setting up a minimal environment in which OS can run, and beginning the startup process. Hence, the bootloader is not specific to Android.

In the context of Android (pun intended!), you might've heard of OEM manufacturers placing certain limitations on the operating system (e.g. limited background processes). This is where those rules are stored.

One of the major tasks of bootloader involves setting up memory management, security options. This is essential for the Kernel. Bootloader contains two important files: init.s and main.c

Init.s is responsible for initializing stacks and BSS segments. It eventually calls main.c, which is responsible for initializing hardware such as a keyboard, system clock, console, etc.

Most importantly, the bootloader verifies the integrity of the boot and recovery partitions before moving execution to the Kernel and displays the warnings specified in the section Boot state.

Kernel

Once Kernel boots up, it starts to set up the cache, load drivers, mount the file system, start Kernel daemons, etc. Once it finishes the system setup, it looks for the init process in the system files and launches the root/first process.

Without Kernel, your software won't have a chance to communicate with the hardware.

Init

This is a very crucial process. It is where the directories such as /dev, /sys, /proc are mounted. This is also the place where init.rc script is executed.

Init process also starts the daemons, such as bluetooth daemon, adb daemon, etc. These handle low-level hardware interfaces including radio interface.

If you take a look at init.rc script, you'll find that it includes commands such as "start vold" for the file system and "trigger zygote" for starting the Zygote process in Android.

One of the most important things that happens during this init process is a call to start the Zygote. The  app_process command starts the ART or Dalvik VM and also gives a call to Zygote's  main() method.

Zygote and VM

When the command  app_process launches the Zygote, first, a VM instance is created, and then, a call to Zygote's  main() function happens.

According to the dictionary definition: Zygote is the first cell that's formed during fertilization. Similarly, Zygote is the first Android-specific process when Android OS boots up!

Zygote preloads all the system resources and classes used by the Android framework, thus achieving fast app launches.

The Zygote forks itself to start a "system-server." The system-server starts services such as ActivityManagerService, hardware services, etc.

It starts listening on a socket interface for future requests to spawn off new virtual machines (VM) for managing new application processes. On receiving a new request, it forks itself to create a new process that gets a pre-initialized VM instance.

This forking is available due to the copy-on-write resource management technique. It doesn't copy anything actually, just points to the pages of the parent process. The actual copying happens when there is a new write to the process' pages.

Forking happens very efficiently. A new Dalvik VM is created, and then, the process gets its own thread and resources to work with. This enables code sharing among VMs, resulting in minimal startup time.

System Server

System Server is the first service started by the Zygote. The first thing that the system server does is start the native library called android_servers that provides interfaces to native functionalities.

It starts initializing each system service and registering them with the previously started Service Manager. Each service runs in a separate Dalvik thread in system server.

ActivityManager is responsible for starting the Launcher App and registering click listeners to it. It also manages the activity lifecycle, maintains activity stack, etc.

System Server also starts other services beginning with com.android, such as com.android.phone and com.android.email. It also starts other managers such as Location Manager, Bluetooth Manager, etc.

Activity Manager

It is responsible for activity thread process creation, activity stack management, and activity lifecycle management. In the end, it launches an intent to start Home Launcher and registers on click listeners to it. Whenever a click is detected, it launches new apps from icons on the home screen.

The click events are transferred to AcitivityManagerService via Binder IPC. AMS performs multiple steps:

  • Collects info about the target intent of the intent object. It does so using resolveIntent() method.
  • Information about the target is saved back into the intent object.
  • Now, it's checked if the user can actually access the target using  grantUriPermissionLocked() method.
  • Then, AMS checks if the intent needs to be opened as a new task. It checks for flags such as FLAG_ACTIVITY_NEW_TASK, etc.
  • If the process doesn't already exist for the target, the AMS has to create a new process for this.

Conclusion

This article will help you host CloudAnchors using Google Cloud Anchors API. Let me know if you'll face any problems and I'll be happy to help :)

*Important*: Join the AndroidVilleSLACK workspace for mobile developers where people share their learnings about everything latest in Tech, especially in Android Development, RxJava, Kotlin, Flutter, and mobile development in general.

Click on this link to join the workspace. It’s absolutely free!

You can follow me on LinkedIn, Quora, Twitter, and Instagram where I answer questions related to mobile development, particularly Android and Flutter.

Android (robot) operating system Android OS mobile app

Published at DZone with permission of Ayusch Jain. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Google Cloud Messaging with Android
  • Top 13 Mobile App Development Platforms You Need
  • Difference Between Cross-Browser Testing and Responsive Testing
  • Exploring the Salesforce Mobile SDK Using Android Studio

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: