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

Stora anmärkningar innan du kompilerar: Om du lägger till eller byter flaggor måste du göra rent (eller göra clobber) innan du kompilerar om, annars kommer inte dina flaggändringar att inkluderas!

När du har TWRP-källkoden måste vi ändra några av byggflaggorna för din specifika enhet. Hitta BoardConfig.mk för din enhet - vanligtvis hittar du den i enheter / tillverkare / kodnamn (till exempel enheter / lge / hammerhead / BoardConfig.mk)

Tavelkonfigurationen måste inkludera 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ällningsstarten segfault och det kommer bara att blinka TeamWin-logotypen på skärmen upprepade gånger.

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

För Allt enheter måste du instruera TWRP vilket tema du ska använda. 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 ut vilket tema som helst.

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

Så ditt byggflaggavsnitt + temaflagg ska se ut så här:

#twrp

TW_THEME: = porträtt_hdpi

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

• RECOVERY_SDCARD_ON_DATA: = true (detta 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 levererades med ICS som Galaxy Nexus) Denna flagga krävs dock inte för dessa typer av enheter. Om du definiera inte den här flaggan och ta heller inte med några referenser till / sdcard, / internal_sd, / internal_sdcard eller / emmc i din fstab, då antar vi automatiskt att enheten använder emulerad lagring.)
• BOARD_HAS_NO_REAL_SDCARD: = true - inaktiverar saker som partitionering av SD-kort och kan spara lite utrymme om TWRP inte passar i din återställningspatition
• TW_NO_BATT_PERCENT: = true - inaktiverar visningen av batteriprocenten för enheter som inte stöder det ordentligt
• TW_CUSTOM_POWER_BUTTON: = 107 - anpassade kartor för strömbrytaren för låsskärmen
• TW_NO_REBOOT_BOOTLOADER: = true - tar bort startladdningsknappen från omstartsmenyn
• TW_NO_REBOOT_RECOVERY: = true - tar bort återställningsknappen från omstartsmenyn
• RECOVERY_TOUCHSCREEN_SWAP_XY: = true - byter kartläggning av beröringar mellan X- och Y-axeln
• RECOVERY_TOUCHSCREEN_FLIP_Y: = true - vänder y-axelns pekskärmsvärden
• RECOVERY_TOUCHSCREEN_FLIP_X: = true - vänder x-axelns pekskärmsvärden
• TWRP_EVENT_LOGGING: = true - möjliggör loggning av pekhändelser för att hjälpa till att felsöka problem med pekskärmen (lämna inte det här för en release - det fyller i din loggfil mycket snabbt)
• BOARD_HAS_FLIPPED_SCREEN: = true - vänder skärmen upp och ner för skärmar som var monterade upp och ner

Ytterligare build-flaggor kan hittas genom att bläddra igenom Android.mk-filerna i återställningskällan, men de används vanligtvis inte så det finns ingen mening med 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 utöka TWRP: s säkerhetskopierings- / återställningsfunktioner. Du behöver inte lägga till fstab-flaggor, eftersom de flesta partitioner hanteras automatiskt.

TWRP stöder endast v2 fstabs i version 3.2.0 och senare - i äldre versioner av TWRP måste du använda det gamla formatet av 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 byta namn på den till> etc> recovery.fstab.bak - i grunden ersätter den fstab från din enhet med TWRP fstab, vilket utökar kompatibilitet.

Exempelkod:

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 till slutet av partitionsförteckningen i fstab, avgränsad av mellanslag / mellanslag / flikar. Flaggan påverkar bara den partitionen, men inga andra. Flaggor är åtskilda av semikolon. Här är en exempelkod:

Så låt oss undersöka detta bit för bit. Flaggan här ger ett visningsnamn “Micro SDcard”. Wipeingui-flaggan gör denna partition tillgänglig för torkning i menyn Advanced Wipe. Den avtagbara flaggan indikerar att den här partitionen inte alltid finns, vilket förhindrar att monteringsfel visas.

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

