Root er nu tilgængelig til Google Pixel og Pixel XL: Her er, hvad vi har fundet

click fraud protection

Google Pixel og Pixel har nu rod, takket være XDA Senior Developer Chainfire! Gå over for at vide mere om, hvordan du kan roote din pixel!

Denne metode er forældet og virker muligvis ikke. Besøg vores Google Pixel- og Pixel XL-fora for at få de seneste root-metoder.

Som lovet, systemløs rod til Google Pixel og Pixel XL er nu tilgængelig. XDA Senior anerkendt udvikler Kædebålarbejdede på root til Google Pixel telefon, der kører Android 7.1 Nougat de sidste par dage, og han har nået et stadie i sin udvikling, hvor han nu er komfortabel nok til at dele sit arbejde med fællesskabet.

Rootadgang til Google Pixel og Google Pixel XL er tilgængelig ved at installere SuperSU 2,78 SR2, som muliggør su få adgang uden at røre ved noget i systempartitionen og tillade, at dm-verity kan skiftes. Før du kan roote din enhed, skal du først have din bootloader låst op. Det første trin i at låse din bootloader op er at downloade adb og fastboot binære filer (vi anbefaler at gribe Minimal ADB & Fastboot fra vores fora) og derefter installere den relevante Google USB-driver til din maskine.

Hvis du har købt din Pixel-enhed direkte fra Google, behøver du kun udstede en fastboot blinkende oplåsning kommando efterfulgt af fastboot oem oplåsning. Hvis du har købt din Pixel fra Verizon eller EE, skal du gøre det lås din bootloader op gennem dePixel8-værktøjet. Men skynd dig, for SunShine-udviklerne har nævnt, at deres bootloader-oplåsningsudnyttelse kan blive rettet i den kommende sikkerhedsopdatering fra november!


Sådan installeres SuperSU på din Pixel

Som Chainfire nævner i sit Google+ indlæg, skal du først downloade boot-to-root billeder til Pixel eller Pixel XL fra hans hjemmeside. Du kan Klik her for at downloade zip'en til Google Pixel, eller Klik her for at downloade zip'en til Google Pixel XL. Efter at have downloadet zip, skal du fastboot boot det boot-to-root billede, LADE VÆRE MEDfastboot flash billedet! Med andre ord, den eneste kommando, du skal bruge til de to enheder, er følgende:

fastbootbootboot-to-root.img

Vent et par minutter, og efter et par genstarter vil du blive startet op med fuld root-adgang. Yay!


Øjeblikkelig brug af root-adgang

Forresten, udover den sædvanlige funktionalitet, som root-adgang skulle bringe, er vi gået videre og testet et par ting, som vi vidste, at I alle ville være interesserede i. Først op, kan du bringe Google Now on Tap tilbage? Svaret er Ja! Alt du skal gøre er at redigere bygge.prop med følgende ændring, genstart og ryd Google App-data, og du vil ikke længere blive mødt med Google Assistant.

Lave om

ro.opa.eligible_device=true

til

ro.opa.eligible_device=<strong>falsestrong>

Hvad med en anden almindeligt skjult funktion: dobbelttryk for at vågne? Vi har kigget rundt efter den skjulte skifte og har opdaget, hvad der ser ud til at være det.

sailfish:/sys/devices # echo 1 > ./soc/7577000.i2c/i2c-3/3-0020/input/input3/wake_gesture

Desværre, da vi ændrede værdien, så det ikke ud til at holde fast. Indtil videre ser det ud til, at du bliver nødt til at flashe en brugerdefineret kerne som f.eks ElementalX for at få d2tw til at virke.

Nogle andre ting, vi har testet, omfatter, om Titanium Backup virker eller ej (det gør det), Bedre batteristatistik (arbejder), Substratum/Layers Temaer (ser ud til at have nogle problemer), og annonceblokering (fejler). Ad-away virker ikke i øjeblikket, fordi /system ikke kan monteres read-write som standard, så vi bliver nødt til at vente, indtil TWRP er tilgængelig, før vi kan flashe systemløs løsning til Ad-Away. Og ja, vi har allerede prøvet at bruge FlashFire at flashe Ad-Away-enableren til systemløs rod, men det ser heller ikke ud til at virke på nuværende tidspunkt.

sailfish:/sys/devices # mount -o rw, remount /system
mount: '/system' not in /proc/mounts

Opdatering: Chainfire har bekræftet, at FlashFire og andre apps skal opdateres, før de kan bruges. Se nedenfor for flere detaljer.

Opdatering 2: Chainfire har sendt os en besked med en løsning for at få AdAway til at fungere, indtil appen selv er opdateret. Se tillægget i slutningen af ​​artiklen.

Her er nogle skærmbilleder, der viser, at Titanium Backup fungerer. Så hvis du kommer fra en anden enhed, og du gerne vil gendanne alle dine sikkerhedskopierede apps, kan du være sikker på, at alle dine appdata nu vil blive gendannet.

Vi fortsætter med at dykke dybt ned i vores Pixel-enheder for at se, hvad vi kan skifte til. Hvilken "Pixel-eksklusiv"-funktion bliver den næste, der falder?


"Kampen" for at opnå rod

