Sådan DIY Port TWRP til Android

Hovednote inden kompilering: Hvis du tilføjer eller ændrer flag, skal du gøre rent (eller lave clobber) inden kompilering igen, ellers vil dine flagændringer ikke være inkluderet!

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

Boardkonfigurationen skal indeholde arkitektur og platformindstillinger - disse er typisk allerede inkluderet hvis du bruger en andens enhedskonfiguration. Men hvis du oprettede din egen, skal du tilføje dem. Dette skyldes, at uden dem kan genoprettelsesstarten segfault, og det vil bare blinke TeamWin-logoet på din skærm gentagne gange.

Flag skal placeres i bunden af ​​BoardConfig.mk under overskriften #twrp

Til alle enheder, skal du instruere TWRP, hvilket tema der skal bruges. TW_THEME-flag 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. I portrættilstand vil du højst sandsynligt have hdpi-temaet 720 × 1280 og nyere, men for liggende enheder skal du bruge 1280 × 720 og op.

Så dit build-flagafsnit + temaflag skal se sådan ud:

#twrp

TW_THEME: = portræt_hdpi

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

• RECOVERY_SDCARD_ON_DATA: = sandt (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 leveret med ICS som Galaxy Nexus). Dette flag er dog ikke påkrævet for denne type enheder. Hvis du definer ikke dette flag og inkluder heller ingen referencer til / sdcard, / internal_sd, / internal_sdcard eller / emmc i din fstab, så antager vi automatisk, at enheden bruger emuleret lager.)
• BOARD_HAS_NO_REAL_SDCARD: = sand - deaktiverer ting som partitionering af SD-kort og kan spare dig noget plads, hvis TWRP ikke passer i din gendannelsespatition
• TW_NO_BATT_PERCENT: = true - deaktiverer visningen af ​​batteriprocenten for enheder, der ikke understøtter det korrekt
• TW_CUSTOM_POWER_BUTTON: = 107 - brugerdefinerede kort afbryderknappen til låseskærmen
• TW_NO_REBOOT_BOOTLOADER: = true - fjerner reboot-bootloader-knappen fra genstartmenuen
• TW_NO_REBOOT_RECOVERY: = true - fjerner genoprettelsesknap til genstart fra genstartmenuen
• RECOVERY_TOUCHSCREEN_SWAP_XY: = sand - bytter kortlægning af berøringer mellem X- og Y-aksen
• RECOVERY_TOUCHSCREEN_FLIP_Y: = sand - vender y-aksens berøringsskærmsværdier
• RECOVERY_TOUCHSCREEN_FLIP_X: = true - vender x akse berøringsskærmsværdier
• TWRP_EVENT_LOGGING: = sand - aktiverer logning af berøringshændelser for at hjælpe med at debugge problemer med berøringsskærm (lad ikke dette være tilsluttet - det udfylder din logfil meget hurtigt)
• BOARD_HAS_FLIPPED_SCREEN: = sand - vender skærmen på hovedet for skærme, der blev monteret på hovedet

Yderligere buildflag kan findes ved at skimme gennem Android.mk-filerne i gendannelseskilden, men de bruges typisk ikke, så der er ingen mening med at dokumentere dem.

Brug af Recovery.Fstab

TWRP 2.5 og højere har understøttelse af nye recovery.fstab-funktioner - især muligheden for at udvide TWRPs backup / gendannelsesfunktioner. Du behøver ikke tilføje fstab-flag, fordi de fleste partitioner håndteres automatisk.

TWRP understøtter kun v2 fstabs i version 3.2.0 og nyere - 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 build-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, omdøber den den til> etc> recovery.fstab.bak - dybest set erstatter den fstab fra din enhed med TWRP fstab, som udvider kompatibilitet.

Eksempel kode:

PRODUCT_COPY_FILES + = enhed / lge / hammerhead / twrp.fstab: opsving> rod> etc> twrp.fstab

Fstab i TWRP kan indeholde nogle “flag” for hver partition, der er anført i fstab.

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

Så lad os undersøge dette lidt efter lidt. Flagget her vil vise et displaynavn på “Micro SDcard”. Wipeingui-flag gør denne partition tilgængelig til sletning i menuen Advanced Wipe. Det aftagelige flag angiver, at denne partition ikke altid er til stede, hvilket forhindrer, at monteringsfejl vises.

En komplet liste over flag (kreditter til TeamWin) :