• avtagbar - indikerar att partitionen kanske inte är närvarande och förhindrar att monteringsfel 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, zipinstallationer etc.
• inställningar lagring - endast en partition ska ställas in som inställningslager, den här partitionen används som plats för lagring av TWRP: s inställningsfil
• kan förväxlas - indikerar att partitionen kan torkas av back-end-systemet, men kanske inte listas i GUI för torkning av användaren
• userrmrf - åsidosätter den normala typen av torkning och tillåter bara att partitionen rensas med kommandot rm -rf
• backup = - måste följas av likhetstecknet, så backup = 1 eller backup = 0, 1 indikerar att partitionen kan listas i säkerhetskopierings- / återställningslistan medan 0 säkerställer att denna partition inte kommer att visas i säkerhetskopieringslistan.
• wipeingui - gör att partitionen visas i GUI så att användaren kan välja den för att radera i den avancerade rensningsmenyn
• torkningfaktor återställs - 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 få TWRP att hoppa över / ignorera resultaten av blkid och endast använda filsystemet som anges i fstab
• retainlayoutversion - gör att TWRP behåller .layoutversion-filen i / data på enheter som Sony Xperia S som använder / data / media men ändå har en separat / sdcard-partition
• symlink = - får TWRP att köra ett extra monteringskommando vid montering av partitionen, som vanligtvis används med / data / media för att skapa / sdcard
• visa = - anger ett visningsnamn för partitionen för listning i GUI
• lagringsnamn = - anger ett lagringsnamn för partitionen för listning i GUI-lagringslistan
• backupnamn = - ställer in ett säkerhetskopieringsnamn för partitionen för listning i GUI-säkerhetskopierings- / återställningslistan
  längd = - används vanligtvis för att reservera tomt utrymme i slutet av / datapartitionen för lagring av dekrypteringsnyckeln när Androids fullständiga enhetskryptering är närvarande, om du inte ställer in detta kan det leda till oförmåga att kryptera enheten
• canencryptbackup = - 1 eller 0 för att aktivera / inaktivera, gör att TWRP krypterar säkerhetskopian av denna partition om användaren väljer kryptering (gäller endast tjärbackup, inte bilder)
• userdataencryptbackup = - 1 eller 0 för att aktivera / inaktivera, gör att TWRP endast krypterar datadelen av denna partition, vissa subfuldes som / data / app krypteras inte för att spara tid
• delning av = - måste efterföljas av likhetstecknet och partitionens väg det är en underdelning av. En underdelning behandlas som ”del” av huvudpartitionen så till exempel gör TWRP automatiskt / datadata till en underdelning av / data. Detta innebär att / datadata inte kommer att visas i GUI-listorna, men / datadata torkas, säkerhetskopieras, återställs, monteras och avmonteras när som helst dessa operationer utförs på / data.

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

Detta klumpar ihop alla tre partitionerna 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 högre som använder V2 Fstab, du behöver inte lägga till några build-flaggor . V2 Fstab-stöd är automatiskt. V2 Fstab stöder också jokertecken (* -symbolen) vilket kan vara användbart för USB OTG och micro-SD-kort med flera partitioner. Du kan också fortsätta använda V1 Fstab-formatet, och det är fullt möjligt att använda både V1- och V2-typer i samma Fstab.

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

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-format, 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-återställningen. Fstab:

Det kan också ha följande flaggor inkluderade:

Så här kommer de två första raderna i TWRP.Flags att lägga till Boot och Recovery-partitionerna, vilka inte var närvarande i V2 Fstab. Därefter kommer / cust-raden i TWRP.flags att instruera TWRP att tillåta slutanvändaren att säkerhetskopiera (cust) -partitionen och ge den ett visningsnamn.

Partitionen / misc finns i twrp.flags, och / oeminfo-partitionen instruerar TWRP att också tillåta säkerhetskopiering och ge den ett visningsnamn.

Vi behöver / datalinjen eftersom många Huawei-enheter är krypterade, men använder speciella Huawei-binärer - alltså använder vi Huawei-binärerna för att dekryptera enheten automatiskt i återställningsläge. Så här kommer / dataraden att instruera TWRP att använda / dev / block / dm -0, och inte / dev / block / bootdevice / by-name / userdata, vilket vanligtvis används för 'korrekt' montering '.

Slutligen finns / system_image, så att TWRP kommer att inkludera ett alternativ för att skapa en systemavbildning i menyerna Backup och Restore.

Den officiella TeamWin github bör också innehålla de senaste exemplen på enhetsträd 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 ska du bygga en källa ./build/envsetup.sh

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

Efter en framgångsrik lunch använder de flesta enheter det här kommandot:

Du måste ersätta # in –j # med kärnantalet +1. Så om du har en dubbel kärna är den –j3, en fyrkärna blir –j5, etc. Byt ut # med kärnantalet +1, så om du har en dubbel kärna blir det -j3 och en fyrkärna blir -j5, etc.

