Sådan gør du DIY Port TWRP til Android

Appuals værter mange hvordan man kan rotere Android-guider, men root guider findes ikke for alle enheder på planeten - det skyldes normalt en række årsager; mest specielt utilgængeligheden af et brugerdefineret opsving, som TWRP, for en bestemt enhed. Heldigvis er det ikke utroligt svært at transportere en brugerdefineret opsving som TWRP til din enhed (selvom det stadig er ret så).

Hvis du har en enhed, du vil have rod og ikke kan finde nogen form for rodmetode til rådighed, bør du overveje at lære at port TWRP til dig selv. Dette vil i det mindste give dig et brugerdefineret opsving til at arbejde fra, som du forsøger at rod din enhed.

Hvis du er interesseret i disse slags DIY Android-projekter, overvej også at læse følgende vejledninger fra Appuals:

Sådan opbygger du Mediatek Android Kernel fra Source
Sådan opbygges brugerdefineret ROM fra Android Open Source Project | Pt. 2
Sådan manuelt tema Android System UI

Forudsætninger:

Et grundlæggende kendskab til Linux-kommandoer og / eller kompilering af AOSP fra bunden.

Hvis du ikke er bekendt med grundlæggende Linux-kommandoer og / eller bygger AOSP, er denne vejledning ikke til dig - der er ingen nybegyndervenlig måde at skrive en guide til denne proces. Jeg foreslår at prøve nogle lettere operationer først, som at læse Appual's guide til, hvordan man opbygger AOSP fra bunden.

Nu kan du bruge Omni versioner 5.1 til 8.1 eller CM versioner 12.1 til 15.1 - men hvis du bruger CM, kan du støde på små problemer relateret til makefile. Hvis du ikke er praktisk ved fejlfinding af makefile-problemer, skal du vælge at bruge Omni i stedet.

Men hvis du vælger at bruge CM, skal du placere TWRP i mappen CM / bootable / recovery-twrp, og indstil RECOVERY_VARIANT: = twrp i BoardConfig.mk-filen

Du kan finde TWRP-kildekoden her, og du skal vælge den seneste tilgængelige filial. Du behøver ikke at gøre dette med Omni, fordi det indeholder TWRP-kilde som standard, medmindre du bruger en ældre version af Omni - i hvilket tilfælde vil du trække fra den seneste filial.

Hvis du kun vil opbygge TWRP, kan du prøve at arbejde med et mindre træ, som dette Minimal Manifest TWRP. Der kan dog være situationer, hvor du har brug for flere reposer, end dette manifest tillader.

Hovednotat før kompilering: Hvis du tilføjer eller ændrer flag, skal du gøre ren (eller gøre kløver) før genkompilering, ellers vil dine flagændringer ikke medtages!

Når du har TWRP-kildekoden, skal vi ændre nogle af build-flagene til din specifikke enhed. Find BoardConfig.mk for din enhed - typisk findes det i enheder / producent / kodenavn (for eksempel enheder / lge / hammerhead / BoardConfig.mk)

Board-konfigurationen skal indeholde arkitektur- og platformindstillinger - disse er typisk allerede inkluderet, hvis du bruger en andens enhedskonfiguration. Men hvis du har oprettet din egen, skal du tilføje dem. Dette skyldes, at uden dem kan genoprettelsesstartet sigfault, og det vil blot blinke TeamWin-logoet på skærmen gentagne gange.

Flag skal placeres nederst på BoardConfig.mk under en overskrift #twrp

For alle enheder skal du instruere TWRP hvilket tema du skal bruge. Flag TW_THEME bruges i stedet for det ældre DEVICE_RESOLUTION-flag, hvilket betyder, at TWRP nu bruger skalering til at strække ethvert tema.

Dine muligheder er: portrait_hdpi, portrait_mdpi, landscape_hdpi, landscape_mdpi og watch_mdpi. Til portrættilstand vil du højst sandsynligt have hdpi-temaet på 720 × 1280 og op, men for landskabsenheder går det med 1280 × 720 og op.

Så din build flag sektion + tema flag skal se sådan ud:

#twrp

TW_THEME: = portrait_hdpi

Nogle yderligere build-flag, som du vil medtage i dette afsnit (kreditter til XDA-fora):

