How to Vendor Partition (VAB) Files Impact Custom ROM Installs

Modern Android phones split their software into several partitions, and the vendor partition is the one most custom ROM users never think about — until something breaks. The vendor image holds the maker-specific drivers and hardware code: the camera sensors, the modem, the fingerprint reader, the audio chip, the display calibration. A custom ROM replaces the system partition but usually keeps the vendor files from stock firmware, and that split explains why a ROM can boot perfectly and still fail at calls, photos, or unlocking the phone.

I learned this the hard way on a phone that ran a fresh LineageOS build beautifully for a day, then lost mobile data every time I left Wi-Fi. The ROM was fine. The vendor build on the phone was two releases behind the one the developers tested with, and the modem driver was calling an interface that had changed. One vendor update later, the data came back. That is the story of this article: the vendor layer decides whether a custom install works in daily use, not just whether it boots.

This guide explains what lives in the vendor image, what Virtual A/B changes about the partition layout, and how the wrong vendor package produces the exact symptoms users blame on the ROM — failed installs, dead fingerprint readers, silent calls, and fast battery drain. Read it before your next flash, and you will spend far less time guessing afterward.

What the vendor partition holds and why custom firmware needs it

The vendor image is the bridge between Android and the physical phone. The system talks to hardware through a layer called the hardware abstraction layer, and the code behind that layer lives in the vendor code. Camera drivers, sensor drivers, audio libraries, modem configuration, display calibration data, and the code that talks to the fingerprint sensor all sit there. Without them, Android has no way to reach the parts that make a phone a phone.

ROM developers build the system to use the vendor layer from stock firmware. That design saves an enormous amount of work — nobody wants to rewrite a camera driver for every phone — and it keeps hardware support stable across builds. It also means the ROM depends on a vendor release it was tested with. A newer or older vendor build may change an interface the ROM expects, and that change breaks a feature without any error on screen.

Drivers, modem code and calibration data in one place

Think of the vendor image as three groups of files. The first group is drivers: the code that drives the camera sensors, the gyroscope, the proximity sensor, the audio chip and the display panel. The second group is modem and radio code: the baseband configuration, carrier band tables, and the tuning for your region. The third group is calibration data: the numbers that make your exact panel, your exact camera module and your exact fingerprint sensor behave correctly. Swap in a vendor package from another model and the calibration numbers stop matching the hardware, even if the drivers load.

Why a ROM can boot yet fail at calls or the camera

Booting needs only a small part of the vendor layer: the display, the storage driver, and the basics. Calls, camera, fingerprint and VoLTE need the rest of it, and they need the right release of it. That is why a mismatch is a quiet failure. The phone looks fine on the home screen, then the fingerprint reader fails, or mobile data drops, or the camera opens to a black screen. Users blame the ROM when the vendor package is the real cause, and matching the vendor package to the ROM build prevents most of these surprises.

Virtual A/B (VAB) explained: slots, snapshots and the vendor image

Virtual A/B is the update system that replaced classic A/B slots on many newer phones. Classic A/B kept two full copies of the system — slot A and slot B — so an update could write to the idle slot and the phone could fall back if the update failed. That design worked, but it doubled the space the system needed. Virtual A/B keeps the same safety idea with far less space: it uses snapshot-based updates and compressed partitions, so the update writes to a snapshot of the running system instead of a whole second copy.

For a custom ROM user, this layout matters because the vendor layer is part of that snapshot layout. On a VAB phone, the maker files live inside a super partition alongside the system image, and the update process treats them as one unit. You cannot always update the vendor package on its own the way you could on an older phone with a separate vendor partition, and a ROM installer that expects a standalone vendor image may behave differently on a VAB device.

How snapshot-based updates changed flashing

On older phones, flashing was simple: write the system image to one partition, write the vendor code to another, reboot. On a snapshot-layout phone, the super partition holds several logical partitions at once, and the installer must resize and rewrite them as a group. That is why guides for this layout insist on a specific recovery version and a specific install order — the recovery has to understand the snapshot layout, or the flash writes to the wrong place and the phone refuses to start.

VAB files in guides: vendor and bootloader packages by another name

