Introduction: The Criticality of Flashed Partition Verification

Flashing firmware, custom ROMs, or kernels on Android devices is a common practice for enthusiasts seeking enhanced functionality, performance, or privacy. However, the process is not without its pitfalls. A corrupted or improperly flashed partition can lead to a myriad of issues, ranging from boot loops and unexpected crashes to a completely bricked device. Ensuring the integrity of flashed partitions is paramount to a stable and secure Android experience. This expert guide delves into advanced techniques using ADB (Android Debug Bridge) and Fastboot to diagnose and verify your flashed partitions, providing peace of mind and safeguarding your device against potential disasters.

While Fastboot confirms the successful writing of an image to a partition, it doesn’t always guarantee the integrity of the data itself or its compatibility with the rest of the system post-boot. This is where a combination of Fastboot’s diagnostic capabilities and ADB’s post-boot inspection becomes invaluable.

Prerequisites for Advanced Diagnostics

Before embarking on partition verification, ensure you have the following:

• ADB & Fastboot Setup: The latest platform tools installed on your computer and added to your system’s PATH.
• OEM Unlocking: Your device’s bootloader must be unlocked. This is a prerequisite for flashing custom images.
• Device Drivers: Correct USB drivers for your Android device installed on your computer.
• USB Debugging: Enabled in Developer Options on your device for ADB functionality.
• Battery Charge: Ensure your device has at least 50% charge to prevent interruptions.

Understanding Android Partitions: A Quick Overview

Android devices utilize various partitions, each serving a specific purpose. Common partitions you’ll interact with include:

• boot: Contains the kernel and ramdisk. Essential for device startup.
• system: Houses the Android OS framework, libraries, and core applications.
• vendor: Contains hardware-specific binaries and libraries from the device manufacturer.
• dtbo (Device Tree Blob Overlay): For newer devices, providing hardware configuration data.
• recovery: A separate bootable partition for system recovery and updates.
• userdata: Stores user data, app data, and settings.

Understanding these partitions helps in identifying which component might be at fault during troubleshooting.

Phase 1: Verifying the Flashing Process with Fastboot

Fastboot is your primary tool for low-level interaction with your device’s bootloader. It’s crucial for flashing images and initial diagnostics.

Step 1: Confirm Device Recognition

Before any flashing or verification, ensure Fastboot recognizes your device.

fastboot devices

You should see your device’s serial number. If not, check your drivers and USB connection.

Step 2: Observe Flashing Output

When flashing a partition, Fastboot provides critical feedback. Always pay close attention to the console output.

fastboot flash boot boot.imgSending 'boot' (131072 KB)                        OKAY [  3.000s]Writing 'boot'                                     OKAY [  0.800s]Finished. Total time: 3.800s

The `OKAY` messages for `Sending` and `Writing` are strong indicators of a successful transfer and write operation. Any `FAILED` or `ERROR` messages here mean the flash was unsuccessful, and you should not proceed to boot the device without resolving the issue.

Step 3: Querying Partition Information with `getvar`

The `fastboot getvar` command can retrieve various bootloader variables, including partition sizes and device state, which can be useful for pre- and post-flash comparisons.

fastboot getvar all

This command outputs a wealth of information. Look for entries related to partition sizes (e.g., `max-download-size`, `partition-size:boot`). While `getvar` doesn’t read the *content* of a partition, it confirms the bootloader’s understanding of the partition layout and its properties, ensuring that the target partition exists and is recognized.

fastboot getvar partition-size:bootfastboot getvar current-slot # For A/B devices

Compare the reported partition sizes with the size of the image you intended to flash. Significant discrepancies might indicate an issue with the image file itself or the device’s partition table.

Phase 2: Verifying Partition Content Post-Flash with ADB

Once you’ve successfully flashed partitions and booted your device (even if it’s into a custom recovery or the newly flashed OS), ADB becomes your primary tool for deeper inspection and content verification.

Step 1: Confirm ADB Device Recognition

Boot your device into the system or recovery, and ensure ADB can connect.

adb devices

Your device’s serial number should appear, indicating it’s connected and authorized.

Step 2: Inspecting Mounted Partitions

Use `adb shell` to gain a shell prompt on your device and examine how partitions are mounted.

adb shellmount

This command lists all mounted filesystems. Verify that critical partitions like `/system`, `/vendor`, and `/data` are mounted correctly and with the expected filesystem types (e.g., ext4, f2fs).

adb shell df -h

This command provides a human-readable summary of disk space usage. Check that the sizes and free space reported for your partitions are as expected, especially after flashing a new ROM.

Step 3: Examining Partition Block Devices

The actual block devices for partitions are usually found under `/dev/block/by-name`. This directory uses symbolic links to point to the actual block devices, making it easier to identify partitions by their human-readable names.

adb shell ls -l /dev/block/by-name

Verify that all expected partitions (boot, system, vendor, etc.) are present and correctly linked. Missing or incorrect entries here could indicate a corrupted partition table or a failed flash of a critical partition.

Step 4: Verifying System Properties and Build Information

After booting into a newly flashed ROM, you can check system properties to confirm that the correct firmware version and build are running.

adb shell getprop ro.build.fingerprintadb shell getprop ro.build.version.releaseadb shell getprop ro.product.deviceadb shell getprop ro.bootloader

Compare these outputs with the expected values for your flashed ROM. For example, the `ro.build.fingerprint` often contains detailed information about the build, including the ROM name, version, and date. Discrepancies here might mean you’ve booted into an older slot on an A/B device or that the flash was not entirely successful.

Step 5: Kernel Version Check

The kernel is a critical component of the `boot` partition. Verifying its version ensures your `boot.img` was correctly flashed.

adb shell uname -a

The output will show the kernel version, build date, and other system information. Cross-reference this with the kernel version expected by your custom kernel or ROM.

Advanced Diagnostics and Troubleshooting for A/B Devices

Modern Android devices often use A/B (seamless) updates, which means there are two sets of partitions (slot A and slot B) for system-critical components like `boot`, `system`, and `vendor`. This allows for updates without downtime but adds complexity to flashing and verification.

Checking Current Slot

fastboot getvar current-slot

This tells you which slot is currently active. When flashing, you typically flash to the *inactive* slot, then switch to it.

Switching Active Slot

If a flash to one slot fails or results in a bootloop, you can try switching back to a known working slot:

fastboot --set-active=a  # or b

Flashing All Slots (Carefully!)

Some images or tools might flash to both slots simultaneously (e.g., `fastboot flash –slot=all boot boot.img`). Exercise caution, as this can overwrite both slots and potentially leave you with no working bootable system if the image is faulty.

Conclusion: The Value of Diligent Verification

Verifying flashed partitions is not an optional step but a critical component of successful Android firmware management. By diligently using ADB and Fastboot’s diagnostic capabilities, you can ensure the integrity of your flashed images, confirm correct system configuration, and significantly reduce the risk of device instability or bricking. Embracing these advanced verification techniques empowers you to confidently experiment with custom ROMs, kernels, and system upgrades, knowing you have the tools to diagnose and troubleshoot effectively.