RECOVERY_SDCARD_ON_DATA: = true (dette muliggør korrekt håndtering af / data / medier på enheder, der har denne mappe til opbevaring (de fleste Honeycomb og enheder, der oprindeligt blev sendt med ICS som Galaxy Nexus). Dette flag er ikke nødvendigt for disse typer enheder. Definer ikke dette flag og indeholder heller ikke nogen henvisninger til / sdcard, / internal_sd, / internal_sdcard eller / emmc i dit fstab, så antager vi automatisk, at enheden bruger emuleret lagring.)
BOARD_HAS_NO_REAL_SDCARD: = true - deaktiverer ting som SD-kortpartitionering og kan spare dig for noget plads, hvis TWRP ikke passer ind i din gendannelsespatition
TW_NO_BATT_PERCENT: = true - deaktiverer visning af batteriprocenten for enheder, som ikke understøtter det korrekt
TW_CUSTOM_POWER_BUTTON: = 107 - brugerdefinerede kort på tænd / sluk-skærmen
TW_NO_REBOOT_BOOTLOADER: = true - fjerner genstart bootloader-knappen fra genstart menuen
TW_NO_REBOOT_RECOVERY: = true - fjerner genstart genoprettelsesknappen fra genstart menuen
RECOVERY_TOUCHSCREEN_SWAP_XY: = true - bytter kortlægningen af kontakter mellem X og Y aksen
RECOVERY_TOUCHSCREEN_FLIP_Y: = true-flips y akse touchscreen værdier
RECOVERY_TOUCHSCREEN_FLIP_X: = true-flips x-aksens berøringsskærmværdier
TWRP_EVENT_LOGGING: = true - muliggør logføring af berøringshændelser for at hjælpe med at debugere berøringsskærmsproblemer (lad det ikke stå på for en udgivelse - det vil fylde din logfil meget hurtigt)
BOARD_HAS_FLIPPED_SCREEN: = true - flipper skærmen på hovedet for skærme, der blev monteret på hovedet

Yderligere build-flag kan findes ved at skumme gennem Android.mk-filerne i genoprettelseskilden, men de bruges typisk ikke, så der er ingen mening i at dokumentere dem.

Brug af Recovery.Fstab

TWRP 2.5 og nyere understøtter nye recovery.fstab funktioner - især evnen til at udvide TWRPs backup / restore funktioner. Du behøver ikke at tilføje fstab-flag, fordi de fleste partitioner automatisk håndteres.

TWRP understøtter kun v2 fstabs i version 3.2.0 og højere - i ældre versioner af TWRP skal du bruge det gamle format af fstab. Her er et eksempel på TWRP fstab til en Galaxy S4:

For at maksimere kompatibiliteten med dit bestemte bygge-træ kan du oprette en twrp.fstab og bruge PRODUCT_COPY_FILES til at placere i> etc> twrp.fstab.

Når TWRP starter og finder twrp.fstab i ramdisken, vil den omdøbe det til> etc> recovery.fstab.bak - det erstatter i princippet fstab fra din enhed med TWRP fstab, som udvider kompatibiliteten.

Eksempelkode:

PRODUCT_COPY_FILES + = enhed / lge / hammerhead / twrp.fstab: gendannelse> root> etc> twrp.fstab

FSTAB i TWRP kan indeholde nogle flag for hver partition, der er angivet i fstab.

Disse flag er tilføjet til slutningen af partitionlisten i fstab, adskilt af hvidt mellemrum / mellemrum / faner. Flagget påvirker kun den partition, men ingen andre. Flag er adskilt af semikoloner. Her er nogle eksempler kode:

Så lad os undersøge dette lidt efter lidt. Flagget her giver et visningsnavn på Micro SDcard. Wipeingui-flagmet gør denne partition ledig til at tørre i menuen Avanceret aftørring. Det flytbare flag angiver, at denne partition ikke altid er til stede, hvilket forhindrer monteringsfejl i at blive vist.

En komplet liste over flag (credits til TeamWin) :