In many device guides, “VAB files” means the vendor and bootloader related packages bundled for a device: the vendor code, the modem firmware, and sometimes the bootloader update that goes with them. The exact contents vary by maker and by model. Some packages update the modem and the bootloader together. Others update only vendor libraries for sensors and audio. Read the package notes for your model before flashing anything, and never assume a package for one model fits another, even a close one.

What a vendor-and-bootloader package usually contains for one model

A typical bundle names its parts: a vendor partition image with the hardware drivers, a modem firmware image with the radio code, and a bootloader image when the guide pairs them. Some makers add a separate firmware package for the Bluetooth and Wi-Fi chips. The guide for your codename lists the parts and the order, and the order matters — a package that updates the bootloader and the modem together must run in the sequence the guide states, or the phone can end up unable to reach recovery at all.

How vendor packages reach the phone during a flash

There are two common routes, and mixing them is a classic mistake. Some guides flash vendor code with fastboot commands from a computer, one image at a time. Others flash them as a ZIP in recovery, alongside the ROM. Some ROM installers include a vendor check that warns you before flashing when the vendor release does not match the build. Follow the method in your device guide, and do not mix methods from different guides for the same phone.

1. Download the vendor package that matches your codename, your region, and the ROM build you plan to install. Check the file size against the guide, and verify the checksum when one is given.
2. Place the vendor files in the same folder as your ROM and recovery files, and label the folder with the version and the date. A labelled folder is the difference between a five-minute flash and an hour of guessing which file is which.
3. Flash the vendor files in the order the guide states. Order matters when a package updates the bootloader and the modem together — a wrong order can leave the phone unable to boot to recovery.
4. Flash the ROM after the vendor package, unless the guide says the opposite. Most guides put vendor first, then the ROM, then any add-ons.
5. Reboot and test the hardware features before you restore your apps: a call, mobile data, the camera, the fingerprint reader, and audio. Test now, while a rollback is still easy.

Fastboot commands versus recovery ZIPs

Fastboot gives you control over each image: fastboot flash vendor vendor.img writes the vendor partition image, fastboot flash modem modem.img writes the modem, and fastboot reboot bootloader returns to the bootloader between steps. Recovery ZIPs are simpler — one flash, one reboot — but they hide the steps, so a failure tells you less about which part went wrong. Use the route your device guide names, and keep the fastboot route in mind as a fallback when a ZIP flash fails.

Why flashing order matters for bootloader and modem updates

A bootloader update can change how the phone reads the partitions that follow it, and a modem update can change the radio behaviour the system expects. Flash the modem before the bootloader on a guide that says so, and the bootloader may refuse the modem image. Flash them in the guide order, and each step lands on a layout the next step understands. That is the whole reason the order is written down — it is not a suggestion.

Status 7 errors and verification failures when the vendor set does not match

Nothing stops a flash faster than a Status 7 error. The installer checks the device, the vendor release, or the file signature, finds a mismatch, and aborts with a short error and a dead install. The message looks cryptic, but the meaning is simple: something the installer expected does not match something on the phone, and the installer refused to continue rather than risk a bad flash.

Vendor mismatches are one of the most common triggers. Many ROM installers assert a minimum vendor release in the updater script, and when the phone runs an older vendor set, the assert fails and the install stops. The fix is usually a vendor update, not a different ROM, and the guide for fixing Status 7 errors during ZIP installation walks through the same checks in detail — read the assert lines, match the vendor set, and verify the file before you flash again.

Read the assert lines in the error before you retry

The error text names the failed check. An assert on the device codename means you flashed a package for the wrong model. An assert on the vendor release means the vendor build is too old or too new for the build. An assert on the file signature means the ZIP is corrupt or was signed for a different release. Write down the exact line before you retry, because the line tells you which of the three problems you have, and each one has a different fix.

What an updater-script assert actually checks

An assert is a condition the installer tests before writing anything: the codename must match, the vendor release must fall inside the range the build was tested with, and the package must pass its signature check. If any assert fails, the installer aborts before it writes a single file, which is why a Status 7 error is annoying but safe — the phone is unchanged, and you can fix the mismatch and try again.

Verification failures and corrupt packages

A verification failure is a different fault from a Status 7 assert, though the two often appear together. Verification checks the file itself: a bad download, a truncated ZIP, or a package from an unofficial mirror without a checksum. Re-download the file from the source your device guide names, check the size, and verify the checksum when one is given. A corrupt vendor file can damage the modem partition, so care at this step protects the most delicate parts of your phone.

