Com fer un port TWRP per a Android

Com És?
, podeu provar de treballar amb un arbre més petit, com aquest Manifest mínim TWRP . Tanmateix, pot haver-hi situacions en què necessiteu més reposicions del que permet aquest manifest.



Nota important abans de compilar: si afegiu o canvieu algun senyalador, haureu de netejar-lo (o fer-ne un clobber) abans de tornar a compilar-lo, en cas contrari els canvis de senyaladors no s'inclouran.

Un cop tingueu el codi font TWRP, hem de canviar algunes de les marques de compilació del vostre dispositiu específic. Cerqueu BoardConfig.mk per al vostre dispositiu, normalment es troba a dispositius / fabricant / nom de codi (per exemple, dispositius / lge / hammerhead / BoardConfig.mk)



La configuració de la placa ha d’incloure paràmetres d’arquitectura i plataforma: normalment ja s’inclouen si feu servir la configuració del dispositiu d'una altra persona. Però si n’heu creat la vostra, n’haureu d’afegir. Això es deu al fet que, sense ells, l’arrencada de recuperació pot produir-se de manera segura i només llamparà el logotip de TeamWin a la pantalla repetidament.



Les banderes s'han de posar a la part inferior de BoardConfig.mk, sota un encapçalament de #twrp



Per a tot dispositius, heu d’indicar a TWRP quin tema s’ha d’utilitzar. S'utilitza el senyalador TW_THEME en lloc del senyal DEVICE_RESOLUTION anterior, el que significa que ara TWRP utilitza l'escala per estirar qualsevol tema.

Les vostres opcions són: portrait_hdpi, portrait_mdpi, landscape_hdpi, landscape_mdpi i watch_mdpi. Per al mode retrat, és probable que vulgueu el tema hdpi de 720 × 1280 o superior, però per als dispositius horitzontals aneu amb 1280 × 720 o més.

Per tant, la vostra secció de bandera de construcció + bandera de tema hauria de ser així:



#twrp

TW_THEME: = portrait_hdpi

Alguns indicadors de compilació addicionals que voldreu incloure en aquesta secció (crèdits als fòrums XDA):

  • RECOVERY_SDCARD_ON_DATA: = true (permet la manipulació adequada de / data / media en dispositius que tinguin aquesta carpeta per emmagatzemar-la (la majoria de Honeycomb i dispositius que s’enviaven originalment amb ICS com Galaxy Nexus)). no definiu aquesta marca i tampoc no inclogueu cap referència a / sdcard, / internal_sd, / internal_sdcard o / emmc al vostre fstab, doncs assumirem automàticament que el dispositiu utilitza emmagatzematge emulat.)
  • BOARD_HAS_NO_REAL_SDCARD: = true: desactiva aspectes com el particionament de la targeta SD i us pot estalviar una mica d’espai si TWRP no s’adapta a la vostra sol·licitud de recuperació
  • TW_NO_BATT_PERCENT: = true: desactiva la visualització del percentatge de bateria dels dispositius que no la suporten correctament
  • TW_CUSTOM_POWER_BUTTON: = 107: mapa personalitzat del botó d’engegada de la pantalla de bloqueig
  • TW_NO_REBOOT_BOOTLOADER: = true: elimina el botó del carregador d'arrencada del menú de reinici
  • TW_NO_REBOOT_RECOVERY: = true: elimina el botó de recuperació de reinici del menú de reinici
  • RECOVERY_TOUCHSCREEN_SWAP_XY: = true: canvia el mapatge de tocs entre els eixos X i Y
  • RECOVERY_TOUCHSCREEN_FLIP_Y: = true: gira els valors de la pantalla tàctil de l'eix y
  • RECOVERY_TOUCHSCREEN_FLIP_X: = true: gira els valors de la pantalla tàctil de l'eix x
  • TWRP_EVENT_LOGGING: = true: permet el registre d’esdeveniments tàctils per ajudar a depurar problemes de pantalla tàctil (no deixeu això activat per a una versió; omplirà el fitxer de registre molt ràpidament)
  • BOARD_HAS_FLIPPED_SCREEN: = true: gira la pantalla cap per avall per a pantalles muntades cap per avall

