Hvordan DIY Port TWRP for Android

Appuals vert mange for å rote Android-guider, men rotførere finnes ikke for hver enhet på planeten - dette skyldes vanligvis en rekke årsaker; mest spesielt, utilgjengeligheten av en tilpasset gjenoppretting, som TWRP, for en bestemt enhet. Heldigvis er det ikke utrolig vanskelig å transportere en tilpasset gjenoppretting som TWRP til enheten din (men likevel ganske så).

Hvis du har en enhet som du vil rotere og ikke finner noen form for rotmetode tilgjengelig, bør du sterkt vurdere å lære hvordan du sender TWRP til deg selv. Dette vil i det minste gi deg en egendefinert gjenoppretting for å jobbe fra når du forsøker å rote enheten.

Hvis du er interessert i slike DIY Android-prosjekter, bør du også vurdere følgende veiledninger fra Appuals:

Hvordan bygge Mediatek Android Kernel fra Source
Slik bygger du tilpasset ROM fra Android Open Source Project | Pt. 2
Hvordan manuelt tema Android System UI

Forutsetninger:

En grunnleggende kunnskap om Linux-kommandoer og / eller kompilering av AOSP fra grunnen av.

Hvis du ikke er kjent med grunnleggende Linux-kommandoer og / eller bygger AOSP, er denne veiledningen ikke for deg - det er ingen nybegynner vennlig måte å skrive en veiledning for denne prosessen. Jeg foreslår at du prøver å gjøre enklere operasjoner først, for eksempel å lese Appuals veiledning om hvordan du bygger AOSP fra bunnen av.

Nå, for bygging, kan du bruke Omni-versjoner 5.1 til 8.1 eller CM-versjoner 12.1 til 15.1 - men hvis du bruker CM, kan du støte på små problemer relatert til makefile. Hvis du ikke er nyttig ved feilsøking av makefile-problemer, bør du velge å bruke Omni i stedet.

Men hvis du bestemmer deg for å bruke CM, må du plassere TWRP i mappen CM / bootable / recovery-twrp, og sett RECOVERY_VARIANT: = twrp i BoardConfig.mk-filen

Du finner TWRP kildekoden her, og du bør velge den siste tilgjengelige grenen. Du trenger ikke å gjøre dette med Omni, fordi det inkluderer TWRP-kilde som standard, med mindre du bruker en eldre versjon av Omni - i så fall vil du trekke fra den siste grenen.

Hvis du bare vil bygge TWRP, kan du prøve å jobbe med et mindre tre, for eksempel denne Minimal Manifest TWRP. Det kan imidlertid være situasjoner der du trenger flere reposer enn dette manifestet tillater.

Hovednotat før kompilering: Hvis du legger til eller endrer noen flagg, må du rengjøre (eller lage kløver) før du kompilerer, ellers vil ikke flaggendringene bli inkludert!

Etter at du har TWRP-kildekoden, må vi endre noen av byggflaggene for din spesifikke enhet. Finn BoardConfig.mk for enheten din - vanligvis finnes dette i enheter / produsent / kodenavn (for eksempel enheter / lge / hammerhead / BoardConfig.mk)

Board-konfigurasjonen må inkludere arkitektur- og plattforminnstillinger - disse er vanligvis allerede inkludert hvis du bruker en andres enhetskonfigurasjon. Men hvis du har laget din egen, må du legge til dem. Dette er fordi uten dem kan gjenopprettingsstartet segfault og det vil bare blinke TeamWin-logoen på skjermen gjentatte ganger.

Flagg bør settes nederst på BoardConfig.mk, under en overskrift #twrp

For alle enheter må du instruere TWRP hvilket tema du skal bruke. Flagget TW_THEME brukes i stedet for det eldre DEVICE_RESOLUTION-flagget, noe som betyr at TWRP nå bruker skalering for å strekke et hvilket som helst tema.

Alternativene dine er: portrait_hdpi, portrait_mdpi, landscape_hdpi, landscape_mdpi og watch_mdpi. For stående modus vil du mest sannsynlig ha hdpi-temaet på 720 × 1280 og oppover, men for liggende enheter går det med 1280 × 720 og oppover.

Så din flagseksjon + temaflagg skal se slik ut:

#twrp

TW_THEME: = portrait_hdpi

Noen ekstra byggflagger du vil inkludere i denne delen (kreditter til XDA-fora):