VoLTE, fingerprint and camera: the hardware features that break first

When the vendor set does not match, the failures follow a pattern, and learning the pattern saves hours. Mobile data loss after a flash often points to a modem mismatch. Camera failure points to a sensor driver mismatch. Fingerprint failure points to a biometric driver mismatch. Audio distortion points to an audio library mismatch. Each symptom narrows the suspect area, so note the exact failing feature before you search for a fix.

VoLTE is the most fragile of the group. Voice over LTE needs the modem, the carrier configuration, and the system telephony stack to agree, and the carrier configuration lives in the vendor files. A vendor package from the wrong region can break VoLTE while leaving ordinary data working, which is why a phone can browse the web fine and still fail at calls. The guide on how custom ROMs handle VoLTE and fingerprint hardware explains the same split in depth — the ROM provides the calling app, but the vendor layer provides the radio behaviour underneath it.

Why the fingerprint reader is so sensitive to vendor versions

Fingerprint hardware is calibrated per sensor and per model, and the fingerprint calibration data lives in the vendor partition. An optical sensor needs the display calibration to light the right pixels; an ultrasonic sensor needs timing data that differs between panel revisions. A vendor package built for a different panel revision can leave the reader slow, inaccurate, or dead, with no error message at all — the sensor simply never reports a match.

Camera and audio failures after a vendor change

The camera is the second most sensitive feature. A sensor driver mismatch can leave the camera app opening to a black screen, or recording video with no sound, or crashing when you switch to the front camera. Audio has the same shape: a wrong audio library can produce distortion, silence on calls, or a speaker that works for media but not for the earpiece. In both cases the fix is the same — match the vendor release to the build — and in both cases changing the ROM at the same time hides which change fixed the problem.

Battery drain after a vendor mismatch and how governor tweaks help

Battery drain is the symptom most users misread, because it feels like a ROM problem. A sensor driver that polls too often keeps the phone awake. A modem that hunts for signal drains power fast. A camera driver that never sleeps holds a wakelock all night. Check the battery stats for a hardware service that uses unusual power — that clue often leads back to the vendor package, not the ROM.

Once the vendor package matches, tuning can still help. The guide to tuning battery life on a custom ROM covers governor settings and system optimisations that cut idle drain on a correctly matched install — a calmer CPU governor, fewer background wakeups, and a modem that is not hunting for a signal it cannot hold. Tuning cannot fix a mismatch, though. A governor tweak on top of a broken modem driver only hides the drain for a day, and the real fix is still the vendor update.

How to tell vendor drain from ordinary ROM drain

Open Settings, then Battery, and look at which service uses the power. Vendor drain shows up as a hardware service — the modem, a sensor, or the camera — using a large share while the screen is off. Ordinary drain shows up as an app. If a hardware service tops the list after a fresh flash, suspect the vendor package first, and check the battery again after the vendor update before you touch any tuning setting.

How to match the vendor version to your ROM build before flashing

Matching is a habit, not a talent. Every ROM build is tested against a vendor release or a range, and the build notes name that release. The whole job is reading the notes, checking the phone, and flashing the matching package before the ROM — and keeping a record so you can repeat the combination later.

1. Read the build notes for the ROM you plan to install, and write down the required vendor release or firmware version it names.
2. Check the vendor release on the phone. In fastboot, run fastboot getvar vendor-version where the bootloader supports it; on other phones, check the baseband version in Settings, then About phone, which usually tracks the modem and vendor package together.
3. Download the matching vendor package for your codename and your region from the source the device guide names. Never flash maker files from another model, even a close one — a wrong vendor package can break the radio calibration for your region.
4. Flash the vendor package with the guide method, reboot, and test the hardware features before you flash the ROM. A vendor flash that breaks something is far easier to roll back before the ROM is on top of it.
5. Keep the stock firmware for your model on your computer. That file contains a known good vendor set, labelled with model and version. Do not delete it after a successful install — you may need it months later for a rollback or a warranty repair.

Find the required vendor version in the build notes