Chainfire er ret omhyggelig, når det kommer til udgivelsesnoter. Når du er udvikleren, og giver titusindvis af brugere en metode til at opnå root-adgang, gør det mening at være så gennemsigtig som muligt, så du ikke står over for en horde af forvirrede brugere, der undrer sig over, hvorfor noget er det gået i stykker. Mens hans Twitter-konto (@ChainfireXDA) er reserveret mere til korte meddelelser, Chainfire har en tendens til at poste meget velkomne, lange forklaringer på hans Google+ konto. Denne gang er ikke anderledes.

Først og fremmest forklarer Chainfire, hvilke ændringer der blev foretaget på de to Pixel-telefoner, som han skulle omgås for at opnå root-adgang. Især Chainfire beskriver først det nye partitionslayout på Pixel-enhederne.

Nyt partitionslayout (Pixel og sandsynligvis mange fremtidige enheder):

- Der er to af flere Android-partitioner, boot, system, leverandør

- Gendannelses- og cache-partitionerne er væk

- Roden / biblioteket til Android er nu en del af systempartitionen i stedet for bootpartitionen (initramfs)

- Gendannelse er nu inde i det normale opstartsbillede og bruger dets initramfs (som plejede at blive brugt af Android)

Som vi tidligere har dækket, er disse partitionsændringer på de to Pixel-telefoner ville kræver nogle ændringer af den nuværende rodmetode. Chainfire har bekræftet, at disse ændringer af /systempartitionen krævede en anden tilgang, en der kan involvere ændring af kernen.

Med Pixels nye partitionslayout er de filer, vi ændrede, flyttet til systempartitionen (det vi oprindeligt tænkte på som /system er nu en undermappe inde i den partitions filsystem). Så kunne vi så bare ændre systempartitionen, der indeholder alle disse filer, og lade opstartsbilledet være i fred? Selvom jeg personligt foretrækker at lave ændringen af ​​opstartsbilledet og lade systemet være i fred, kunne det omvendte potentielt være en løsning, og jeg ved, at nogle tekniske brugere endda ville foretrække det.

Jeg kunne dog ikke få dette til at virke. Opstartsindlæseren sender faktisk information til kernen (som findes i opstartsbilledet). force-aktiveret dm-verity (som håndhæver systempartitionens integritet), som vi ikke kan opsnappe eller ændre uden (Trommehvirvel) ændre boot-billedet. Min første succesfulde rod af Pixel blev gjort på den måde - ved at ændre begge (billedet, der blev lagt op tidligere, er fra dette forsøg).

Med andre ord, der er ingen måde at deaktivere dm-verity uden en ændring af kernen, som vi havde mistanke om. Fordi kernen er force-aktiverende dm-verity, var Chainfire nødt til at ændre kernen lidt for at forhindre dm-verity i at forhindre ændringer i systempartitionen. Heldigvis opdagede Chainfire dog, at hans modifikation kun kræver en lille kerne binær patch, men ikke en fuld kerne-rekompilering. Derfor skulle hans løsning forblive en generisk løsning til Android 7.1-enheder med et A/B-partitionsskema.

For at forklare denne nye rodmetode mere detaljeret, opnår Chainfire systemløs rod ved at lave kernel bruge boot-billedets initramfs som dets rodmappe, snarere end noget fra systemet skillevæg. For at gøre det importeres indholdet af rodbiblioteket i systempartitionen til opstartsbilledet, hvilket gør det muligt at ændre disse filer uden at skulle ændre nogen systemfiler. Systempartitionen er monteret til /system_root og /system selv sim-linket til /system_root/system. Og til sidst ændrer hans kernepatch kernen, så den ignorerer kommandoen sendt fra bootloaderen, som normalt ville håndhæve dm-verity.

Der er dog nogle ret trivielle problemer introduceret med denne nye metode. Visse apps, såsom FlashFire eller AdAway (som vi begge har vist ikke virker) forventer, at systempartitionen monteres som /system, ikke /system_root, og skal opdateres i overensstemmelse hermed. Selvom du kan prøve at genmontere systemet som sådan

mount -o rw, remount /system_root

Hvilket skulle give dig mulighed for at skrive til /system. Vi har endnu ikke testet, hvilke root-apps der fikser, men du er fri til at teste det selv. Endelig er Chainfire usikker på om skjul vil arbejde med denne nye rooting-ordning, men han siger, at han vil fortsætte med at lede efter en løsning.


For at downloade SuperSU til Google Pixel-telefonerne skal du gå over til XDA forum tråd. En stor tak til Chainfire for at bringe rod over til enhederne! Lad Tweaking-spillene begynde!

Besøg SuperSU XDA-underforumet!

Denne historie er under udvikling og vil blive opdateret, efterhånden som vi modtager ny information. En Google Pixel blev ofret ved tilblivelsen af ​​denne artikel. RIP Jeffs data.


Tillæg #1: Midlertidig rettelse til AdAway

Download AdAway v3.1.2 fra vores fora, og brug derefter enten a terminal emulator eller ADB shell for at indtaste følgende kommando:

mkdir /su/etc; cp /system/etc/hosts /su/etc/hosts; echo "#!/su/bin/sush\nmount -o bind /su/etc/hosts /system/etc/hosts" > /su/su.d/50adaway; chmod 0700 /su/su.d/50adaway

Genstart, og du bør have systemdækkende annonceblokering.