Typiska Samsung-enheter kräver också detta:

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

Nu bör du ha TWRP sammanställt för din enhet och förhoppningsvis fungerar den i en emulatormiljö. Du bör alltid testa din TWRP-port i en emulatormiljö först, så att du inte riskerar att borka din enhet.
Ladda ner den här uppsättningen av enhetens konfigurationsfiler.

Kompilera en återställningsbild med dessa enhetsfiler. I Android SDK klickar du på Verktyg -> Hantera AVD: er. Klicka på Ny. Ställ in det enligt följande:

Klicka sedan på OK.

När du väl har din AVD och din återställningsbild kan du starta TWRP i emulatorn genom att bläddra till din Android-sdk / tools-mapp och köra det här kommandot:

Observera att ADB inte fungerar direkt. Cirka 10 till 15 sekunder efter att TWRP har startat kommer ADB att gå online. Vi startar ADB via init.rc så även om TWRP inte startar på grund av något slags kodfel som du kan ha gjort, bör ADB fortfarande fungera. Njut av!

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

Ur TWRP-synvinkel skiljer sig A / B-enheter inte mycket från vanliga enheter, men utvecklare verkar vara blyga för att arbeta på dessa enheter. Jag ska försöka belysa detta ämne och förhoppningsvis kommer detta att fungera som en guide för att portra TWRP till A / B-enheter.

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

Observera dubbla start-, system- och leverantörspartitioner i listan ovan, men bara en användardatapartition.

Även om det tekniskt inte finns något krav som jag känner till har alla A / B-enheter som hittills levererats ingen separat återställningspartition. Istället innehåller startbilden återställningen i sin ramdisk. Det viktiga är att veta att startavbildningen nu också innehåller återställningen. För fullständighet är systempartitionen ett fullständigt rotfilsystem. Om kärnan uppmanas att starta för återställning under start, kommer den att extrahera ramdisken i startpartitionen. Om kärnan inte uppmanas av bootloadern att starta för återställning, kommer kärnan att montera rätt systempartition (A eller B) eftersom systempartitionen är ett fullständigt rotfilsystem. Detta innebär att systempartitionen på dessa enheter är monterad på / istället för till / system och att systempartitionen innehåller alla filer som normalt skulle ha funnits i startavbildningsramdisken och en / systemundermapp.

Ur en TWRP-synpunkt finns det tre saker 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 har kommit till TWRP, kommer du förmodligen att se till att bootctl hal-info svarar korrekt utan några fel. Vanligtvis kräver bootctl binärt 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 platser inom TWRP korrekt.

Förutom inställningen

Koda:

AB_OTA_UPDATER: = sant

du kanske också vill ställa in:

Koda:

BOARD_USES_RECOVERY_AS_BOOT: = sant

BOARD_BUILD_SYSTEM_ROOT_IMAGE: = sant

Om du ställer in

Koda:

BOARD_USES_RECOVERY_AS_BOOT: = sant

gör sedan recoveryimage fungerar inte längre 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-byggda träd. Dessa flaggor kommer troligen att krävas för utvecklare som bygger fulla 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 så småningom blinka TWRP till startpartitionen. På Pixel 1 och 2 använder vi snabbstart för att temporärt starta TWRP utan att blinka TWRP. Vi levererar sedan en zip för att tillåta användare att blinka TWRP till båda platserna. Du kan ladda ner en av dessa dragkedjor från vår webbplats och uppdatera zip-filen efter behov för att stödja dina enheter. Så småningom kommer vi att lägga till verktyg i TWRP så att användare 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. Istället måste användarna bestämma sin för närvarande aktiva startplats med

Koda:

för att komma in i TWRP. En gång i TWRP kan de sedan gå till omstartsidan och byta tillbaka till sin ursprungligen aktiva plats, göra en säkerhetskopia och sedan installera TWRP. Genom att använda den inaktiva platsen kan användare få en bra, omodifierad säkerhetskopia av sin enhet innan de installerar TWRP.

Ytterligare anmärkningar:

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

1. Enhetskonfigurationsfiler för att kompilera TWRP från källan för din enhet - packa inte om en återställning. img för hand måste de sammanställa det från källan.
2. När TeamWin har byggt en kopia av TWRP skickar de den till dig för validering - när du väl har validerat den kommer TeamWin att bygga en arbetsbild för din enhet och lägga till den i den officiella TWRP-appen.