Så här gör du DIY Port TWRP för Android

Appuals värdar många hur man rotar Android-guider, men rotguider finns inte för varje enhet på planeten - detta beror vanligtvis på ett antal skäl. mest speciellt otillgängligheten av en anpassad återställning, som TWRP, för en viss enhet. Lyckligtvis är det inte otroligt svårt att överföra en anpassad återställning som TWRP till din enhet (men fortfarande ganska så).

Om du har en enhet som du vill rota och inte kan hitta någon form av rotmetod som är tillgänglig, bör du starkt överväga att lära dig hur du använder TWRP för dig själv. Detta kommer åtminstone att ge dig en anpassad återställning för att fungera från när du försöker rotera din enhet.

Om du är intresserad av dessa typer av DIY Android-projekt, överväg också att läsa följande guider från Appuals:

Hur man bygger Mediatek Android Kernel från Source
Hur man bygger anpassad ROM från Android Open Source Project | Pt. 2
Hur man manuellt tema Android System UI

Förutsättningar:

En grundläggande kunskap om Linux-kommandon och / eller kompilering av AOSP från början.

Om du inte är bekant med grundläggande Linux-kommandon och / eller bygger AOSP, är den här guiden inte för dig - det finns ingen nybörjare vänlig väg att skriva en guide till för processen. Jag föreslår att jag försöker göra enklare operationer först, till exempel att läsa Appuals guide om hur man bygger AOSP från början.

Nu, för byggnad kan du använda Omni-versionerna 5.1 till 8.1 eller CM-versionerna 12.1 till 15.1 - men om du använder CM kan du stöta på små problem relaterade till makefile. Om du inte är användbar vid felsökning av makefile-problem bör du välja att använda Omni istället.

Men om du väljer att använda CM måste du placera TWRP i mappen CM / bootable / recovery-twrp och ange RECOVERY_VARIANT: = twrp i BoardConfig.mk-filen

Du kan hitta TWRP-källkoden här, och du borde välja den senaste tillgängliga filialen. Du behöver inte göra det med Omni, eftersom det innehåller TWRP-källan som standard, om du inte använder en äldre version av Omni - i vilket fall vill du dra från den senaste filialen.

Om du bara vill bygga TWRP kan du försöka arbeta med ett mindre träd, till exempel denna Minimal Manifest TWRP. Det kan dock finnas situationer där du behöver mer repos än det här manifestet tillåter.

Viktig anteckning före sammanställning: Om du lägger till eller ändrar flaggor måste du rengöra (eller göra klibb) innan du kompilerar, annars kommer dina flaggändringar inte att inkluderas!

När du har TWRP-källkoden behöver vi ändra några av byggflaggarna för din specifika enhet. Hitta BoardConfig.mk för din enhet - vanligtvis kommer det att hittas i enheter / tillverkare / kodnamn (till exempel enheter / lge / hammerhead / BoardConfig.mk)

Styrkonfigurationen måste innehålla arkitektur- och plattformsinställningar - dessa ingår vanligtvis redan om du använder någon annans enhetskonfiguration. Men om du skapade din egen måste du lägga till dem. Detta beror på att utan dem kan återställningsstartet segfault och det kommer bara att blinka TeamWin-logotypen på skärmen upprepade gånger.

Flaggor ska placeras längst ner i BoardConfig.mk, under en rubrik på #twrp

För alla enheter måste du instruera TWRP vilket tema som ska användas. TW_THEME-flaggan används istället för den äldre DEVICE_RESOLUTION-flaggan, vilket innebär att TWRP nu använder skalning för att sträcka något tema.

Dina alternativ är: portrait_hdpi, portrait_mdpi, landscape_hdpi, landscape_mdpi och watch_mdpi. För porträttläge kommer du sannolikt att ha hdpi-temat på 720 × 1280 och uppåt, men för liggande enheter går det med 1280 × 720 och uppåt.

Så din bygga flaggavsnitt + temaflagg ska se så här ut:

#twrp

TW_THEME: = portrait_hdpi

Några ytterligare byggflaggor som du vill inkludera i det här avsnittet (krediter till XDA-forum):