Es poden trobar indicadors de compilació addicionals fent un recorregut pels fitxers Android.mk de la font de recuperació, però normalment no s’utilitzen, de manera que no té cap sentit documentar-los.

Utilitzant Recovery.Fstab

TWRP 2.5 i versions posteriors admeten noves funcions de recovery.fstab, sobretot la possibilitat d’ampliar les funcions de còpia de seguretat / restauració de TWRP. No cal afegir senyaladors fstab, perquè la majoria de les particions es gestionaran automàticament.

TWRP només admet fstabs v2 a la versió 3.2.0 i posteriors; en versions anteriors de TWRP, haureu d’utilitzar el format antic de fstab. Aquí teniu un exemple de TWRP fstab per a un Galaxy S4:

Per maximitzar la compatibilitat amb l'arbre de construcció concret, podeu crear un twrp.fstab i utilitzar PRODUCT_COPY_FILES per col·locar-lo a> etc> twrp.fstab.

Quan TWRP llança i troba twrp.fstab al disc ram, el canviarà de nom a> etc> recovery.fstab.bak: bàsicament substitueix el fstab del dispositiu pel TWRP fstab, que amplia la compatibilitat.

Codi d'exemple:

PRODUCT_COPY_FILES + = device / lge / hammerhead / twrp.fstab: recovery> root> etc> twrp.fstab

La fstab de TWRP pot contenir algunes 'marques' per a cada partició llistada a la fstab.

Aquestes banderes s’afegeixen fins al final del llistat de particions a la fstab, separades per espais en blanc / espais / pestanyes. La bandera només afectarà aquesta partició, però cap altra. Les banderes estan separades per punts i coma. Aquí teniu un exemple de codi:

Així doncs, examinem això a poc a poc. El senyalador aquí mostrarà el nom visible de 'Micro SDcard'. La marca wipeingui farà que aquesta partició estigui disponible per esborrar-la al menú Advanced Wipe. El senyalador extraïble indica que aquesta partició no sempre és present, cosa que evitarà que es mostrin errors de muntatge.

