Hvordan DIY Port TWRP for Android

Viktigste merknader før kompilering: Hvis du legger til eller endrer flagg, må du gjøre rent (eller lage clobber) før du kompilerer på nytt, ellers vil ikke flaggendringene dine være inkludert!

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

Brettkonfigurasjonen må inkludere arkitektur og plattforminnstillinger - disse er vanligvis allerede inkludert hvis du bruker en andres enhetskonfigurasjon. Men hvis du opprettet dine egne, må du legge dem til. Dette er fordi uten dem, kan gjenopprettingsstart oppstå, og det vil bare blinke TeamWin-logoen på skjermen gjentatte ganger.

Flagg skal settes nederst på BoardConfig.mk, under overskriften #twrp

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

Alternativene dine er: portrett_hdpi, portrett_mdpi, landskap_hdpi, landskap_mdpi og watch_mdpi. For portrettmodus vil du mest sannsynlig ha hdpi-temaet 720 × 1280 og oppover, men for liggende enheter går du med 1280 × 720 og oppover.

Så din byggflaggseksjon + temaflagg skal se slik ut:

#twrp

TW_THEME: = portrett_hdpi

Noen ekstra build-flagg du vil inkludere i denne delen (studiepoeng 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 denne typen enheter. Hvis du ikke definere dette flagget og heller ikke inkludere referanser til / sdcard, / internal_sd, / internal_sdcard, eller / emmc i fstab, så vil vi automatisk anta at enheten bruker emulert lagring.)
• BOARD_HAS_NO_REAL_SDCARD: = true - deaktiverer ting som partisjonering av SD-kort og kan spare deg for litt plass hvis TWRP ikke passer i din gjenopprettingspatisjon
• TW_NO_BATT_PERCENT: = true - deaktiverer visningen av batteriprosenten for enheter som ikke støtter den riktig
• TW_CUSTOM_POWER_BUTTON: = 107 - tilpasset kartlegger av / på-knappen for låseskjermen
• TW_NO_REBOOT_BOOTLOADER: = true - fjerner oppstartslaster-knappen fra omstartsmenyen
• TW_NO_REBOOT_RECOVERY: = true - fjerner gjenopprettingsknappen for omstart fra omstartsmenyen
• RECOVERY_TOUCHSCREEN_SWAP_XY: = true - bytter kartlegging av berøringer mellom X- og Y-aksen
• RECOVERY_TOUCHSCREEN_FLIP_Y: = true - vender berøringsskjermverdiene på y-aksen
• RECOVERY_TOUCHSCREEN_FLIP_X: = true - blar x akse berøringsskjermverdier
• TWRP_EVENT_LOGGING: = true - muliggjør logging av berøringshendelser for å feilsøke problemer med berøringsskjermen (ikke la dette være på for en utgivelse - det vil fylle opp loggfilen din veldig raskt)
• BOARD_HAS_FLIPPED_SCREEN: = true - vender skjermen opp ned for skjermer som ble montert opp ned

Ytterligere build-flagg kan bli funnet ved å bla gjennom Android.mk-filene i gjenopprettingskilden, men de brukes vanligvis ikke, så det nytter ikke å dokumentere dem.

Bruke Recovery.Fstab

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

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

For å maksimere kompatibiliteten med det spesifikke build-treet ditt, kan du opprette en twrp.fstab og bruke PRODUCT_COPY_FILES til å plassere i> etc> twrp.fstab.

Når TWRP starter og finner twrp.fstab i ramdisken, vil den endre navn på den til> etc> recovery.fstab.bak - i utgangspunktet erstatter den fstabben fra enheten din med TWRP fstab, som utvider kompatibiliteten.

Eksempel kode:

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 er lagt til til slutten av partisjonen i fstab, atskilt med mellomrom / mellomrom / faner. Flagget vil bare påvirke den partisjonen, men ingen andre. Flaggene er atskilt med semikolon. Her er noen eksempler på kode:

Så la oss undersøke dette litt for litt. Flagget her vil gi et visningsnavn på “Micro SDcard”. Wipeingui-flagget vil gjøre denne partisjonen tilgjengelig for tørking i Advanced Wipe-menyen. Det flyttbare flagget indikerer at denne partisjonen ikke alltid er til stede, noe som forhindrer at monteringsfeil vises.

En komplett liste over flagg (studiepoeng til TeamWin) :

