Introduction: Beyond the Standard ADB Sideload

Android factory images are the official rescue packages provided by device manufacturers and Google. They contain all the necessary components to restore a device to its pristine, out-of-the-box state. While most users interact with these images through simple `flash-all` scripts or `adb sideload` commands, a deeper understanding of their internal structure is invaluable for advanced customization, debugging, and developing custom ROMs. This guide will walk you through the process of deconstructing a factory image, revealing its constituent parts, and empowering you to devise custom sideloading strategies.

What is a Factory Image?

A factory image typically comprises a collection of partition images (e.g., system, boot, vendor), bootloaders, radio firmware, and scripts to automate the flashing process. It’s designed to be a complete overwrite, ensuring device integrity. However, its monolithic nature often obscures the individual components that power your Android device.

Why Deconstruct?

Deconstructing a factory image allows:

• Targeted Flashing: Flash specific partitions without reinstalling everything.
• Modification & Customization: Inspect or modify individual images before flashing (e.g., custom kernels, modified `build.prop`).
• Troubleshooting: Identify issues by comparing partition contents across different builds.
• Recovery Development: Understand how partitions are structured for building custom recoveries (like TWRP).
• Security Research: Analyze firmware components for vulnerabilities.

Prerequisites and Tools

Before we begin, ensure you have the following tools installed and configured:

• Android SDK Platform Tools: Includes `adb` and `fastboot`.
• Python 3: Required for the `payload_dumper.py` script.
• Basic Linux Utilities: `unzip`, `dd`, `mount` (or equivalent on macOS/Windows Subsystem for Linux).
• `payload_dumper.py` script: Downloadable from various Android modding repositories (e.g., GitHub). This tool extracts contents from `payload.bin`.
• `simg2img` utility: Converts Android sparse images to raw images. Often part of Android `mksparse` tools or available separately.

Acquiring and Initial Inspection of the Factory Image

Downloading the Factory Image

Obtain the factory image specific to your device model and desired Android version. For Google Pixel devices, these are readily available on the official Google Developers website. Always download images from trusted sources.

Unzipping the Primary Archive

Once downloaded, the factory image will typically be a `.zip` archive. Unzip it to a working directory:

unzip walleye-factory-a3c31405.zip -d factory_image_extract

Inside, you’ll find several files and often another nested `.zip` archive.

Deep Dive: Understanding the Contents

The Flash-All Script and Key Binaries

The top-level directory usually contains `flash-all.sh` (for Linux/macOS) or `flash-all.bat` (for Windows). These scripts automate the flashing process. Examining them provides insights into the order and method of flashing:

#!/bin/bashfastboot flash bootloader bootloader-walleye-mw-5.22.imgfastboot reboot-bootloaderfastboot flash radio radio-walleye-mw-3.23.imgfastboot reboot-bootloaderfastboot update image-walleye-a3c31405.zip

This script reveals that the bootloader and radio firmware are flashed first, followed by a reboot, and then the main system image archive (`image-walleye-a3c31405.zip`) is applied.

The Crucial `image-*-factory-.zip` Archive

This nested `.zip` file contains the core operating system and user data partitions. Unzip this archive:

unzip image-walleye-a3c31405.zip -d core_image_extract

You’ll typically find files like:

• `android-info.txt`: Contains device identifiers and version information.
• `boot.img`: The kernel and ramdisk.
• `dtbo.img`: Device Tree Blob Overlay, used by newer Android versions.
• `product.img`, `system.img`, `vendor.img`: These are the core Android partitions.
• `recovery.img`: The recovery environment.
• `super.img` (on newer devices with Dynamic Partitions): A super partition containing multiple logical partitions.

Handling `payload.bin` on Newer Devices

For devices employing A/B updates and Project Treble’s dynamic partitions (Android 10+), individual partition images might not be directly present. Instead, you’ll find a `payload.bin` file. This file is essentially an OTA (Over-The-Air) update package containing compressed and delta-encoded partition images. To extract them, you’ll use the `payload_dumper.py` script:

python3 payload_dumper.py payload.bin

This script will extract all the individual `.img` files from `payload.bin`, such as `system.img`, `vendor.img`, `product.img`, `system_ext.img`, `boot.img`, etc., into a new directory.

Extracting and Analyzing Partition Images

Sparse Images (`.img`) vs. Raw Images (`.img`)

Many of the extracted `.img` files (e.g., `system.img`, `vendor.img`) are