RECOVERY_SDCARD_ON_DATA: = true (det här möjliggör korrekt hantering av / data / media på enheter som har den här mappen för lagring (de flesta Honeycomb och enheter som ursprungligen skickades med ICS som Galaxy Nexus). Denna flagga är dock inte nödvändig för dessa typer av enheter. definiera inte denna flagga och inte inkludera några hänvisningar till / sdcard, / internal_sd, / internal_sdcard eller / emmc i ditt fstab, då antar vi automatiskt att enheten använder emulerat lagringsutrymme.)
BOARD_HAS_NO_REAL_SDCARD: = true - inaktiverar saker som SD-kortpartitionering och kan spara lite utrymme om TWRP inte passar i din återställningspatition
TW_NO_BATT_PERCENT: = true - inaktiverar visning av batteriprocenten för enheter som inte stöder det ordentligt
TW_CUSTOM_POWER_BUTTON: = 107 - anpassade kartor strömbrytaren för låsskärmen
TW_NO_REBOOT_BOOTLOADER: = true - tar bort startknappen för omstartsuppladdning från startmenyn
TW_NO_REBOOT_RECOVERY: = true - tar bort återställningsknappen från startmenyn
RECOVERY_TOUCHSCREEN_SWAP_XY: = true - byter kartläggning av beröring mellan X- och Y-axeln
RECOVERY_TOUCHSCREEN_FLIP_Y: = true-flips y axel pekskärmsvärden
RECOVERY_TOUCHSCREEN_FLIP_X: = true-flips x-axel pekskärmsvärden
TWRP_EVENT_LOGGING: = true - möjliggör avkänningshändelse loggning för att hjälpa till att felsöka pekskärmsproblem (lämna inte det här för en släpp - det kommer att fylla din loggfilm väldigt snabbt)
BOARD_HAS_FLIPPED_SCREEN: = true - flips skärmen upp och ner för skärmar som monterades upp och ner

Ytterligare byggflaggor kan hittas genom att skimming via Android.mk-filerna i återställningskällan, men de används vanligtvis inte så det finns ingen anledning att dokumentera dem.

Använda Recovery.Fstab

TWRP 2.5 och högre har stöd för nya recovery.fstab funktioner - särskilt möjligheten att förlänga TWRPs backup / restore funktioner. Du behöver inte lägga till fstab-flaggor, eftersom de flesta partitionerna automatiskt hanteras.

TWRP stöder bara v2 fstabs i version 3.2.0 och högre - i äldre versioner av TWRP måste du använda det gamla formatet fstab. Här är ett exempel på TWRP fstab för en Galaxy S4:

För att maximera kompatibiliteten med ditt specifika byggträd kan du skapa en twrp.fstab och använda PRODUCT_COPY_FILES för att placera i> etc> twrp.fstab.

När TWRP startar och hittar twrp.fstab i ramdisken, kommer den att omdöpa den till> etc> recovery.fstab.bak - i princip ersätter fstab från enheten med TWRP fstab, som utökar kompatibiliteten.

Exempel kod:

PRODUCT_COPY_FILES + = enhet / lge / hammerhead / twrp.fstab: återställning> root> etc> twrp.fstab

FSTAB i TWRP kan innehålla några flaggor för varje partition som anges i fstab.

Dessa flaggor läggs till i slutet av partitionlistan i fstab, separerade med vitt utrymme / mellanslag / flikar. Flaggan påverkar endast den partitionen, men ingen andra. Flaggor separeras av semikolon. Här är några exempelkod:

Så låt oss undersöka det här bit för bit. Flaggan här kommer att ge ett visningsnamn på Micro SDcard. Wipeingui-flaggan gör den här partitionen tillgänglig för att torka i menyn Advanced Wipe. Den flyttbara flaggan indikerar att den här partitionen inte alltid är närvarande, vilket förhindrar att monteringsfel visas.

En komplett lista över flaggor (krediter till TeamWin) :

