Recovery install queues let you flash several packages in one session. You add packages to a list and recovery installs them in order. Queues save repeated reboots and menu navigation. They also reduce the chance of forgetting a package. Used well, queues turn long installs into smooth routines.
Queue order matters as much as queue contents. A package installed too early can be overwritten by a later package. A package installed too late can miss setup steps. This guide explains a reliable order for common packages. It also explains how to handle queue failures safely.
How Queues Work
Queues process packages sequentially without returning to the menu between installs. Recovery runs each install script in list order. It reports success or failure for each package. A failure may halt the queue depending on settings. Check the log after the queue finishes before rebooting.
Queues do not reboot between packages by default. That behavior matters for packages that expect a fresh system state. Some packages need a reboot before the next package applies cleanly. Those cases suit separate sessions rather than one queue. Know which packages need isolation before queueing them.
- Queues install packages in list order without menu trips
- Failures may halt later packages so check logs carefully
- Some packages need a reboot before the next install
- Order decides which package wins when files overlap
A Reliable Standard Order
Start with the ROM package as the foundation of the queue. The ROM writes the system and sets core configuration. Add GApps immediately after the ROM in the same queue. GApps setup expects a fresh ROM system without a prior boot. Booting between ROM and GApps can break Google services setup.
Add kernel packages after ROM and GApps when a custom kernel is planned. Kernel installers patch the boot image from the fresh ROM. Adding the kernel before the ROM would let the ROM overwrite it. Add small system modules last after core packages settle. Modules often depend on ROM and kernel files already in place.
Vendor or firmware packages follow maker and ROM guidance for placement. Some firmware must install before the ROM itself. Others install safely after the ROM in the queue. ROM threads state firmware order explicitly for affected models. Follow thread order over general rules when they conflict.
Building the Queue Carefully
Stage all packages on readable storage before building the queue. Verify file sizes and names before adding them. A truncated package fails midway and wastes the whole session. Add packages one by one and confirm the displayed order. A quick order review prevents most queue mistakes.
Keep queues short for first time installs of a new ROM. A short queue isolates problems to fewer packages. Long queues on untested combinations hide fault sources. After a combination proves itself, longer queues become safe. Experience with a combination earns queue length.
ROM and GApps order details appear in flashing custom ROM zip files and GApps packages for the core pair. Queue order builds on that foundation with kernels and modules added.
Handling Queue Failures
When a package fails, stop and read its error before continuing. Continuing past a failed core package creates a broken system. Core failures need diagnosis and a corrected package. Optional module failures may allow continuing with caution. Judge continuation by package importance, not by impatience.
Common queue failures include wrong device asserts and corrupt zips. Assert failures mean a package targets another model. Corrupt zips mean a bad download or truncated copy. Storage full errors mean the target partition lacks space. Each failure type has a different fix. Guessing fixes wastes more time than reading errors.
After fixing a failure, rebuild the queue from the failed package onward. Reinstalling earlier successful packages is usually unnecessary. But a failed ROM install may require restarting the whole queue. ROM failure leaves system in an unknown state. Restarting from the ROM restores a clean foundation.
Wipes and Queue Timing
Perform wipes before building the queue, not during it. Wiping between queued packages erases just installed files. That mistake ruins an otherwise correct queue. Complete all wiping as a separate step first. Then build and run the queue on the clean target.
Cache wipes after the queue can help first boot cleanliness. Wipe cache and Dalvik after installs complete and before reboot. That final wipe clears stale optimization data from the install. It does not erase installed packages or user data. Post queue cache wipes are safe and often helpful.
Wipe choices pair with queue planning closely. Review wiping system cache and data partitions correctly before any multi package session. Correct wipe timing protects queue results.
adb reboot recovery
adb push rom.zip /sdcard/queue/
adb push gapps.zip /sdcard/queue/
adb shell ls -l /sdcard/queue/The commands above stage queue packages on phone storage. Recovery queue menus then add them in order. Confirm staged files with a listing before building the queue. Staging checks prevent mid queue missing file errors.
Time Saving Queue Habits
Prepare a standard package folder for each ROM you use regularly. Keep ROM and matching GApps and kernel together in that folder. Update the folder when new versions release. A ready folder turns queue building into quick selection. It also prevents version mismatches across packages.
Document successful queue orders for your common combinations. A short note with package names and order saves future guessing. Share that note with your future self after long gaps between flashes. Memory fades but notes persist. Good notes compound time savings across many sessions.
Automated checks before queue runs also save time. Verify storage space and battery level before starting. A queue that dies from low battery wastes the whole session. Charge above sixty percent for long multi package queues. Preparation time pays for itself in avoided retries.
Queues and Backups Together
Back up before every queue that changes system or data. Queues amplify both success and failure across several packages. A backup before a long queue is therefore more important, not less. Store the backup off the device when possible. A queue failure with a backup is a short restore.
Back up again after a successful complex queue. That post queue backup captures the working combination exactly. Future experiments restore to that combination in one step. The pair of pre and post backups brackets every queue session safely. That bracketing habit defines careful flashers.
Mount problems can block queue staging from external drives. The mount repair path in fixing mount errors and file system corruption in recovery shell helps when storage refuses to cooperate. Healthy mounts keep queues moving.
Queue Templates for Common Jobs
A clean ROM install template covers the core packages in order. ROM comes first as the system foundation. GApps follows immediately for Google services setup. Kernel follows when a custom kernel is desired. Small modules close the queue after core packages settle.
An update template differs from a clean install template. The update ROM comes first without a data wipe. Matching GApps follows when the update guide requires it. Kernel reflash follows if the ROM overwrote the boot image. Modules usually survive updates but verify each one after boot.
A repair template prioritizes the broken component only. A boot image or patch zip may be the sole queue entry. Short repair queues reduce variables during diagnosis. Resist adding unrelated packages to a repair queue. Focused repair queues produce clear results.
Logging Queues for Later Review
Recovery logs record each queued package result in order. Review the log before rebooting after every queue run. A package that reports failure needs attention before boot. Booting past a failed core package creates confusing symptoms. Log review takes a minute and prevents hours of diagnosis.
Save logs for complex queues to a computer when possible. ADB pull can retrieve recovery logs after a session. Saved logs help forum helpers when problems appear later. They also document successful combinations for future reuse. A log archive is a practical knowledge base.
Note queue outcomes alongside ROM version records. A successful queue order for one version may change next version. Version specific notes prevent applying stale orders blindly. Update notes whenever a queue order changes. Living documentation beats memory for flashing work.
- Clean installs order ROM then GApps then kernel then modules
- Updates reflash kernel when ROM overwrites boot
- Repair queues stay short and focused on the fault
- Review logs before rebooting after every queue
Queue Failures and Partial Installs
Partial installs leave systems in mixed states that confuse diagnosis. Some packages installed while later packages failed. The system may boot with missing features or crashes. Identifying installed versus failed packages guides repair. Recovery logs list each package result in order.
Rebuilding a partial install usually means restarting the queue cleanly. Wipe system again before restarting when the ROM failed. Reinstall core packages in correct order from the start. Patching a partial install package by package often wastes time. Clean restarts produce predictable systems faster.
Data may survive partial installs when data wipes did not run. Preserve that data with a backup before restarting. A backup before queue restart protects against further failure. Restarting without backup risks compounding the original failure. Backup discipline applies to retries fully.
Queue Testing With Small Packages
Testing queue behavior with small packages builds confidence safely. Queue two tiny trusted packages and run them together first. Observe log output and reboot behavior after the test. A successful small queue proves ordering and storage work. Larger queues then proceed with proven mechanics. Small tests reveal storage or permission problems cheaply. They cost minutes and prevent failures in long sessions. Practice queues before production queues every time.
The steps above follow the approach described in the official developer documentation for this platform. That documentation explains package installation and system update concepts in general terms. It also covers ordering constraints that affect multi package installs. Combine it with ROM notes for your exact device build.