• avtakbar - indikerer at partisjonen kanskje ikke er til stede, og forhindrer at monteringsfeil vises under oppstart
• Oppbevaring - indikerer at partisjonen kan brukes som lagring som gjør partisjonen tilgjengelig som lagring for sikkerhetskopiering, gjenoppretting, zip-installasjoner, etc.
• innstillingslagring - bare en partisjon skal settes som innstillingslagring, denne partisjonen brukes som sted for lagring av TWRPs innstillingsfil
• kanbevisst - indikerer at partisjonen kan tørkes av back-end-systemet, men kanskje ikke er oppført i GUI for å tørke av brukeren
• brukerrmrf - overstyrer den normale formattypen for tørking og lar bare partisjonen tørkes ved hjelp av kommandoen rm -rf
• backup = - må etterfølges av likhetstegnet, så backup = 1 eller backup = 0, 1 indikerer at partisjonen kan være oppført i sikkerhetskopierings- / gjenopprettingslisten, mens 0 sørger for at denne partisjonen ikke vises i sikkerhetskopilisten.
• wipeingui - gjør at partisjonen vises i GUI for å tillate brukeren å velge den for å tørke i den avanserte tørkemenyen
• tørkefaktorinnstilling - partisjonen tørkes under tilbakestilling av fabrikken
• 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 bare bruker filsystemet som er spesifisert i fstab
• retainlayoutversion - får TWRP til å beholde .layoutversion-filen i / data på enheter som Sony Xperia S som slags bruker / data / media, men fortsatt har en egen / sdcard-partisjon
• symlink = - får TWRP til å kjøre en ekstra monteringskommando når du monterer partisjonen, vanligvis brukt med / data / media for å lage / sdcard
• vise = - angir et visningsnavn for partisjonen for oppføring i GUI
• lagringsnavn = - angir et lagringsnavn for partisjonen for oppføring i GUI-lagringslisten
• backupnavn = - angir et backupnavn for partisjonen for oppføring i GUI-sikkerhetskopierings- / gjenopprettingslisten
  lengde = - brukes vanligvis til å reservere tom plass på slutten av / datapartisjonen for lagring av dekrypteringsnøkkelen når Android-enhetens fullstendige kryptering er tilstede, hvis du ikke angir dette, kan det føre til manglende evne til å kryptere enheten
• canencryptbackup = - 1 eller 0 for å aktivere / deaktivere, gjør at TWRP krypterer sikkerhetskopien til denne partisjonen hvis brukeren velger kryptering (gjelder kun tar-sikkerhetskopier, ikke bilder)
• userdataencryptbackup = - 1 eller 0 for å aktivere / deaktivere, gjør at TWRP bare krypterer brukerdata-delen av denne partisjonen, visse subfuldes som / data / app vil ikke bli kryptert for å spare tid
• underdeling av = - må etterfølges av likhetstegnet og banen til partisjonen den er en underdeling av. En underdeling blir behandlet som “del” av hovedpartisjonen, slik at TWRP for eksempel automatisk gjør / datadata til en underdeling av / data. Dette betyr at / datadata ikke vil vises i GUI-oppføringene, men / datadata vil bli slettet, sikkerhetskopiert, gjenopprettet, montert og demontert når som helst disse operasjonene utføres på / data.

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

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

Med TWRP 3.2.0 og nyere som bruker V2 Fstab, kan du trenger ikke legge til noen build-flagg . 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 fullt mulig å bruke både V1- og V2-typene i samme Fstab.

For eksempel er her en V1 Fstab-linje med et jokertegn ment for en USB OTG:

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

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

For eksempel kan en Huawei-enhet ha denne V2 fstab i etc utvinning. Fstab:

Det kan også ha disse flaggene inkludert:

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

/ Misc-partisjonen er tilstede i twrp.flags, og / oeminfo-partisjonen instruerer TWRP om også å tillate sikkerhetskopiering og gi den 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 vil / datalinjen instruere TWRP om å bruke / dev / block / dm -0, og ikke / dev / block / bootdevice / by-name / userdata, som vanligvis brukes til 'riktig' montering '.

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

Den offisielle TeamWin github skal også inneholde de siste eksemplene på enhetstrær for enheter som har en offisiell TWRP-port. TeamWin github finnes HER .

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

Og du vil 'lunsjere' enheten, slik at du kan gjøre noe sånt som 'lunsj omni_hammerhead.eng'.

Etter en vellykket lunsj, vil de fleste enhetene bruke denne kommandoen:

Du må erstatte # in –j # med kjernetallet +1. Så hvis du har en dobbel kjerne, er den –j3, en firekjerne er –j5 osv. Bytt ut # med kjernetallet +1, så hvis du har en dobbel kjerne blir det -j3 og en firekjerne blir til -j5 osv.

Også, typiske Samsung-enheter vil kreve dette:

Dette er fordi de fleste Samsung-enheter inkluderer gjenoppretting som en ekstra ramdisk i bagasjerommet, i stedet for på en egen gjenopprettingspartisjon (som de fleste andre enheter bruker).

Nå skal du ha TWRP samlet for enheten din, og forhåpentligvis fungerer den i et emulatormiljø. Du bør alltid teste TWRP-porten din i et emulatormiljø først, slik at du ikke risikerer å bork deg.
Last ned dette settet med enhetskonfigurasjonsfiler.

Kompiler et gjenopprettingsbilde ved hjelp av disse enhetsfilene. I Android SDK klikker du på Verktøy -> Administrer AVD-er. Klikk på Ny. Sett den opp slik:

Klikk deretter OK.

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