flyttbar - indikerar att partitionen kanske inte är närvarande så att monteringsfel inte visas under start
lagring - indikerar att partitionen kan användas som lagring som gör partitionen tillgänglig som lagring för säkerhetskopiering, återställning, zip-installationer etc.
settingsstorage - endast en partition ska ställas in som inställningslagring, den här partitionen används som plats för lagring av TWRPs inställningsfil
kanbevisad - indikerar att partitionen kan torkas av back-end-systemet, men får inte anges i GUI för att torka av användaren
userrmrf - överskridar normalformat typ av torkning och tillåter endast partitionen att torkas med kommandot rm -rf
backup = - måste lyckas med lika tecken, så backup = 1 eller backup = 0, 1 indikerar att partitionen kan listas i listan backup / restore medan 0 säkerställer att den här partitionen inte visas i backuplistan.
wipeingui - gör partitionen uppenbar i GUI så att användaren kan välja den för att torka i den avancerade torkmenyn
wipeduringfactoryreset - partitionen torkas under en fabriksåterställning
ignoreblkid - blkid används för att bestämma vilket filsystem som används av TWRP, den här flaggan kommer att leda till att TWRP hoppa över / ignorera resultaten från blkid och använd filsystemet som anges i fstab
retainlayoutversion - orsakar TWRP att behålla filen .layoutversion i / data på enheter som Sony Xperia S vilken typ av användningar / data / media men fortfarande har en separat / sdcard-partition
symlink = - får TWRP att köra ett extra mount-kommando när du monterar partitionen, vanligtvis används med / data / media för att skapa / sdcard
display = - anger ett visningsnamn för partitionen för listning i GUI
storagename = - anger ett lagringsnamn för partitionen för listning i GUI-lagringslistan
backupname = - anger ett säkerhetskopieringsnamn för partitionen för listning i GUI backup / restore list
längd = - brukar användas för att reservera tomt utrymme i slutet av / data-partitionen för att lagra dekrypteringsnyckeln när Android-enhetens fullständiga enhetskryptering är närvarande. Det kan inte leda till att det inte går att kryptera enheten
canencryptbackup = - 1 eller 0 för att aktivera / inaktivera, gör TWRP kryptera säkerhetskopieringen av den här partitionen om användaren väljer kryptering (gäller bara tjärryggningar, inte bilder)
userdataencryptbackup = - 1 eller 0 för att aktivera / inaktivera, gör TWRP endast kryptering av userdata-delen av den här partitionen, vissa subfuldes som / data / app skulle inte krypteras för att spara tid
subpartitionof = - måste efterföljas av likestecknet och partitionens väg är det en delpartition av. En delpartition behandlas som en del av huvudpartitionen, så till exempel TWRP gör automatiskt / datadata en subpartition av / data. Det betyder att / datadata inte kommer att visas i GUI-listorna, men / datadata skulle torkas, säkerhetskopieras, återställas, monteras och avmonteras när som helst som dessa operationer utförs på / data.

Ett bra exempel på användningen av delpartitioner är 3x efs-partitionerna på LG Optimus G:

Detta klumpar alla 3 partitioner till en enda EFS-post i TWRP GUI så att alla tre kan säkerhetskopieras och återställas tillsammans under en enda post.

Med TWRP 3.2.0 och däröver som använder V2 Fstab behöver du inte lägga till några byggflaggor . V2 Fstab-stöd är automatiskt. V2 Fstab stöder också jokertecken (symbolen *) som kan vara användbar för USB OTG och micro-SD-kort med flera partitioner. Du kan också fortsätta använda V1 Fstab-formatet, och det är helt möjligt att använda både V1 och V2-typerna i samma Fstab.

Till exempel, här är en V1 Fstab-linje med ett jokertecken för en USB OTG:

PRO TIPS: Om problemet är med din dator eller en bärbar dator, bör du försöka använda Reimage Plus-programvaran som kan skanna förvaret och ersätta korrupta och saknade filer. Detta fungerar i de flesta fall där problemet uppstått på grund av systemkorruption. Du kan ladda ner Reimage Plus genom att klicka här

Här är en V2 Fstab-linje för samma enhet som uppnår samma resultat:

Dessutom kan du inkludera etc twrp.flags som använder V1 Fstab-formatet, och de kan användas för att komplettera V2 Fstab med TWRP-flaggor, ytterligare partitioner som inte ingår i V2 Fstab eller övergripande inställningar i V2 Fstab.

Till exempel kan en Huawei-enhet ha denna V2-fstab i etc recovery.fstab:

Det kan också innehålla dessa flaggor:

Så här lägger de två första raderna i TWRP.Flags till Boot och Recovery partitionerna, som inte var närvarande i V2 Fstab. Därefter instruerar / cust-linjen i TWRP.flags TWRP så att slutanvändaren kan säkerhetskopiera partitionen (cust) och ge det ett visningsnamn.

Misc-partitionen finns i twrp.flags, och / oeminfo partitionen instruerar TWRP för att också tillåta säkerhetskopiering och ge det ett visningsnamn.

Vi behöver / datalinjen eftersom många Huawei-enheter krypteras, men använder speciella Huawei-binärer - så använder vi Huawei-binärerna automatiskt för att dekryptera enheten automatiskt i återställningsmodus. Så här / / -linjen ska instruera TWRP att använda / dev / block / dm -0, och inte / dev / block / bootdevice / by-name / userdata, som vanligtvis används för korrekt montering.

Slutligen finns / system_image, så att TWRP kommer att innehålla ett alternativ att skapa en systembild i Backup and Restore menyerna.

Den officiella TeamWin githuben bör också innehålla de senaste exemplet träden för enheter som har en officiell TWRP-port. TeamWin github finns här.

När Omni eller CM har synkroniserats, och du har ställt in dina TWRP-flaggor, borde du bygga en källa ./build/envsetup.sh

Och du vill luncha enheten, så du kan göra något som lunch omni_hammerhead.eng.

Efter en lyckad lunch brukar de flesta enheter använda det här kommandot:

Du måste ersätta # i -j # med kärnantalet +1. Så om du har en dubbel kärna är det -j3, kommer en quadcore -j5, etc.Replace # med kärnantalet +1, så om du har en dubbel kärna blir -j3 och en quad-kärna -j5, etc.

Även typiska Samsung-enheter kommer att kräva detta:

Detta beror på att de flesta Samsung-enheter inkluderar återställningen som en extra ramdisk i uppstarten, istället för på en separat återställningspartition (som de flesta andra enheter använder).

Nu borde du ha TWRP sammanställd för din enhet och det fungerar förhoppningsvis i en emulatormiljö. Du bör alltid testa din TWRP-port i en emulatormiljö först, så du riskerar inte att borka enheten.
Hämta den här uppsättningen konfigurationsfiler för en enhet.

Kompilera ett återställningsimage med hjälp av dessa enhetsfiler. I Android SDK, klicka på Verktyg -> Hantera AVD. Klicka på Ny. Ställ in det som följande:

Klicka sedan på OK.

När du har din AVD och ditt återställningsimage kan du starta TWRP i emulatorn genom att bläddra i mappen android-sdk / tools och köra det här kommandot:

Observera att ADB inte fungerar direkt. Omkring 10 till 15 sekunder efter att TWRP slutar starta kommer ADB att komma online. Vi startar ADB via init.rc så även om TWRP inte startar på grund av någon typ av kodfel som du kanske har gjort, borde ADB fortfarande fungera. Njut av!

TWRP och A / B-enheter (krediter till TeamWin):

Från en TWRP-ståndpunkt är A / B-enheter inte mycket annorlunda än vanliga enheter, men utvecklare verkar vara blyga om att arbeta med dessa enheter. Jag kommer att försöka kasta lite ljus på detta ämne och förhoppningsvis kommer detta att fungera som en guide för portning av TWRP till A / B-enheter.

För det första, låt oss förstå vad som är en A / B-enhet och hur det är annorlunda. A / B-enheter har dubbletter av många partitioner på enheten. En A / B-enhet har 2x systempartitioner, 2x boot partitioner, 2x leverantörspartitioner, 2x modem / firmware partitioner, etc. Endast en slits används i taget åt gången. Under tidig start, läste de första stegen i startläsaren lite liten mängd data som kallas BCB eller Bootloader Control Block och bestämmer huruvida A-partitionerna eller B-partitionerna ska startas upp. När en OTA-uppdatering är tillgänglig kopieras data från den aktiva spåret från den inaktiva spåret och patchas / uppdateras. Om du till exempel befinner dig på plats A, skulle din enhet ladda ner uppdateringen och kopiera den befintliga systempartitionen från plats A och patch / uppdatera den med de nya uppdateringarna i plats B. När kopieringen och uppdateringen är klar, BCB uppdateras och enheten startas om med spår B. Nästa gång en uppdatering är tillgänglig kopieras systempartitionen i spår B till spår A och uppdateras, BCB uppdateras och vi startar om till spår A. När du tittar på partitioner på enheten, du ser något så här:

Observera dual boot, system och leverantör partitioner i listan ovan, men bara en userdata partition.

Även om det finns tekniskt inget krav som jag är medveten om, har alla A / B-enheter som skickas hittills inte någon separat återställningspartition. Istället innehåller startbilden återhämtningen i ramdisken. Det viktiga är att veta att startbilden nu också innehåller återhämtningen. För fullständighet är systempartitionen ett fullständigt rotfilsystem. Under uppstarten, om kärnan berättas att starta till återställning, kommer den att extrahera ramdisken i bootpartitionen. Om kärnan inte berättas av startladdaren för att starta till återställning, kommer kärnan att montera den lämpliga systempartitionen (A eller B) eftersom systempartitionen är ett fullständigt rotfilsystem. Det betyder att systempartitionen på dessa enheter är monterad till / i stället för till / system och systempartitionen innehåller alla filer som normalt skulle ha varit i bildbildskärmsbildskärmsdisken och a / system-undermappen.

Ur TWRP-ståndpunkt finns det 3 saker som du måste göra för en A / B-enhet. Först måste du ställa in

Koda:

Slutligen, när du väl kommit in i TWRP, kommer du noga att se till att bootctl hal-info svarar korrekt utan några fel. Vanligtvis kräver bootctl binär ett eget bibliotek eller till och med ett par tjänster för att fungera korrekt. Om bootctl inte fungerar korrekt, kommer du inte heller att kunna byta slitsar inom TWRP korrekt.

Förutom inställningen

Koda:

AB_OTA_UPDATER: = true

du kanske också vill ställa in:

Koda:

BOARD_USES_RECOVERY_AS_BOOT: = true

BOARD_BUILD_SYSTEM_ROOT_IMAGE: = true

Om du ställer in

Koda:

BOARD_USES_RECOVERY_AS_BOOT: = true

då gör återställningsimage inte längre fungerar och istället måste du göra bootimage. Jag rekommenderar inte att du ställer in någon av dessa flaggor för TWRP-bara bygga träd. Dessa flaggor kommer troligen att krävas för utvecklare att bygga fullständiga ROM-skivor för A / B-enheter.

Installera / blinka TWRP på A / B-enheter:

Eftersom alla kända A / B-enheter inte har en separat återställningspartition måste du slutligen flasha TWRP till startpartitionen. På Pixel 1 och 2 använder vi snabbväststart för att tillfälligt starta TWRP utan att blinka TWRP. Vi levererar sedan en blixtlås för att tillåta användare att blinka TWRP till båda slitsarna. Du kan ladda ner en av dessa blixtlås från vår hemsida och uppdatera zip som behövs för att stödja dina enheter. Så småningom lägger vi till verktyg för TWRP så att användarna kan flasha återställningar på dessa enheter utan att behöva använda blixtlås.

Nyligen arbetade jag på Razer Phone. Razer Phone stöder tyvärr inte snabbstart. I stället måste användarna bestämma sin nuvarande aktiva startplats med

Koda:

att komma in i TWRP. En gång i TWRP kan de sedan gå till omstartssidan och byta tillbaka till sin ursprungligen aktiva plats, göra en säkerhetskopia och installera sedan TWRP. Med hjälp av den inaktiva platsen kan användarna få en bra, omodifierad säkerhetskopia av enheten innan de installeras TWRP.

Ytterligare anmärkningar:

Om du vill få TWRP officiellt stöd för din enhet så att den automatiskt kan installeras med TWRP-appen och du verkligen vill göra det så att andra ägare av samma enhet kan ha officiellt TWRP-stöd och det är det fina att göra, måste du skicka följande information till TeamWin:

Enhetskonfigurationsfiler för att kompilera TWRP från källan till din enhet - Omplocka inte en recovery.img för hand, de måste kompilera den från källan.
När TeamWin bygger en kopia av TWRP skickar de den till dig för validering. När du väl har validerat det, kommer TeamWin att bygga en fungerande bild för din enhet och lägga till den i den officiella TWRP-appen.