| Name | Modified | Size | Downloads / 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 (recommended)
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
/sdcardinternal-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_amatched addbaseline byte-for-byte; restore reproduced the same hash - File flash: root patches (init_boot repatch) and ordinary files
- Terminal, file browser, menus/About, legacy
twrpCLI 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
recoverypartition and re-patchinit_boot(BakaSU) — the payload overwrites them with stock. userdatais 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
recoverypartition 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