RECOVERY_SDCARD_ON_DATA: = true (dette muliggjør riktig håndtering av / data / media på enheter som har denne mappen for lagring (de fleste Honeycomb og enheter som opprinnelig ble levert med ICS som Galaxy Nexus). Dette flagget er ikke nødvendig for disse typer enheter. Ikke definer dette flagget, og ikke med noen referanser til / sdcard, / internal_sd, / internal_sdcard eller / emmc i fstab, da antar vi automatisk at enheten bruker emulert lagring.)
BOARD_HAS_NO_REAL_SDCARD: = true - deaktiverer ting som SD-kortpartisjonering og kan spare deg for plass hvis TWRP ikke passer i gjenopprettingspatisjonen
TW_NO_BATT_PERCENT: = true - deaktiverer visning av batteriprosent for enheter som ikke støtter det riktig
TW_CUSTOM_POWER_BUTTON: = 107 - tilpassede kart på strømknappen for låseskjermen
TW_NO_REBOOT_BOOTLOADER: = true - fjerner startstartknappen for omstart fra rebootmenyen
TW_NO_REBOOT_RECOVERY: = true - fjerner gjenopprett gjenopprettingsknappen fra rebootmenyen
RECOVERY_TOUCHSCREEN_SWAP_XY: = true - bytter kartlegging av berøringer mellom X- og Y-aksen
RECOVERY_TOUCHSCREEN_FLIP_Y: = true-flips y-aksens berøringsskjermverdier
RECOVERY_TOUCHSCREEN_FLIP_X: = true - flips x-aksens berøringsskjermverdier
TWRP_EVENT_LOGGING: = true - muliggjør loggføring av berøringshendelse for å hjelpe deg med å feilsøke berøringsskjermproblemer (ikke la dette på for en utgivelse - det vil fylle opp loggfilen din veldig raskt)
BOARD_HAS_FLIPPED_SCREEN: = true - flips skjermen på hovedet for skjermer som ble montert opp ned

Ytterligere byggflagger kan bli funnet ved å skumre gjennom Android.mk-filene i gjenopprettingskilden, men de brukes vanligvis ikke, så det er ikke noe poeng i å dokumentere dem.

Bruke Recovery.Fstab

TWRP 2.5 og høyere har støtte for nye recovery.fstab funksjoner - spesielt evnen til å utvide TWRPs backup / restore funksjoner. Du trenger ikke å legge til fstab-flagg, fordi de fleste partisjonene automatisk håndteres.

TWRP støtter bare v2 fstabs i versjon 3.2.0 og høyere - i eldre versjoner av TWRP må du bruke det gamle formatet for fstab. Her er et eksempel på TWRP fstab for en Galaxy S4:

For å maksimere kompatibiliteten med ditt bestemte bygge-tre, kan du opprette en twrp.fstab og bruke PRODUCT_COPY_FILES til å plassere i> etc> twrp.fstab.

Når TWRP lanserer og finner twrp.fstab i ramdisken, vil den omdøpe det til> etc> recovery.fstab.bak - i utgangspunktet erstatter det fstab fra enheten med TWRP fstab, som utvider kompatibiliteten.

Eksempelkode:

PRODUCT_COPY_FILES + = enhet / lge / hammerhead / twrp.fstab: gjenoppretting> root> etc> twrp.fstab

FSTAB i TWRP kan inneholde noen flagg for hver partisjon som er oppført i fstab.

Disse flaggene legges til slutten av partisjonlisten i fstab, adskilt av hvitt mellomrom / mellomrom / faner. Flagget vil bare påvirke den partisjonen, men ingen andre. Flaggene er adskilt av semikolon. Her er noen eksempler på kode:

Så la oss undersøke dette litt etter litt. Flagget her vil gi et visningsnavn for Micro SDcard. Wipeingui-flagget gjør denne partisjonen tilgjengelig for å tørke i menyen Advanced Wipe. Det flyttbare flagget indikerer at denne partisjonen ikke alltid er tilstede, noe som forhindrer monteringsfeil fra å bli vist.

En komplett liste over flagg (kreditter til TeamWin) :