Merk at ADB ikke fungerer med en gang. Omtrent 10 til 15 sekunder etter at TWRP er startet opp, vil ADB komme online. 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 (studiepoeng til TeamWin):

Fra et TWRP-synspunkt er A / B-enheter ikke veldig forskjellige fra vanlige enheter, men utviklere ser ut til å være sjenerte over å jobbe med disse enhetene. Jeg skal prøve å belyse dette emnet, og forhåpentligvis vil dette tjene som en guide for å portere TWRP til A / B-enheter.

For det første, la oss forstå hva som er en A / B-enhet og hvordan den er annerledes. A / B-enheter har duplikater av mange partisjoner på enheten. En A / B-enhet har 2x systempartisjoner, 2x oppstartspartisjoner, 2x leverandørpartisjoner, 2x modem / firmwarepartisjoner osv. Bare ett spor er i bruk om gangen. Under tidlig oppstart leser de første trinnene i opplasteren litt data kalt BCB eller Bootloader Control Block og bestemmer om A-partisjonene eller B-partisjonene skal startes. Når en OTA-oppdatering er tilgjengelig, blir dataene fra det aktive sporet kopiert fra det inaktive sporet og lappet / oppdatert. Hvis du for eksempel er på spor A, vil enheten laste ned oppdateringen og kopiere den eksisterende systempartisjonen fra spor A og lappe / oppdatere den med de nye oppdateringene i spor B. Når kopieringen og oppdateringen er fullført, er BCB oppdateres og enheten starter på nytt med spor B. Neste gang en oppdatering er tilgjengelig, blir systempartisjonen i spor B kopiert til spor A og oppdatert, BCB blir oppdatert, og vi starter på nytt til spor A. Når du ser partisjoner på enheten, du ser noe sånt som dette:

Legg merke til de doble oppstarts-, system- og leverandørpartisjonene i listen ovenfor, men bare en brukerdata-partisjon.

Selv om det teknisk ikke er noe krav som jeg er klar over, har alle A / B-enheter som hittil er sendt ingen separat gjenopprettingspartisjon. I stedet inneholder oppstartsbildet gjenoppretting i sin ramdisk. Det viktige er å vite at oppstartsbildet nå også inneholder gjenopprettingen. For fullstendighet er systempartisjonen et fullstendig root-filsystem. Hvis kjernen får beskjed om å starte opp til gjenoppretting under oppstart, vil den trekke ut ramdisken i oppstartspartisjonen. Hvis kjernen ikke får beskjed fra bootloader om å starte opp til gjenoppretting, vil kjernen montere riktig systempartisjon (A eller B) fordi systempartisjonen er et fullstendig rotfilsystem. Dette betyr at systempartisjonen på disse enhetene er montert på / i stedet for til / system, og systempartisjonen inneholder alle filene som normalt ville vært i boot image ramdisk og en / system-undermappe.

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

Kode:

Til slutt, når du kommer inn i TWRP, vil du sannsynligvis være sikker på at bootctl hal-info reagerer riktig uten feil. Vanligvis krever bootctl binært 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 innenfor TWRP.

I tillegg til innstilling

Kode:

AB_OTA_UPDATER: = sant

du vil kanskje også stille inn:

Kode:

BOARD_USES_RECOVERY_AS_BOOT: = sant

BOARD_BUILD_SYSTEM_ROOT_IMAGE: = sant

Hvis du setter inn

Kode:

BOARD_USES_RECOVERY_AS_BOOT: = sant

så lag recoveryimage vil ikke lenger fungere, og i stedet må du lage bootimage. Jeg anbefaler ikke å sette noen av disse flaggene for trær som bare bygger TWRP. Disse flaggene vil trolig være påkrevd for utviklere som bygger hele ROM-er for A / B-enheter.

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

Siden alle kjente A / B-enheter ikke har en egen gjenopprettingspartisjon, må du til slutt blinke TWRP til oppstartspartisjonen. På Pixel 1 og 2 bruker vi hurtigstart boot for å midlertidig starte TWRP uten å blinke TWRP. Vi leverer deretter en glidelås slik at brukerne kan blinke TWRP til begge sporene. Du kan laste ned en av disse glidelåsene fra nettstedet vårt og oppdatere glidelåsen etter behov for å støtte enhetene dine. Til slutt vil vi legge til verktøy i TWRP for å tillate brukere å blinke gjenoppretting på disse enhetene uten å måtte bruke glidelåser.

Nylig jobbet jeg på Razer Phone. Razer Phone støtter dessverre ikke hurtigstart. I stedet må brukerne bestemme deres aktive boot-spor ved hjelp av

Kode:

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

Ytterligere merknader:

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

1. Enhetskonfigurasjonsfiler for å kompilere TWRP fra kilden for enheten din - ikke pakk om gjenoppretting. img for hånd , må de kompilere det fra kilden.
2. Etter at TeamWin har bygget en kopi av TWRP, sender de den til deg for validering - når du har validert den, vil TeamWin bygge et arbeidsbilde for enheten din, og legge den til i den offisielle TWRP-appen.