Google Pixel și Pixel au acum root, prin amabilitatea XDA Senior Developer Chainfire! Mergeți aici pentru a afla mai multe despre cum vă puteți roota pixelul!
Această metodă este depășită și este posibil să nu funcționeze. Vă rugăm să vizitați forumurile noastre Google Pixel și Pixel XL pentru cele mai recente metode de root.
După cum am promis, rădăcină fără sistem pentru Google Pixel și Pixel XL este acum disponibil. Dezvoltator recunoscut senior XDA Lanț de foclucra la root pentru Google Pixel telefon care rulează Android 7.1 Nougat în ultimele zile și a ajuns la o etapă în dezvoltarea sa în care acum se simte suficient de confortabil să-și împărtășească munca cu comunitatea.
Accesul root pentru Google Pixel și Google Pixel XL este disponibil prin instalarea SuperSU 2,78 SR2, care permite su accesați fără a atinge nimic din partiția de sistem și permițând comutarea dm-verity. Înainte de a vă putea roota dispozitivul, va trebui mai întâi să aveți bootloader-ul deblocat. Primul pas în deblocarea bootloader-ului este să descărcați binarele adb și fastboot (recomandăm să apucați
ADB minim și Fastboot de pe forumurile noastre) și apoi instalarea corespunzătoare Driver USB Google pentru mașina dvs.Dacă v-ați achiziționat dispozitivul Pixel direct de la Google, atunci trebuie doar să emiteți a deblocare intermitent fastboot comanda urmata de deblocare OEM fastboot. În cazul în care ați achiziționat Pixel de la Verizon sau EE, ar trebui deblocați încărcătorul de pornire prin instrumentul dePixel8. Grăbește-te însă, deoarece dezvoltatorii SunShine au menționat că exploit-ul lor de deblocare a încărcării de pornire poate fi corectat în următoarea actualizare de securitate din noiembrie!
Cum se instalează SuperSU pe Pixel
După cum menționează Chainfire în postarea sa pe Google+, mai întâi va trebui să descărcați boot-to-root imagini pentru Pixel sau Pixel XL de pe site-ul său. Puteți click aici pentru a descărca codul zip pentru Google Pixel sau click aici pentru a descărca codul zip pentru Google Pixel XL. După descărcarea zip-ului, trebuie boot boot rapid cel boot-to-root imagine, NU FACEfastboot flash imaginea! Cu alte cuvinte, singura comandă de care veți avea nevoie pentru cele două dispozitive este următoarea:
fastbootbootboot-to-root.imgAșteptați câteva minute și, după câteva reporniri, veți fi pornit cu acces complet root. Yay!
Utilizări imediate ale accesului rădăcină
Apropo, pe lângă funcționalitatea obișnuită pe care ar trebui să o aducă accesul la root, am continuat și am testat câteva lucruri de care știam că veți fi interesați pe toți. În primul rând, poți aduce înapoi Google Now on Tap? Raspunsul este da! Tot ce trebuie să faci este să editezi construi.prop cu următoarea modificare, reporniți și ștergeți datele aplicației Google și nu veți mai fi întâmpinat cu Asistentul Google.
Schimbare
ro.opa.eligible_device=truela
ro.opa.eligible_device=<strong>falsestrong>Ce zici de o altă caracteristică ascunsă în mod obișnuit: atingeți de două ori pentru a trezi? Ne-am uitat în jur după comutatorul ascuns și am descoperit ce pare a fi acesta.
sailfish:/sys/devices # echo 1 > ./soc/7577000.i2c/i2c-3/3-0020/input/input3/wake_gestureDin păcate, când am schimbat valoarea, nu părea să se mențină. Pentru moment, se pare că va trebui să flash un nucleu personalizat, cum ar fi ElementalX pentru a pune d2tw să funcționeze.
Alte lucruri pe care le-am testat includ dacă Titanium Backup funcționează sau nu (o face), Statistici mai bune ale bateriei (lucrări), Teme de substrat/straturi (pare să aibă unele probleme), și blocarea anunțurilor (eșuează). Ad-away nu funcționează în prezent, deoarece /sistemul nu poate fi montat în mod implicit pentru citire-scriere, așa că va trebui să așteptăm până când TWRP este disponibil înainte de a putea flash soluție fără sistem pentru Ad-Away. Și da, am încercat deja să folosim FlashFire să afișeze activatorul Ad-Away pentru root fără sistem, dar nici asta nu pare să funcționeze în acest moment.
sailfish:/sys/devices # mount -o rw, remount /system
mount: '/system' not in /proc/mountsActualizare: Chainfire a confirmat că FlashFire și alte aplicații vor trebui actualizate înainte de a putea fi utilizate. Vezi mai jos pentru mai multe detalii.
Actualizarea 2: Chainfire ne-a trimis un mesaj cu o soluție pentru ca AdAway să funcționeze până când aplicația este actualizată. Vezi addendumul de la sfârșitul articolului.
Iată câteva capturi de ecran care arată că Titanium Backup funcționează, totuși. Deci, dacă veniți de pe alt dispozitiv și doriți să restaurați toate aplicațiile pentru care ați făcut backup, puteți fi sigur că toate datele aplicației dvs. vor fi acum restaurate.
Vom continua să ne aprofundăm în dispozitivele noastre Pixel pentru a vedea ce putem comuta. Care caracteristică „exclusiv Pixel” va fi următoarea care va cădea?
„Lupta” pentru a obține rădăcina
Chainfire este destul de meticulos când vine vorba de lansarea notelor. Când sunteți dezvoltatorul, oferind zeci de mii de utilizatori o metodă pentru a obține accesul la root, face sens să fii cât mai transparent posibil, ca să nu te confrunți cu o hoardă de utilizatori confuzi care se întreabă de ce este ceva spart. În timp ce a lui cont de Twitter (@ChainfireXDA) este rezervată mai mult pentru anunțuri scurte, Chainfire tinde să posteze explicații lungi și binevenite pe Google+ cont. De data aceasta nu este diferit.
În primul rând, Chainfire explică ce modificări au fost aduse celor două telefoane Pixel pe care trebuia să le rezolve pentru a obține accesul root. În special, Chainfire descrie mai întâi noul aspect al partițiilor pe dispozitivele Pixel.
Aspect nou de partiție (Pixel și probabil multe dispozitive viitoare):
- Există două dintre mai multe partiții Android, boot, sistem, furnizor
- Partițiile de recuperare și cache au dispărut
- Rădăcina / directorul pentru Android face acum parte din partiția de sistem, în loc de partiția de boot (initramfs)
- Recuperarea se află acum în imaginea normală de pornire și își folosește initramfs (care era folosit înainte de Android)
După cum am tratat anterior, acestea modificări de partiție pe cele două telefoane Pixel ar fi necesită unele modificări la metoda rădăcină curentă. Chainfire a confirmat că aceste modificări ale partiției /system necesită o abordare diferită, una care poate implica modificarea nucleului.
Cu noul aspect al partiției Pixel, acele fișiere pe care le schimbam s-au mutat în partiția de sistem (ceea ce credeam inițial ca /system este acum un subfolder în sistemul de fișiere al partiției respective). Deci, am putea doar să modificăm partiția de sistem care conține toate aceste fișiere și să lăsăm imaginea de pornire în pace? Deși personal prefer să modific imaginea de pornire și să las sistemul în pace, inversul ar putea fi o soluție și știu că unii utilizatori de tehnologie chiar ar prefera acest lucru.
Cu toate acestea, nu am putut face asta să funcționeze. Bootloader-ul trimite de fapt informații către kernel (care se află în imaginea de boot) care dm-verity activat cu forța (care impune integritatea partiției sistemului), pe care nu o putem intercepta sau schimba fara (ruliu de tobe) modificarea imaginii de boot. Prima mea rădăcină de succes a Pixel a fost făcută astfel - modificându-le pe ambele (imaginea postată mai devreme este din această încercare).
Cu alte cuvinte, nu există nicio modalitate de a dezactiva dm-verity fără o modificare a nucleului, așa cum am bănuit. Deoarece nucleul activează forțat dm-verity, Chainfire a trebuit să modifice ușor nucleul pentru a opri dm-verity să prevină modificări ale partiției de sistem. Din fericire, însă, Chainfire a descoperit că modificarea sa necesită doar un mic patch binar al nucleului, dar nu o recompilare completă a nucleului. Astfel, soluția sa ar trebui să rămână o soluție generică pentru dispozitivele Android 7.1 cu o schemă de partiție A/B.
Pentru a explica mai detaliat această nouă metodă de rădăcină, Chainfire realizează rădăcina fără sistem prin realizarea nucleul folosește initramfs al imaginii de pornire ca director rădăcină, mai degrabă decât orice altceva din sistem compartimentare. Pentru a face acest lucru, conținutul directorului rădăcină din partiția de sistem este importat în imaginea de pornire, ceea ce permite modificarea acestor fișiere fără a fi nevoie să modificați niciun fișier de sistem. Partiția de sistem este montată pe /sistem_rădăcină și /sistemul însuși este conectat sim la /system_root/system. Și, în cele din urmă, patch-ul său de kernel modifică nucleul astfel încât să ignore comanda trimisă de la bootloader, care ar impune de obicei dm-verity.
Cu toate acestea, există câteva probleme destul de triviale introduse cu această nouă metodă. Anumite aplicații, cum ar fi FlashFire sau AdAway (ambele dintre care am arătat că nu funcționează) se așteaptă ca partiția de sistem să fie montată ca /system, nu /system_root și va trebui actualizată în consecință. Deși, puteți încerca să remontați sistemul ca atare
mount -o rw, remount /system_rootCare ar trebui să vă permită să scrieți în /system. Nu am testat încă ce aplicații root se rezolvă, dar sunteți liber să le testați singur. În cele din urmă, Chainfire nu este sigur dacă suhide va funcționa cu această nouă schemă de înrădăcinare, dar el afirmă că va continua să caute o soluție.
Pentru a descărca SuperSU pentru telefoanele Google Pixel, mergeți la Subiect de forum XDA. Un mare mulțumire lui Chainfire pentru că a adus root pe dispozitive! Să înceapă Jocurile de Tweaking!
Vizitați subforumul SuperSU XDA!
Această poveste este în curs de dezvoltare și va fi actualizată pe măsură ce primim informații noi. Un Google Pixel a fost sacrificat la realizarea acestui articol. RIP datele lui Jeff.
Anexa nr. 1: Remediere temporară pentru AdAway
Descărcați AdAway v3.1.2 de pe site-ul nostru forumuri, apoi utilizați fie a emulator de terminal sau ADB shell pentru a introduce următoarea comandă:
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/50adawayReporniți și ar trebui să aveți blocarea anunțurilor la nivel de sistem.