Build notes usually name the vendor release in one line: “requires firmware 14.0.5” or “vendor from stock build V14.0.5.0”. That line is the most important sentence in the whole thread, and it is the one most users skip. If the notes name a range, any release inside the range should work; if they name one release, treat it as exact. A security update can also change vendor code, so check the requirement again after any stock update, and keep a note of the vendor release that works with your current ROM.

Where makers publish vendor version numbers

Makers publish vendor releases in their stock firmware release notes, in the fastboot image package name, and in the baseband version shown in Settings. ROM threads usually quote the stock release they were built against. When the two disagree, trust the ROM thread — it names the release the developers actually tested, while the maker page names the latest stock release, which may be newer than the ROM supports.

Vendor updates, OTA packages and major Android version jumps

OTA updates for custom ROMs usually do not update the vendor layer. You must track vendor updates yourself on some devices, checking the device thread when a new stock firmware appears. The thread often states whether the new vendor package is safe, and waiting for confirmation before flashing a fresh stock vendor package is a sound habit — early adopters take the risk, and patient users benefit from their reports.

Major Android version jumps often need a vendor jump too. Plan both updates together: back up, read the notes for the pair, flash the vendor package first if the guide says so, then flash the ROM, and test hardware features before restoring all your apps. Carrier updates can also change vendor code without a full system update — a carrier pushed modem update may alter radio behaviour overnight, and users blame the ROM for a carrier driven change. Check recent carrier updates when a feature breaks suddenly without a ROM change.

Regional variants and why the region matters as much as the model

The same model can ship with different modem tuning per region, and a vendor package for one region may misbehave in another. Carrier bands and regulatory settings live in vendor code, so a wrong region vendor package can weaken signal and, in rare cases, break emergency call behaviour. Match region as carefully as codename. Regional firmware releases also stagger across months, so one region may receive a vendor update weeks before another — stay within your region unless a guide advises otherwise.

Vendor version tracking for long term users

Track vendor releases in a simple log: the vendor release after each flash, the ROM version paired with it, and which features worked. That log becomes invaluable after a year, when you will have forgotten which combination worked. Check vendor threads when a new stock firmware appears, and wait for two independent confirmations before flashing a new vendor package. Keep vendor packages organised by version in folders, named with version and date, and delete only sets for phones you no longer own.

Frequently asked questions about vendor partitions and VAB files

Do I need to update the vendor files every time I update the ROM?

Not every time. You need a vendor update when the ROM build notes name a newer vendor release than the one on your phone. If the notes name the same release you already run, skip the vendor flash and update the ROM alone. Changing the vendor package without a reason adds risk for no benefit.

Can a wrong vendor package brick my phone?

A wrong vendor package can break the modem, the camera, or the fingerprint reader, and in rare cases it can leave the phone unable to boot to recovery if the bootloader update inside it lands wrong. That is why the guide order matters, and why you should keep stock firmware ready before you experiment. Most bad vendor flashes are recoverable with the stock package in fastboot, which is exactly why that package belongs on your computer before you start.

Why does my phone lose signal after a ROM update if I changed nothing else?

A ROM update can target a newer vendor release than the one on your phone, so the modem driver and the system stop agreeing even though you changed no setting. Check the build notes for the new ROM version, and if they name a newer vendor release, flash that vendor package and test again. Carrier pushed modem updates can cause the same sudden break without any ROM change at all.

Is Virtual A/B the same as classic A/B partitions?

No. Classic A/B keeps two full copies of the system so an update can write to the idle slot. Virtual A/B keeps the same fallback idea with snapshots and compressed partitions, using far less space. On a VAB phone the maker files sit inside the super partition with the system image, which is why guides for this layout insist on a matching recovery and a specific install order.

A safe flashing checklist to use before your next install

Before a vendor change, record which features work: test calls, data, camera and fingerprint use, and write pass or fail for each feature. That baseline lets you judge the change honestly — without one, you may blame a vendor change for a fault that already existed. After the change, repeat the same tests in the same order and compare the results with the baseline. A feature that improved proves the change helped; a feature that regressed proves the change hurt, and you should revert the vendor package rather than stacking a ROM change on top of a vendor regression.

Your next step today is simple: open the build notes for the ROM you run, find the required vendor release, and check it against the release on your phone. If they match, you have ruled out the most common cause of mysterious hardware faults. If they do not, you have found your next flash — and this time, you will know exactly why it matters.