flyttbar - indikerer at partisjonen kanskje ikke er til stede, slik at monteringsfeil ikke vises under oppstart
lagring - indikerer at partisjonen kan brukes som lagring som gjør partisjonen tilgjengelig som lagring for sikkerhetskopiering, gjenoppretting, zip installasjoner, etc.
settingsstorage - bare en partisjon skal settes som innstillingslagring, denne partisjonen brukes som plassering for lagring av TWRPs innstillingsfil
canbewiped - indikerer at partisjonen kan bli slettet av back-end-systemet, men kan ikke bli oppført i GUI for å tørke av brukeren
userrmrf - overstyrer normalformattypen for tørking og tillater bare partisjonen å bli slettet med kommandoen rm -rf
backup = - må lykkes med likestegnet, så backup = 1 eller backup = 0, 1 indikerer at partisjonen kan bli oppført i backup / gjenopprettingslisten mens 0 sikrer at denne partisjonen ikke vises i backuplisten.
wipeingui - gjør partisjonen oppe i GUI for å tillate brukeren å velge den for å tørke i den avanserte tørkemenyen
wipeduringfactoryreset - partisjonen vil bli tørket under en fabriksinnstilling
ignoreblkid - blkid brukes til å bestemme hvilket filsystem som brukes av TWRP, dette flagget vil føre til at TWRP hopper over / ignorerer resultatene av blkid og bruker filsystemet spesifisert i fstab bare
retainlayoutversion - får TWRP til å beholde .layoutversion-filen i / data på enheter som Sony Xperia S hvilken type bruk / data / media, men har fortsatt en separat / sdcard-partisjon
symlink = - forårsaker at TWRP kjører en ekstra mount-kommando når du monterer partisjonen, vanligvis brukt med / data / media for å lage / sdcard
display = - angir et visningsnavn for partisjonen for oppføring i GUI
storagename = - angir et lagringsnavn for partisjonen for oppføring i GUI-lagringslisten
backupname = - Angir et reservenavn for partisjonen for oppføring i GUI backup / restore list
lengde = - vanligvis brukt til å reservere tomt rom på slutten av / data-partisjonen for å lagre dekrypteringsnøkkelen når Androids fullstendig kryptering er til stede, kan ikke innstilling av dette føre til manglende evne til å kryptere enheten
canencryptbackup = - 1 eller 0 for å aktivere / deaktivere, gjør TWRP krypterer sikkerhetskopieringen av denne partisjonen hvis brukeren velger kryptering (gjelder bare tar backuper, ikke bilder)
userdataencryptbackup = - 1 eller 0 for å aktivere / deaktivere, gjør TWRP krypterer bare userdata-delen av denne partisjonen, visse deler som / data / app ville ikke bli kryptert for å spare tid
subpartitionof = - må etterfølges av likestilt og partisjonens bane er en underpartisjon av. En underpartisjon behandles som en del av hovedpartisjonen, slik at TWRP automatisk gjør / datadata til en underpartisjon av / data. Dette betyr at / datadata ikke vises i GUI-oppføringene, men / datadata vil bli slettet, sikkerhetskopiert, gjenopprettet, montert og avmontert når som helst disse operasjonene utføres på / data.

Et godt eksempel på bruk av delpartisjoner er 3x efs-partisjonene på LG Optimus G:

Dette klumper alle 3 partisjonene til en enkelt EFS-oppføring i TWRP GUI slik at alle tre kan sikkerhetskopieres og gjenopprettes sammen under en enkelt oppføring.

Med TWRP 3.2.0 og over som bruker V2 Fstab, trenger du ikke å legge til noen byggeflagger. V2 Fstab-støtte er automatisk. V2 Fstab støtter også jokertegn (* symbolet) som kan være nyttig for USB OTG og micro-SD-kort med flere partisjoner. Du kan også fortsette å bruke V1 Fstab-formatet, og det er helt mulig å bruke både V1 og V2-typer i samme Fstab.

For eksempel, her er en V1 Fstab linje med et wildcard ment for en USB OTG:

PRO TIPS: Hvis problemet er med datamaskinen eller en bærbar PC / notatbok, bør du prøve å bruke Reimage Plus-programvaren som kan skanne arkiver og erstatte skadede og manglende filer. Dette fungerer i de fleste tilfeller der problemet er oppstått på grunn av systemkorrupsjon. Du kan laste ned Reimage Plus ved å klikke her

Her er en V2 Fstab-linje for samme enhet som oppnår det samme resultatet:

I tillegg kan du inkludere etc twrp.flags som bruker V1 Fstab-formatet, og de kan brukes til å supplere V2 Fstab med TWRP-flagger, flere partisjoner som ikke er inkludert i V2 Fstab eller overordnede innstillinger i V2 Fstab.

For eksempel kan en Huawei-enhet ha denne V2-fstaben i etc recovery.fstab:

Det kan også ha disse flaggene inkludert:

Så her vil de første to linjene i TWRP.Flags legge til Boot and Recovery-partisjonene, som ikke var tilstede i V2 Fstab. Deretter vil / cust-linjen i TWRP.flags instruere TWRP slik at sluttbrukeren kan sikkerhetskopiere (cust) -partisjonen, og gi den et visningsnavn.

Misc-partisjonen finnes i twrp.flags, og / oeminfo-partisjonen instruerer TWRP for å tillate sikkerhetskopiering og gi det et visningsnavn.

Vi trenger / datalinjen fordi mange Huawei-enheter er kryptert, men bruker spesielle Huawei-binære filer. Derfor bruker vi Huawei-binærene til å dekryptere enheten automatisk i gjenopprettingsmodus. Så her / / / -linjen vil instruere TWRP å bruke / dev / block / dm -0, og ikke / dev / block / bootdevice / bynavn / userdata, som vanligvis brukes til riktig montering.

Endelig er det / system_image, slik at TWRP vil inkludere et alternativ for å lage et systembilde i Backup and Restore menyene.

Den offisielle TeamWin githuben skal også inneholde de nyeste eksemplene på enhetstrær for enheter som har en offisiell TWRP-port. TeamWin github finner du her.

Etter at Omni eller CM har blitt synkronisert, og du har satt opp TWRP-flaggene dine, bør du bygge en kilde ./build/envsetup.sh

Og du vil lunsj enheten, så du kan gjøre noe som lunsj omni_hammerhead.eng.

Etter en vellykket lunsj vil de fleste enheter bruke denne kommandoen:

Du må erstatte # i -j # med kjernetallet +1. Så hvis du har en dobbel kjerne, er det -j3, en quadcore vil være -j5, etc.Velg # med kjernetallet +1, så hvis du har en dobbel kjerne er det -j3 og en quad-kjerne blir -j5, etc.

Også typiske Samsung-enheter krever dette:

Dette skyldes at de fleste Samsung-enheter inkluderer gjenoppretting som en ekstra ramdisk i oppstart, i stedet for på en separat gjenopprettingspartisjon (som de fleste andre enheter bruker).

Nå skal du ha TWRP kompilert for enheten din, og forhåpentligvis virker det i et emulatormiljø. Du bør alltid teste din TWRP-port i et emulatormiljø først, slik at du ikke risikerer å borking enheten.
Last ned dette settet med enhetskonfigurasjonsfiler.

Kompilere et gjenopprettingsbilde ved å bruke disse enhetsfilene. I Android SDK, klikk på Verktøy -> Administrer AVDer. Klikk på Ny. Sett opp det som følger:

Klikk deretter OK.

Når du har din AVD og din gjenopprettingsbilde, kan du starte TWRP i emulatoren ved å bla til android-sdk / tools-mappen din og kjøre denne kommandoen:

Vær oppmerksom på at ADB ikke fungerer umiddelbart. Omtrent 10 til 15 sekunder etter at TWRP er ferdigstart, kommer ADB på nettet. Vi starter ADB via init.rc, så selv om TWRP ikke starter opp på grunn av en slags kodefeil som du kanskje har gjort, bør ADB fortsatt fungere. Nyt!

TWRP og A / B-enheter (kreditter til TeamWin):

Fra et TWRP-standpunkt er A / B-enheter ikke mye forskjellig fra vanlige enheter, men utviklere ser ut til å være sjenert om å jobbe på disse enhetene. Jeg skal prøve å kaste litt lys på dette emnet, og forhåpentligvis vil dette tjene som en guide for å overføre TWRP til A / B-enheter.

For det første, la oss forstå hva som er en A / B-enhet og hvordan det er annerledes. A / B-enheter har duplikater av mange partisjoner på enheten. En A / B-enhet har 2x systempartisjoner, 2x boot partisjoner, 2x leverandør partisjoner, 2x modem / firmware partisjoner, etc. Bare ett spor er i bruk om gangen. Under tidlig oppstart, leser de første stadiene av oppstartslederen litt liten mengde data som kalles BCB eller Bootloader Control Block, og bestemmer om du skal starte A-partisjonene eller B-partisjonene. Når en OTA-oppdatering er tilgjengelig, kopieres dataene fra den aktive sporet fra den inaktive sporet og oppdateres / oppdateres. For eksempel, hvis du for øyeblikket er på plass A, vil enheten laste ned oppdateringen og kopiere den eksisterende systempartisjonen fra spor A og patch / oppdater den med de nye oppdateringene i spor B. Når kopieringen og oppdateringen er fullført, vil BCB oppdateres og enheten starter på nytt ved hjelp av spor B. Neste gang en oppdatering er tilgjengelig, blir systempartisjonen i spor B kopiert til spalte A og oppdatert, BCB blir oppdatert, og vi starter på sporet A. Når du ser partisjoner på enheten, Du ser noe slikt:

Legg merke til dual boot, system og leverandør partisjoner i listen ovenfor, men bare en userdata partisjon.

Selv om det ikke er teknisk krav til at jeg er klar over det, har alle A / B-enheter som sendes til nå, ingen separat gjenopprettingspartisjon. I stedet inneholder bootbildet gjenoppretting i ramdisken. Det viktigste er å vite at boot-bildet nå også inneholder gjenoppretting. For fullstendighet er systempartisjonen et fullt rotfilsystem. Under oppstart, hvis kjernen blir fortalt å starte opp til gjenoppretting, vil den trekke ut ramdisken i oppstartspartisjonen. Hvis kjernen ikke blir fortalt av oppstartslasteren for å starte opp, vil kjernen montere riktig systempartisjon (A eller B) fordi systempartisjonen er et fullt rotfilsystem. Dette betyr at systempartisjonen på disse enhetene er montert på / i stedet for til / system, og systempartisjonen inneholder alle filene som normalt hadde vært i startbilde ramdisk og a / system undermappe.

Fra et TWRP synspunkt er det 3 ting du må gjøre for en A / B-enhet. Først må du sette

Kode:

Til slutt, når du kommer inn i TWRP, vil du sannsynligvis være sikker på at bootctl hal-info reagerer korrekt uten feil. Vanligvis krever bootctl binær et eget bibliotek eller til og med et par tjenester for å fungere riktig. Hvis bootctl ikke fungerer riktig, vil du heller ikke kunne bytte spor i TWRP riktig heller.

I tillegg til innstillingen

Kode:

AB_OTA_UPDATER: = true

du vil kanskje også sette:

Kode:

BOARD_USES_RECOVERY_AS_BOOT: = true

BOARD_BUILD_SYSTEM_ROOT_IMAGE: = true

Hvis du angir

Kode:

BOARD_USES_RECOVERY_AS_BOOT: = true

da får gjenopprettingsbilde ikke lenger fungere, og i stedet må du lage bootimage. Jeg anbefaler ikke å sette inn noen av disse flaggene for TWRP-bare bygge trær. Disse flaggene vil trolig være påkrevd for utviklere å bygge full ROM for A / B-enheter.

Installere / blinke TWRP på A / B-enheter:

Siden alle kjente A / B-enheter ikke har en separat gjenopprettingspartisjon, må du til slutt blinke TWRP til oppstartspartisjonen. På Pixel 1 og 2 bruker vi fastboot-oppstart for midlertidig oppstart av TWRP uten å blinke TWRP. Vi leverer da en zip for å tillate brukere å blinke TWRP til begge sporene. Du kan laste ned en av disse glidelåser fra vår nettside og oppdatere zip-koden som nødvendig for å støtte enhetene dine. Til slutt vil vi legge til verktøy for TWRP for å tillate brukere å blinke gjenoppretting på disse enhetene uten å måtte bruke glidelås.

Nylig jobbet jeg på Razer Phone. Razer-telefonen støtter dessverre ikke hurtigbåtoppstart. I stedet må brukerne bestemme sin aktive oppstartsplass ved bruk av

Kode:

å komme inn i TWRP. En gang i TWRP kan de da gå til omstartssiden og bytte tilbake til deres opprinnelig aktive spor, lage en sikkerhetskopi, og deretter installere TWRP. Ved hjelp av inaktive sporet kan brukerne få en god, umodifisert sikkerhetskopiering av enheten før de installerer TWRP.

Ytterligere notater:

Hvis du ønsker å få TWRP offisielt støttet for enheten din slik at den automatisk kan installeres med TWRP-appen, og du virkelig vil gjøre dette slik at andre eiere av samme enhet kan nyte offisiell TWRP-støtte, og det er det fine å gjøre, må du sende følgende informasjon til TeamWin:

Enhetskonfigurasjonsfiler for å kompilere TWRP fra kilde til enheten din - Ikke pakk om en recovery.img for hånd, de må kompilere den fra kilde.
Etter at TeamWin bygger en kopi av TWRP, sender de den til deg for validering. Når du har validert det, vil TeamWin bygge et fungerende bilde for enheten din, og legge den til den offisielle TWRP-appen.