Download Latest Version AERA-R1.0_1-Stable-Official-iceland.zip (74.7 MB)
Home / AERA
Name Modified Size InfoDownloads / Week
Parent folder
README.md 2026-11-07 5.2 kB
AERA-R1.0_1-Stable-Official-iceland.img 2026-11-07 104.9 MB
AERA-R1.0_1-Stable-Official-iceland.zip 2026-11-07 74.7 MB
Totals: 3 Items   179.5 MB 0

AERA Recovery for OnePlus Pad 4 (OPD2514 / iceland)

Version: AERA R1.0_1 — Stable / Official Maintainer: peeler Base: upstream AERA Recovery R1.0 (Android 16 branch) Device: OnePlus Pad 4, model OPD2514 (OP657AL1, prj 25978, ROW), codename iceland, platform SM8850 / kernel family canne

Device-specific AERA build for the bootloader-unlocked OnePlus Pad 4. Tested on ColorOS 17 (OPD2514_17.0.0.101(EX01)) upgraded from OOS16 (OPD2514_16.0.10.501(EX01)).

Files

File Purpose
AERA-R1.0_1-Stable-Official-iceland.img Recovery image (100 MiB). Flash directly with fastboot
AERA-R1.0_1-Stable-Official-iceland.zip Recovery-installer zip (signed). Flash from an existing custom recovery; also usable for fastboot update-style workflows where supported
README.md this file

SHA256

01b43494bbf67c4b0a5615efd4defd62be58960b3f6f85a1f7b08f724c8c751a  AERA-R1.0_1-Stable-Official-iceland.img
f89295cefab8abfd8b754d3d4f42fdb114b272cd7dce112bd24ab351f2e349f0  AERA-R1.0_1-Stable-Official-iceland.zip

Installation

Prerequisite: unlocked bootloader. All flashing/writing is at your own risk — this is a daily-use device, keep stock images as backups.

fastboot flash recovery_a AERA-R1.0_1-Stable-Official-iceland.img
fastboot flash recovery_b AERA-R1.0_1-Stable-Official-iceland.img

This device uses Virtual A/B and keeps a recovery partition per slot (recovery_a, recovery_b). Flash the image to both slots so the recovery survives OTA slot switches. Then fastboot reboot recovery (or boot into recovery from Android) to start AERA.

recovery-installer zip

From a working custom recovery, flash the zip as a normal package; it installs the bundled recovery.img to the recovery partition of the relevant slot via the included installer (aera-installer + update-binary, signed with test-keys SignApk).

Verified on this device

  • Display: correct orientation/rotation (TW_ROTATION 270), aspect-correct scaled UI on the 3392x2400 panel, responsive touch (no transition lag)
  • GPU/EGL acceleration via KGSL (~115 fps UI rendering)
  • FBE decryption and /sdcard internal-storage access
  • Wi-Fi: driver/firmware load, supplicant, connect, network access, plugin store reachable
  • Root Manager providers including BakaSU (selection UI verified)
  • Backup/restore: GUI backup of the active recovery_a matched a dd baseline byte-for-byte; restore reproduced the same hash
  • File flash: root patches (init_boot repatch) and ordinary files
  • Terminal, file browser, menus/About, legacy twrp CLI behaviour

OTA package flashing (device-specific design)

This device's super is only ~14.6 GB and uses Virtual A/B with overlapping extents — two full systems cannot coexist, and the stock updater's snapshot merge hangs at first boot on this unit. AERA therefore implements an automatic materialization path:

  • The update_engine still uses the snapshot path to allocate target extents (required because they overlap the source layout)
  • Payload data is then written directly to the base extents through dm-linear devices instead of COW snapshot devices
  • On completion the snapshot state is cancelled — no merge is scheduled, the new slot boots immediately as a plain system

Verified end-to-end on this device: sideloading the COS17 full OTA zip to the inactive slot produced a booting COS17 system with no merge and no hang.

OTA limitations and cautions

  • Full-image payloads only. Materialization does not support true delta payloads containing SOURCE_* operations (no source images are read back). This device's OTA zips are full-image payloads and work.
  • The old slot does not survive — by this device's VAB design the target extents physically overlap the source layout, so the source slot's super content is consumed during the write. This is inherent to the hardware layout, not a bug. The inactive slot can be rebuilt later by another OTA.
  • After a successful OTA install: re-flash AERA to the new slot's recovery partition and re-patch init_boot (BakaSU) — the payload overwrites them with stock.
  • userdata is shared and untouched by the OTA path.

Known device-specific constraints

  • UI logical canvas is fixed at 1440 px design width; on the 3392x2400 panel everything renders at a uniform ~1.67x scale (aspect-correct).
  • The recovery partition is per-slot; OTA replaces the target slot's recovery with stock, so AERA must be re-flashed after each OTA.
  • Stock OTA/merge behaviour of this unit is broken by design; use AERA for OS updates.

Warnings

  • Flashing, rebooting, slot switching, and partition writes are entirely the user's responsibility. Keep backups (AERA backup works).
  • Do not flash images built for other models/codenames.
  • Do not install delta/incremental OTA zips — see the limitation above.

Credits

  • AERA Recovery upstream (base R1.0)
  • OrangeFox device tree (bring-up basis)
  • Device bring-up, VAB materialization, fixes: peeler
Source: README.md, updated 2026-11-07