Activació del suport de recuperació UBports

Històricament des de l’inici dels ports basats en GSI cada port va copiar el disc RAM de recuperació en els seus repositoris específics del dispositiu, normalment des de dispositius ja portats que amb prou feines són ideals. Afortunadament ara, amb la recuperació unificada d’UBports només hi ha una versió construïda a UBports CI que es pot utilitzar a tot arreu :)

Migració a una base de recuperació unificada

Idealment el canvi pot ser tan simple com:

deviceinfo_use_unified_recovery="true"
deviceinfo_unified_recovery_ui_density="xxhdpi"

i si cal, reubiqueu el vostre fstab a ramdisk-recovery-overlay/system/etc/recovery.fstab. La majoria dels altres fitxers anteriors que no són del ramdisk-recovery-overlay/ es poden/haurien d’eliminar tret que es verifiqui/conegui la seva finalitat requerida (compareu els fitxers no específics del dispositiu a les versions de la branca de recuperació unificada del Halium 14). Per exemple, el muntatge fals /cache i la configuració USB ConfigFS ja s’han de tenir en compte, cosa que també permet minimitzar el contingut de ramdisk-recovery-overlay/init.recovery.*.rc, etc.

Nota

Els dispositius GKI v5.4/5.10 haurien de desactivar CONFIG_USB_DUMMY_HCD en els seus nuclis (com ja s’ha fet per a les branques genèriques del nucli-android-common) per evitar la necessitat de configurar sys.usb.controller prop a /init.recovery.*.rc per a treballar en USB, en un altre lloc això hauria de funcionar automàticament quan arrenqui la recuperació.

Finalment, és possible que vulgueu verificar ja la informació de les subseccions següents al vostre port. Les actualitzacions del disc RAM de recuperació ara seran automàtiques amb noves publicacions o canonades CI que s’executin en el repositori específic del dispositiu similar a les reconstruccions del nucli.

S’està portant la implementació des de zero

Tot des de dalt encara s’aplica; la base ramdisk-recovery-overlay/system/etc/recovery.fstab s’ha de crear a partir del ramdisk d’estoc desempaquetat (vendor/recovery). El fitxer ha d’existir amb una entrada /data ja que en cas contrari la recuperació no arrencarà en absolut. S’hauria d’adaptar més, per exemple, d’userdata f2fs a ext4, de manera que funcioni adb shell mount /data) (Q25 userdata example).

A més, assegura que les particions (fins i tot amb el tipus emmc) que rebran imatges noves durant les actualitzacions de les OTA, com ara les de workdir/tmp/partitions/*.img tenen /mountpoints vàlids que coincideixin amb les seves particions /dev/block/by-name/ (FP4 recovery example). Els A/B ranurats haurien d’excloure, per exemple, el sufix _a/ b_ i deixar que l’opció slotselect fsmgr triï la de la ranura actual automàticament en arrencar (Q25 vendorboot/dtbo exemple). Al final, verifiqueu les entrades /etc/fstab generades apuntant a dispositius de bloc vàlids.

Els dispositius Qualcomm SoC normalment també volen que almenys els bits d’enllaços d’arrencada del disc RAM original a ramdisk-recovery-overlay/init.recovery.${ro.hardware}.rc perquè les entrades fstab siguin correctes sense més canvis.

Funcions de treball esperades

  1. Sortida de la pantalla

  2. Accés USB via ADB per exemple, l’instal·lador d’UBports

  3. Ubuntu Touch OTAs, vegeu testing local OTA

  4. Restabliment de fàbrica

  5. S’està reiniciant a modes específics (p. ex. adb reboot bootloader)

  6. FastbootD en dispositius amb partició super

  7. Pantalla tàctil (opcional)

  8. Informe del percentatge de bateria (opcional)

  9. Atenuació/enfosquiment automàtic de la brillantor de la pantalla després del temps d’espera (opcional)

Alguns exemples a través dels ports

Tal com es necessita contacteu la comunitat per rebre ajuda.

Configuració addicional

S’han d’afegir més valors propis personalitzats a ramdisk-recovery-overlay/prop.halium, p. ex. per a les tauletes, una interfície d’usuari de paisatge pot ser interessant:

ro.minui.default_rotation=ROTATION_RIGHT
ro.minui.default_touch_rotation=ROTATION_RIGHT

Altres opcions diverses d’interès poden ser:

  • ro.fastbootd.available=true per utilitzar-lo en dispositius encara més antics amb opcions d’instal·lació menys convenients

  • e.g. ro.recovery.ui.margin_height=24 added margin for top logo on notched devices

  • ro.recovery.batteryless=true per ocultar el percentatge d’informació de la bateria en cas que estigui trencat

  • ro.minui.use_qtidrm=true per utilitzar el dorsal DRM modificat per a QTI (Qualcomm) fins i tot sense ro.hardware,qcom, o desactiveu-lo en cas de problema

  • o fins i tot ro.boot.quiescent=true per desactivar la renderització de la interfície d’usuari de recuperació durant la presentació primerenca

Els ajustos condicionals o d’altra manera més avançats pertanyen a la ramdisk-recovery-overlay/init.recovery.${ro.hardware}.rc.

Expansió del sistema de fitxers arrel

Per a dispositius amb una partició super però originalment amb una configuració lògica system_a massa petita quan arrenqueu amb l’instal·lador d’UBports, és possible canviar la mida per a requeriments més grans (p. ex. 24.04-2.x ara s’envia material de les Qt6 al costat de les Qt5 també), sempre que encara hi hagi prou espai disponible al contenidor mateix:

ro.systemimage.system_partition_size=4500

S’està provant l’OTA local

Una vegada que s’inicia la recuperació d’UBports i s’obté la connexió USB (ADB) funcionant, podeu provar el següent en el vostre port del nucli independent directori de nivell superior:

mkdir -p ramdisk-recovery-overlay/system/bin
wget https://github.com/ubports/halium_bootable_recovery/raw/refs/heads/halium-14.0/ubports/system-image-upgrader -O ramdisk-recovery-overlay/system/bin/system-image-upgrader
chmod +x ramdisk-recovery-overlay/system/bin/system-image-upgrader
sed -i '/verify_signature()/a\    return 0' ramdisk-recovery-overlay/system/bin/system-image-upgrader

./build.sh
adb reboot bootloader; (cd workdir/tmp/partitions && for i in *.img; do fastboot flash ${i%.img} $i; done) && fastboot reboot recovery
sudo ./build/prepare-fake-ota.sh out/device_$(awk -F'"' '/^deviceinfo_codename=/ {print $2}' deviceinfo)_usrmerge.tar.xz ota
adb push ota/{*.tar.xz*,ubuntu_command} /cache/recovery && adb reboot recovery
adb wait-for-recovery && sleep 1 && adb shell tail -f /cache/ubuntu_updater.log

Una vegada que es corregeixen els errors i assumint que els fitxers OTA no són els culpables, el procés es pot tornar a provar sense una altra empenta a través de adb shell 'mv /cache/recovery/ubuntucommand{.applying,}; setprop ctl.restart recovery'. Quan tingui èxit, no us oblideu de ramdisk-recovery-overlay/system/bin/system-image-upgrader ;)