flytbare - angiver, at partitionen muligvis ikke er til stede, så det forhindrer monteringsfejl under opstart
lagring - angiver, at partitionen kan bruges som lagerplads, som gør partitionen tilgængelig som lager til backup, gendannelse, zip-installationer osv.
settingsstorage - kun en partition skal indstilles som indstillingslager, denne partition bruges som stedet til lagring af TWRPs indstillingsfil
canbewiped - indikerer at partitionen kan tørres af back-end-systemet, men kan ikke være angivet i GUI'en for at tørre af brugeren
userrmrf - overstyrer den normale formateringstype for aftørring og tillader kun partitionen at blive slettet ved hjælp af kommandoen rm -rf
backup = - skal efterfølges af ligestegnet, så backup = 1 eller backup = 0, 1 angiver, at partitionen kan opføres i backup / gendannelseslisten, mens 0 sikrer, at denne partition ikke vises i backuplisten.
wipeingui - viser partitionen i GUI'en for at give brugeren mulighed for at vælge den til at tørre i den avancerede aftørringsmenu
wipeduringfactoryreset - partitionen bliver slettet under en fabriksindstilling
ignoreblkid - blkid bruges til at bestemme hvilket filsystem der bruges af TWRP, dette flag vil medføre, at TWRP kan springe / ignorere blkid resultaterne og bruge det filsystem, der er angivet i fstab
retainlayoutversion - får TWRP til at beholde .layoutversion-filen i / data på enheder som Sony Xperia S, hvilken slags anvendelser / data / medier, men stadig har en separat / sdcard-partition
symlink = - får TWRP til at køre en ekstra mount-kommando, når du monterer partitionen, som normalt bruges med / data / medier til at oprette / sdcard
display = - angiver et visningsnavn for partitionen til notering i GUI'en
storagename = - angiver et lagernavn for partitionen til notering i GUI-lagerlisten
backupname = - angiver et backupnavn til partitionen til notering i GUI backup / gendannelseslisten
længde = - bruges normalt til at reservere tomt rum i slutningen af / data-partitionen til lagring af dekrypteringsnøglen, når Android's fulde enheds kryptering er til stede, ikke at indstille dette kan føre til manglende evne til at kryptere enheden
canencryptbackup = - 1 eller 0 for at aktivere / deaktivere, gør TWRP til at kryptere backup af denne partition, hvis brugeren vælger kryptering (gælder kun for back-backup, ikke billeder)
userdataencryptbackup = - 1 eller 0 for at aktivere / deaktivere, gør TWRP kun krypteret userdata-delen af denne partition, visse subfuldes som / data / app ville ikke blive krypteret for at spare tid
subpartitionof = - skal efterfølges af ligestegnet og stien i partitionen er en underpartition af. En underpartition behandles som en del af hovedpartitionen, for eksempel gør TWRP automatisk / datadata en underpartition af / data. Dette betyder at / datadata ikke vises i GUI-oversigterne, men / datadata vil blive slettet, sikkerhedskopieret, gendannet, monteret og afmonteret, når som helst disse operationer udføres på / data.

Et godt eksempel på brugen af subpartitioner er 3x efs partitionerne på LG Optimus G:

Dette klumper alle 3 partitioner til en enkelt EFS-indgang i TWRP GUI, så alle tre kan sikkerhedskopieres og gendannes sammen under en enkelt indgang.

Med TWRP 3.2.0 og derover, der bruger V2 Fstab, behøver du ikke at tilføje nogen build-flag . V2 Fstab-understøttelse er automatisk. V2 Fstab understøtter også jokertegn (* symbolet), som kan være nyttigt for USB OTG og micro-SD-kort med flere partitioner. Du kan også fortsætte med at bruge V1 Fstab formatet, og det er helt muligt at bruge både V1 og V2 typer i samme Fstab.

For eksempel er her en V1 Fstab linje med et wildcard beregnet til en USB OTG:

PRO TIP: Hvis problemet er med din computer eller en bærbar computer / notesbog, skal du prøve at bruge Reimage Plus-softwaren, som kan scanne lagrene og udskifte korrupte og manglende filer. Dette virker i de fleste tilfælde, hvor problemet er opstået på grund af systemkorruption. Du kan downloade Reimage Plus ved at klikke her

Her er en V2 Fstab linje til samme enhed, der opnår det samme resultat:

Derudover kan du inkludere osv. Twrp.flags, der bruger V1 Fstab formatet, og de kan bruges til at supplere V2 Fstab med TWRP flag, yderligere partitioner, der ikke er inkluderet i V2 Fstab eller overordnede indstillinger i V2 Fstab.

For eksempel kan en Huawei enhed have denne V2 fstab i mv recovery.fstab:

Det kan også have disse flag indbefattet:

Så her vil de to første linjer i TWRP.Flags tilføje Boot og Recovery partitionerne, som ikke var til stede i V2 Fstab. Derefter vil / cust linjen i TWRP.flags instruere TWRP for at give slutbrugeren mulighed for at sikkerhedskopiere (cust) partitionen og give det et visningsnavn.

Misc-partitionen er til stede i twrp.flags, og / oeminfo partitionen instruerer TWRP for også at tillade sikkerhedskopiering og give det et visningsnavn.

Vi har brug for / datalinjen, fordi mange Huawei-enheder er krypterede, men bruger specielle Huawei-binarier - derfor bruger vi Huawei-binarierne til at dekryptere enheden automatisk i genoprettelsesfunktion. Så her / / / -linjen vil instruere TWRP til at bruge / dev / block / dm -0 og ikke / dev / block / bootdevice / bynavn / userdata, som typisk bruges til korrekt montering.

Endelig er der / system_image, så TWRP vil indeholde en mulighed for at oprette et systembillede i menuerne Sikkerhedskopiering og gendannelse.

Den officielle TeamWin github skal også indeholde de nyeste eksempler på enheden træer til enheder, der har en officiel TWRP-port. TeamWin github kan findes HER.

Når Omni eller CM er blevet synkroniseret, og du har oprettet dine TWRP-flag, skal du opbygge en kilde ./build/envsetup.sh

Og du vil gerne spise enheden, så du kan gøre noget som frokost omni_hammerhead.eng.

Efter en vellykket frokost bruger de fleste enheder denne kommando:

Du skal erstatte # i -j # med kernetællingen +1. Så hvis du har en dobbeltkern, er det -j3, en quadcore vil være -j5, etc.Vælg venligst # med kernetællingen +1, så hvis du har en dobbelt kerne, bliver -j3 og en quad-kerne -j5, osv.

Også typiske Samsung-enheder vil kræve dette:

Dette skyldes, at de fleste Samsung-enheder omfatter genoprettelsen som en ekstra ramdisk i opstart, i stedet for på en separat gendannelsespartition (som de fleste andre enheder bruger).

På nuværende tidspunkt skal du have TWRP kompileret til din enhed og forhåbentlig fungerer det i et emulator miljø. Du bør altid teste din TWRP-port i et emulatormiljø først, så du risikerer ikke at borking din enhed.
Download dette sæt enhedskonfigurationsfiler.

Kompilere et genoprettelsesbillede med disse enhedsfiler. I Android SDK skal du klikke på Værktøjer -> Administrer AVD'er. Klik på Ny. Opsæt det som følgende:

Klik derefter på OK.

Når du har din AVD og dit genoprettelsesbillede, kan du starte TWRP i emulatoren ved at bladre til din android-sdk / tools-mappe og køre denne kommando:

Bemærk, at ADB ikke fungerer med det samme. Ca. 10 til 15 sekunder efter, at TWRP er færdigstartet, kommer ADB online. Vi starter ADB via init.rc, så selv om TWRP ikke starter op på grund af en form for kodefejl, du måtte have lavet, bør ADB stadig arbejde. God fornøjelse!

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

Fra et TWRP-synspunkt er A / B-enheder ikke meget forskellige fra almindelige enheder, men udviklere synes at være genert for at arbejde på disse enheder. Jeg vil forsøge at kaste lys over dette emne, og forhåbentlig vil dette fungere som en vejledning til at overføre TWRP til A / B-enheder.

For det første lad os forstå, hvad der er en A / B-enhed, og hvordan den er anderledes. A / B-enheder har dubletter af mange partitioner på enheden. En A / B-enhed har 2x systempartitioner, 2x boot partitioner, 2x vendor partitioner, 2x modem / firmware partitioner, etc. Kun én slot er i brug ad gangen. Under den tidlige opstart læste de første trin i bootloaderen nogle små mængder data kaldet BCB eller Bootloader Control Block og bestemmer, om A-partitionerne eller B-partitionerne skal startes. Når en OTA-opdatering er tilgængelig, kopieres dataene fra den aktive slot til den inaktive slot og patches / opdateres. Hvis du for eksempel er i slot A, vil din enhed downloade opdateringen og kopiere den eksisterende systempartition fra slot A og patch / opdatere den med de nye opdateringer i slot B. Når kopieringen og opdateringen er afsluttet, BCB opdateres, og enheden genstarter med slot B. Næste gang en opdatering er tilgængelig, kopieres systempartitionen i slot B til slot A og opdateres, BCB opdateres, og vi genstarter til slot A. Når du ser partitioner på enheden, du vil se noget sådan her:

Bemærk de dobbelte boot, system og leverandør partitioner i listen ovenfor, men kun en userdata partition.

Selvom der ikke er noget teknisk krav til, at jeg er opmærksom på, har alle A / B-enheder, der er afsendt indtil videre, ingen separat gendannelsespartition. I stedet indeholder bootbilledet genoprettelsen i ramdisken. Det vigtige er at vide, at bootbilledet nu også indeholder genoprettelsen. For fuldstændighed er systempartitionen et fuldt rodfilsystem. Under opstart, hvis kernen bliver bedt om at starte til genoprettelse, vil den ekstrahere ramdisken i bootpartitionen. Hvis kernen ikke bliver fortalt af bootloaderen for at starte til genoprettelse, vil kernen montere den relevante systempartition (A eller B), fordi systempartitionen er et fuldt rodfilsystem. Dette betyder, at systempartitionen på disse enheder er monteret til / i stedet for til / system, og systempartitionen indeholder alle de filer, der normalt ville have været i opstartsbilledramdisken og a / system-undermappen.

Fra et TWRP synspunkt er der 3 ting, du skal gøre for en A / B-enhed. Først skal du indstille

Kode:

Endelig, når du kommer ind i TWRP, vil du nok gerne sørge for, at bootctl hal-info reagerer korrekt uden fejl. Normalt kræver bootctl binær et proprietært bibliotek eller endda et par tjenester til at fungere korrekt. Hvis bootctl ikke fungerer korrekt, vil du heller ikke kunne skifte slots inden for TWRP korrekt.

Ud over at indstille

Kode:

AB_OTA_UPDATER: = true

du vil måske også indstille:

Kode:

BOARD_USES_RECOVERY_AS_BOOT: = true

BOARD_BUILD_SYSTEM_ROOT_IMAGE: = true

Hvis du indstiller

Kode:

BOARD_USES_RECOVERY_AS_BOOT: = true

så gør genoprettelsesbillede ikke længere, og i stedet skal du lave bootimage. Jeg anbefaler ikke at indstille en af disse flag for TWRP-only build trees. Disse flag vil sandsynligvis være påkrævet for udviklere at opbygge komplette ROM'er til A / B-enheder.

Installation / blinkning af TWRP på A / B-enheder:

Da alle kendte A / B-enheder ikke har en separat gendannelsespartition, skal du til sidst blinke TWRP til bootpartitionen. På Pixel 1 og 2 bruger vi fastboot boot til midlertidigt at starte TWRP uden at blinke TWRP. Vi leverer derefter en lynlås, så brugerne kan blinke TWRP til begge slots. Du kan downloade en af disse lynlås fra vores hjemmeside og opdatere lynlås som nødvendigt for at understøtte dine enheder. Til sidst vil vi tilføje værktøjer til TWRP, så brugerne kan blinke gendannelser på disse enheder uden at skulle bruge lynlåse.

For nylig arbejdede jeg på Razer Phone. Razer Phone understøtter desværre ikke hurtigstart boot. I stedet skal brugerne bestemme deres aktuelt aktive boot slot ved hjælp af

Kode:

at komme ind i TWRP. En gang i TWRP kan de derefter gå til genstartssiden og skifte tilbage til deres oprindeligt aktive slot, lave en sikkerhedskopi og derefter installere TWRP. Brug af inaktiv slot giver brugerne mulighed for at få en god, umodificeret backup af deres enhed, før du installerer TWRP.

Ekstra Noter:

Hvis du gerne vil få TWRP officielt understøttet til din enhed, så den kan installeres automatisk med TWRP-appen, og du vil virkelig gøre det, så andre ejere af samme enhed kan nyde officiel TWRP-support, og det er det rareste at gøre, skal du sende følgende oplysninger til TeamWin:

Enheds konfigurationsfiler til at kompilere TWRP fra kilde til din enhed - ikke ompakke en recovery.img for hånd, de skal compilere den fra kilden.
Når TeamWin bygger en kopi af TWRP, sender de det til dig for validering. Når du har valideret det, vil TeamWin bygge et arbejdsbilde for din enhed og føje det til den officielle TWRP-app.