• aftagelig - angiver, at partitionen muligvis ikke er til stede, hvilket forhindrer, at monteringsfejl vises under opstart
• opbevaring - angiver, at partitionen kan bruges som lager, der gør partitionen tilgængelig som lager til backup, gendannelse, zip-installationer osv.
• indstillingslagring - kun en partition skal indstilles som indstillingslager, denne partition bruges som placeringen til lagring af TWRPs indstillingsfil
• kanbefugges - angiver, at partitionen kan slettes af back-end-systemet, men muligvis ikke vises i GUI til sletning af brugeren
• brugerrmrf - tilsidesætter den normale formatering af sletning og tillader kun partitionen at blive slettet ved hjælp af kommandoen rm -rf
• backup = - skal efterfølges af ligetegnet, så backup = 1 eller backup = 0, 1 indikerer, at partitionen kan vises på listen over sikkerhedskopier / gendannelser, mens 0 sikrer, at denne partition ikke vises i sikkerhedskopilisten.
• wipeingui - gør, at partitionen vises i GUI'en, så brugeren kan vælge den til sletning i den avancerede sletningsmenu
• tørring af faktorindstilling - partitionen slettes under en fabriksindstilling
• ignoreblkid - blkid bruges til at bestemme, hvilket filsystem der bruges af TWRP, dette flag får TWRP til at springe over / ignorere resultaterne af blkid og kun bruge det filsystem, der er angivet i fstab
• retainlayoutversion - får TWRP til at gemme .layoutversion-filen i / data på enheder som Sony Xperia S, som slags bruger / data / medier, men stadig har en separat / sdcard-partition
• symlink = - får TWRP til at køre en ekstra monteringskommando, når partitionen monteres, normalt brugt med / data / media til at oprette / sdcard
• Skærm = - indstiller et visningsnavn for den partition, der skal vises i GUI
• lagernavn = - indstiller et lagernavn for partitionen til notering på GUI-lagringslisten
• backupnavn = - indstiller et backupnavn for partitionen, der skal vises på GUI-backup / gendannelseslisten
  længde = - bruges normalt til at reservere tom plads i slutningen af ​​/ datapartitionen til lagring af dekrypteringsnøglen, når Android's fulde enhedskryptering er til stede, hvis du ikke indstiller dette, kan det føre til manglende evne til at kryptere enheden
• canencryptbackup = - 1 eller 0 for at aktivere / deaktivere, får TWRP til at kryptere sikkerhedskopien af ​​denne partition, hvis brugeren vælger kryptering (gælder kun tjærebackups, ikke billeder)
• userdataencryptbackup = - 1 eller 0 for at aktivere / deaktivere, gør TWRP kun til at kryptere userdata-delen af ​​denne partition, visse subfuldes som / data / app vil ikke blive krypteret for at spare tid
• underopdeling af = - skal efterfølges af ligetegnet og stien til den partition, det er en underopdeling af. En underopdeling behandles som “del” af hovedpartitionen, for eksempel gør TWRP automatisk / datadata til en underopdeling af / data. Dette betyder, at / datadata ikke vises i GUI-listerne, men / datadata slettes, sikkerhedskopieres, gendannes, monteres og afmonteres når som helst disse operationer udføres på / data.

Et godt eksempel på brugen af ​​underpartitioner er de 3x efs-partitioner på LG Optimus G:

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

Med TWRP 3.2.0 og derover, der bruger V2 Fstab, kan du behøver 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 til USB OTG og micro-SD-kort med flere partitioner. Du kan også fortsætte med at bruge V1 Fstab-formatet, og det er fuldt ud muligt at bruge både V1- og V2-typer i samme Fstab.

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

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

Derudover kan du medtage 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 muligvis have denne V2 fstab i etc opsving. Fstab:

Det kan også have disse flag inkluderet:

Så her tilføjer de to første linjer i TWRP.Flags Boot- og Recovery-partitionerne, som ikke var til stede i V2 Fstab. Derefter vil / cust-linjen i TWRP.flags instruere TWRP om at tillade slutbrugeren at tage backup af (cust) -partitionen og give den et displaynavn.

Partitionen / misc findes i twrp.flags, og / oeminfo-partitionen instruerer TWRP om også at tillade sikkerhedskopiering og give den et displaynavn.

Vi har brug for / datalinjen, fordi mange Huawei-enheder er krypteret, men bruger specielle Huawei-binære filer - derfor bruger vi Huawei-binære filer til automatisk at dekryptere enheden i gendannelsestilstand. Så her vil / datalinjen instruere TWRP om at bruge / dev / block / dm -0, og ikke / dev / block / bootdevice / by-name / userdata, som typisk bruges til 'korrekt' montering '.

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

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

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

Og du vil gerne 'frokost' 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 dobbeltkerne, er den –j3, en quadcore er –j5 osv. Udskift # med kernetællingen +1, så hvis du har en dobbeltkerne, er det -j3 og en firekærne bliver til -j5 osv.

Typiske Samsung-enheder kræver også dette:

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

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

Kompilér et gendannelsesbillede ved hjælp af disse enhedsfiler. I Android SDK skal du klikke på Værktøjer -> Administrer AVD'er. Klik på Ny. Indstil det som følger:

Klik derefter på OK.

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