Una llista completa de banderes (crèdits a TeamWin) :

  • extraïble - indica que és possible que la partició no estigui present evitant que es mostrin errors de muntatge durant l'arrencada
  • emmagatzematge - indica que la partició es pot utilitzar com a emmagatzematge, cosa que fa que la partició estigui disponible com a emmagatzematge per a la còpia de seguretat, restauració, instal·lacions zip, etc.
  • settingsstorage - només s’hauria d’establir una partició com a emmagatzematge de configuracions, aquesta partició s’utilitza com a ubicació per emmagatzemar el fitxer de configuració de TWRP
  • esborrat - indica que el sistema back-end pot esborrar la partició, però pot ser que no aparegui a la GUI perquè l’usuari l’esborri.
  • userrmrf - anul·la el tipus de format normal de neteja i només permet esborrar la partició mitjançant l'ordre rm -rf
  • còpia de seguretat =: el signe igual ha de succeir-lo, de manera que còpia de seguretat = 1 o còpia de seguretat = 0, 1 indica que la partició es pot incloure a la llista de còpia de seguretat / restauració mentre que 0 assegura que aquesta partició no apareixerà a la llista de còpia de seguretat.
  • wipeingui - fa que la partició aparegui a la GUI per permetre a l'usuari seleccionar-la per esborrar-la al menú de neteja avançat
  • wipeduringfactoryreset - la partició s'esborrarà durant un restabliment de fàbrica
  • ignoreblkid - blkid s'utilitza per determinar quin sistema de fitxers utilitza TWRP, aquest indicador farà que TWRP ometi / ignori els resultats de blkid i utilitzi només el sistema de fitxers especificat a la fstab
  • retainlayoutversion - fa que TWRP retingui el fitxer .layoutversion a / data en dispositius com Sony Xperia S, que utilitza / data / media, però que encara té una partició / sdcard separada
  • enllaç simbòlic = - fa que TWRP executi una ordre de muntatge addicional quan es munta la partició, generalment s'utilitza amb / data / media per crear / sdcard
  • visualització = - estableix un nom de visualització per a la partició que es llistarà a la GUI
  • nom del magatzem = - estableix un nom d'emmagatzematge per a la partició per incloure-la a la llista d'emmagatzematge GUI
  • nom de còpia de seguretat = - estableix un nom de còpia de seguretat per a la partició per incloure a la llista de còpia de seguretat / restauració de la GUI
    longitud =: s'utilitza generalment per reservar espai buit al final de la partició / data per emmagatzemar la clau de desxifratge quan hi ha xifratge complet del dispositiu d'Android, si no es configura això pot provocar la impossibilitat de xifrar el dispositiu
  • canencryptbackup = - 1 o 0 per activar / desactivar, fa que TWRP xifri la còpia de seguretat d'aquesta partició si l'usuari tria el xifratge (només s'aplica a les còpies de seguretat tar, no a les imatges)
  • userdataencryptbackup = - 1 o 0 per habilitar / desactivar, fa que TWRP xifri només la part de dades de l'usuari d'aquesta partició, certs subdimensions com / data / app no ​​es xifraran per estalviar temps
  • subparticióde = - Ha de ser succeït pel signe igual i el camí de la partició de la qual és una subpartició. Una subpartició es tracta com a 'part' de la partició principal, de manera que, per exemple, TWRP converteix automàticament / datadata en una subpartició de / data. Això significa que / datadata no apareixerà als llistats de la GUI, però / datadata s'esborrarà, es farà una còpia de seguretat, es restaurarà, es muntarà i es desmuntarà cada vegada que es realitzin aquestes operacions a / data.

Un bon exemple de l’ús de subparticions són les particions efs 3x del LG Optimus G:

Això agrupa les 3 particions en una única entrada 'EFS' a la GUI de TWRP, cosa que permet fer una còpia de seguretat de totes tres i restaurar-les juntes sota una sola entrada.

Amb TWRP 3.2.0 i versions posteriors que utilitzen V2 Fstab, vostè no cal afegir cap senyalador de construcció . El suport Fstab de V2 és automàtic. V2 Fstab també admet comodins (el símbol *) que poden ser útils per a targetes USB OTG i micro-SD amb múltiples particions. També podeu continuar utilitzant el format Fstab V1 i és totalment possible utilitzar els tipus V1 i V2 al mateix Fstab.

Per exemple, aquí teniu una línia Fstab V1 amb un comodí destinat a un USB OTG:

Aquí teniu una línia V2 Fstab per al mateix dispositiu que aconsegueix el mateix resultat:

A més, podeu incloure etc twrp.flags que utilitzen el format V1 Fstab i es poden utilitzar per complementar el V2 Fstab amb indicadors TWRP, particions addicionals no incloses al V2 Fstab o configuracions de substitució al V2 Fstab.

Per exemple, un dispositiu Huawei pot tenir aquesta fstab V2 a la recuperació, etc.

També pot incloure aquestes marques:

Aquí, doncs, les dues primeres línies de TWRP.Flags afegiran les particions Boot i Recovery, que no eren presents al V2 Fstab. A continuació, la línia / cust a TWRP.flags indicarà a TWRP que permeti a l'usuari final fer una còpia de seguretat de la partició (cust) i li donarà un nom visible.

La partició / misc està present a twrp.flags i la partició / oeminfo indica a TWRP que també permeti fer còpies de seguretat i donar-li un nom visible.

Necessitem la línia de dades perquè molts dispositius Huawei estan xifrats, però fem servir binaris especials de Huawei; per tant, fem servir els binaris Huawei per desxifrar el dispositiu automàticament en mode de recuperació. Per tant, aquí la línia de dades indicarà a TWRP que utilitzi / dev / block / dm -0 i no / dev / block / bootdevice / per-nom / userdata, que normalment s’utilitza per al muntatge “adequat”.

Finalment hi ha / system_image, de manera que TWRP inclourà una opció per crear una imatge del sistema als menús Còpia de seguretat i restauració.

El github oficial de TeamWin també hauria de contenir els exemples més recents d’arbres de dispositius per a dispositius que tinguin un port TWRP oficial. Es pot trobar el github de TeamWin AQUÍ .

Un cop s'hagi sincronitzat Omni o CM i hagis configurat els indicadors TWRP, hauries de crear una font ./build/envsetup.sh

I voldreu 'dinar' el dispositiu perquè pugueu fer alguna cosa com 'lunch omni_hammerhead.eng'.

Després d'un dinar reeixit, la majoria dels dispositius utilitzaran aquesta ordre:

Heu de substituir el # a –j # pel recompte del nucli +1. Per tant, si teniu un nucli dual, és –j3, un quadcore serà –j5, etc. Substituïu el # amb el recompte de nucli +1, de manera que si teniu un nucli dual és -j3 i un quad core es converteix en -j5, etc.

A més, els dispositius Samsung típics requereixen això:

Això es deu al fet que la majoria de dispositius Samsung inclouen la recuperació com a disc ram addicional a l'arrencada, en lloc de fer-ho en una partició de recuperació independent (que fan servir la majoria dels altres dispositius).

A hores d'ara, hauríeu de compilar TWRP per al vostre dispositiu i, amb sort, funcionarà en un entorn d'emulador. Sempre hauríeu de provar primer el port TWRP en un entorn d’emulador, de manera que no us arrisqueu a escorcollar el dispositiu.
Baixeu aquest conjunt de fitxers de configuració del dispositiu.

Compileu una imatge de recuperació amb aquests fitxers del dispositiu. A l'SDK d'Android, feu clic a Eines -> Gestiona els AVD. Feu clic a Nou. Configureu-lo com segueix:

A continuació, feu clic a D'acord.

Un cop tingueu el vostre AVD i la vostra imatge de recuperació, podeu arrencar TWRP a l'emulador navegant a la carpeta android-sdk / tools i executar aquesta ordre:

Tingueu en compte que l’ADB no funciona de seguida. Uns 10 a 15 segons després que TWRP acabi d’arrencar, l’ADB entrarà en línia. Comencem ADB mitjançant init.rc, per tant, fins i tot si TWRP no arrenca a causa d'un tipus de error de codi que és possible que hàgiu comès, ADB hauria de funcionar. Gaudiu-ne!

Dispositius TWRP i A / B (crèdits a TeamWin):

Des del punt de vista de TWRP, els dispositius A / B no són molt diferents dels dispositius habituals, però els desenvolupadors semblen ser tímids a treballar en aquests dispositius. Intentaré aportar una mica de llum sobre aquest tema i espero que serveixi de guia per portar TWRP a dispositius A / B.

En primer lloc, entenem què és un dispositiu A / B i com és diferent. Els dispositius A / B tenen duplicats de moltes particions al dispositiu. Un dispositiu A / B té 2 particions de sistema, 2 particions d’arrencada, 2 particions de proveïdor, 2 particions de mòdem / microprogramari, etc. Només s’utilitza una ranura a la vegada. Durant l’arrencada inicial, les primeres etapes del carregador d’arrencada llegien una petita quantitat de dades anomenades BCB o Bootloader Control Block i decidien si arrencar les particions A o les particions B. Quan hi ha disponible una actualització OTA, les dades de la ranura activa es copien des de la ranura inactiva i s’han actualitzat o actualitzat. Per exemple, si esteu actualment a la ranura A, el dispositiu descarregaria l’actualització i copiaria la partició del sistema existent de la ranura A i la corregiria / actualitzaria amb les noves actualitzacions a la ranura B. Un cop finalitzada la còpia i actualització, el BCB s’actualitza i el dispositiu es reinicia mitjançant l’espai B. La propera vegada que estigui disponible una actualització, la partició del sistema a l’espai B es copia a l’espai A i s’actualitza, el BCB s’actualitza i reiniciem a l’espai A. Quan visualitzeu particions al dispositiu, veuràs una cosa així:

càmera portàtil asus al revés

Tingueu en compte les particions d'arrencada dual, sistema i proveïdor a la llista anterior, però només una partició de dades d'usuari.

Tot i que tècnicament no hi ha cap requisit que tinc coneixement, tots els dispositius A / B que s’envien fins ara no tenen cap partició de recuperació separada. En canvi, la imatge d’arrencada conté la recuperació al disc ram. L’important és saber que la imatge d’arrencada també conté la recuperació. Per completar-la, la partició del sistema és un sistema de fitxers arrel complet. Durant l'arrencada, si es diu que el nucli arrenca a la recuperació, extreurà el disc ram a la partició d'arrencada. Si el carregador d’inici no indica al nucli que arrenci a la recuperació, el nucli muntarà la partició del sistema adequada (A o B) perquè la partició del sistema és un sistema de fitxers arrel complet. Això vol dir que la partició del sistema en aquests dispositius està muntada a / en lloc de a / system i la partició del sistema conté tots els fitxers que normalment haurien estat al disc ram ram de la imatge d’arrencada i a la subcarpeta / system.

Des del punt de vista TWRP, hi ha tres coses que heu de fer per a un dispositiu A / B. En primer lloc, cal configurar-lo

Codi:

Finalment, un cop accediu a TWRP, probablement voldreu assegurar-vos que bootctl hal-info respongui correctament sense errors. Normalment, el binari bootctl requereix una biblioteca propietària o fins i tot un parell de serveis per funcionar correctament. Si bootctl no funciona correctament, tampoc no podreu canviar les ranures de TWRP correctament.

A més de configurar

Codi:

AB_OTA_UPDATER: = cert

és possible que també vulgueu configurar:

Codi:

BOARD_USES_RECOVERY_AS_BOOT: = cert

BOARD_BUILD_SYSTEM_ROOT_IMAGE: = cert

Si s’estableix

Codi:

BOARD_USES_RECOVERY_AS_BOOT: = cert

llavors fer recoveryimage deixarà de funcionar i, en canvi, haurà de fer bootimage. No recomano establir cap d'aquestes marques per als arbres de construcció només TWRP. Aquests indicadors probablement seran necessaris per als desenvolupadors que construeixin ROM completes per a dispositius A / B.

Instal·lació / intermitència de TWRP en dispositius A / B:

Com que tots els dispositius A / B coneguts no tenen una partició de recuperació independent, finalment haurà de fer flash TWRP a la partició d'arrencada. Al Pixel 1 i 2, fem servir l’arrencada d’arrencada ràpida per arrencar temporalment TWRP sense parpellejar TWRP. A continuació, subministrem un fitxer zip per permetre als usuaris fer flash TWRP a les dues ranures. Podeu descarregar una d’aquestes cremalleres des del nostre lloc web i actualitzar el fitxer zip segons sigui necessari per donar suport als vostres dispositius. Finalment, afegirem eines a TWRP per permetre als usuaris fer flash de recuperacions en aquests dispositius sense necessitat d’utilitzar cremalleres.

Recentment he treballat al telèfon Razer. Malauradament, el telèfon Razer no admet l'arrencada ràpida. En lloc d'això, els usuaris han de determinar la seva ranura d'arrencada activa actualment mitjançant

Codi:

per entrar a TWRP. Un cop a TWRP, poden anar a la pàgina de reinici i tornar a la seva ranura activa original, fer una còpia de seguretat i instal·lar TWRP. L’ús de la ranura inactiva permet als usuaris obtenir una bona còpia de seguretat sense modificar el seu dispositiu abans d’instal·lar TWRP.

Notes addicionals:

Si voleu obtenir TWRP admès oficialment per al vostre dispositiu perquè es pugui instal·lar automàticament amb l'aplicació TWRP, i realment voleu fer-ho perquè altres propietaris del mateix dispositiu puguin gaudir de l'assistència oficial de TWRP i sigui el millor que heu de fer, haureu d'enviar la informació següent a Guany de l'equip:

  1. Fitxers de configuració del dispositiu per compilar TWRP des de la font per al vostre dispositiu - no torneu a empaquetar un recovery.img a mà , han de compilar-lo des de la font.
  2. Un cop TeamWin hagi creat una còpia de TWRP, l’enviaran per validar-la; un cop l’hagueu validat, TeamWin crearà una imatge de treball per al vostre dispositiu i l’afegirà a l’aplicació oficial TWRP.
13 minuts de lectura