Bemærk, at ADB ikke fungerer med det samme. Cirka 10 til 15 sekunder efter TWRP er startet, kommer ADB online. Vi starter ADB via init.rc, så selvom TWRP ikke starter på grund af en slags kodefejl, som du muligvis har lavet, skal ADB stadig fungere. God fornøjelse!

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

Fra et TWRP-synspunkt adskiller A / B-enheder sig ikke meget fra almindelige enheder, men udviklere synes at være genert over at arbejde på disse enheder. Jeg vil prøve at kaste lys over dette emne, og forhåbentlig vil dette tjene som en guide til at porte TWRP til A / B-enheder.

Lad os først forstå, hvad der er en A / B-enhed, og hvordan den er anderledes. A / B-enheder har duplikater af mange partitioner på enheden. En A / B-enhed har 2x systempartitioner, 2x bootpartitioner, 2x leverandørpartitioner, 2x modem / firmwarepartitioner osv. Kun en slot er i brug ad gangen. Under den tidlige opstart læser bootloaderens første trin nogle små mængder data kaldet BCB eller Bootloader Control Block og beslutter, om A-partitionerne eller B-partitionerne skal startes. Når en OTA-opdatering er tilgængelig, kopieres dataene fra det aktive slot fra det inaktive slot og patches / opdateres. For eksempel, hvis du i øjeblikket er på slot A, vil din enhed downloade opdateringen og kopiere den eksisterende systempartition fra slot A og patch / opdatere den med de nye opdateringer til slot B. Når kopiering og opdatering er afsluttet, er BCB opdateres, og enheden genstarter ved hjælp af 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 partitioner vises på enheden, ser du noget som dette:

Bemærk dual-boot-, system- og leverandørpartitionerne i listen ovenfor, men kun en userdata-partition.

Selvom der teknisk set ikke er noget krav, som jeg er opmærksom på, har alle hidtil sendte A / B-enheder ingen separat gendannelsespartition. I stedet indeholder boot-billedet gendannelsen i sin ramdisk. Det vigtige er at vide, at boot-image nu også indeholder opsvinget. For fuldstændighed er systempartitionen et fuldt rodfilsystem. Hvis kernen bliver bedt om at starte til gendannelse under opstart, vil den udtrække ramdisk i bootpartitionen. Hvis kernen ikke får besked fra bootloaderen om at starte til gendannelse, vil kernen montere den relevante systempartition (A eller B), fordi systempartitionen er et fuldt rodfilsystem. Dette betyder, at systempartitionen på disse enheder er monteret på / i stedet for til / system, og systempartitionen indeholder alle de filer, der normalt ville have været i boot image ramdisk og en / system undermappe.

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 først er kommet ind i TWRP, vil du sandsynligvis sørge for, at bootctl hal-info reagerer korrekt uden fejl. Normalt kræver bootctl binært et proprietært bibliotek eller endda et par tjenester for at fungere korrekt. Hvis bootctl ikke fungerer korrekt, kan du heller ikke skifte slots inden for TWRP korrekt.

Ud over indstilling

Kode:

AB_OTA_UPDATER: = sandt

du vil muligvis også indstille:

Kode:

BOARD_USES_RECOVERY_AS_BOOT: = sandt

BOARD_BUILD_SYSTEM_ROOT_IMAGE: = sandt

Hvis du indstiller

Kode:

BOARD_USES_RECOVERY_AS_BOOT: = sandt

lav derefter recoveryimage fungerer ikke længere, og i stedet bliver du nødt til at lave bootimage. Jeg anbefaler ikke at indstille nogen af ​​disse flag til træer, der kun bygger TWRP. Disse flag vil sandsynligvis være påkrævet for udviklere, der bygger fulde 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, bliver du til sidst nødt til at blinke TWRP til bootpartitionen. På Pixel 1 og 2 bruger vi hurtigstart boot til midlertidigt at starte TWRP uden at blinke TWRP. Vi leverer derefter en zip, så brugerne kan blinke TWRP til begge slots. Du kan downloade en af ​​disse lynlåse fra vores websted og opdatere zip'en efter behov 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-telefonen understøtter desværre ikke fastboot-opstart. I stedet skal brugerne bestemme deres aktuelt aktive boot-slot ved hjælp af

Kode:

at komme ind i TWRP. Når de er i TWRP, kan de derefter gå til reboot-siden og skifte tilbage til deres oprindeligt aktive slot, lave en sikkerhedskopi og derefter installere TWRP. Brug af den inaktive slot giver brugerne mulighed for at få en god, umodificeret backup af deres enhed, før de installerer TWRP.

Ekstra Noter:

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

1. Enhedskonfigurationsfiler til kompilering af TWRP fra kilde til din enhed - ompak ikke ikke et opsving. img med hånden , de har brug for at kompilere det fra kilden.
2. Når TeamWin har bygget en kopi af TWRP, sender de den til validering - når du har valideret den, vil TeamWin oprette et arbejdsbillede til din enhed og føje det til den officielle TWRP-app.