Az XDA Senior Developer Chainfire jóvoltából a Google Pixel és a Pixel immár gyökérrel rendelkezik! Látogasson el, és tudjon meg többet arról, hogyan rootolhatja pixelét!
Ez a módszer elavult, és előfordulhat, hogy nem működik. Kérjük, keresse fel Google Pixel és Pixel XL fórumainkat a legújabb gyökérmódszerekért.
Ahogy ígértem, rendszer nélküli gyökér a Google Pixel és Pixel XL van most elérhető. XDA elismert vezető fejlesztő Lánctűza Google Pixel root-ján dolgozott Android 7.1 Nougat operációs rendszert futtató telefonja az elmúlt napokban, és fejlődésének egy olyan szakaszához érkezett, ahol már elég kényelmesen megoszthatja munkáját a közösséggel.
A Google Pixel és a Google Pixel XL root hozzáférése a SuperSU telepítésével érhető el 2,78 SR2, amely lehetővé teszi su anélkül érhető el, hogy bármit is érintene a rendszerpartíción, és lehetővé tenné a dm-verity átkapcsolását. Mielőtt rootolná az eszközt, először fel kell oldania a rendszerbetöltőt. A rendszerbetöltő feloldásának első lépése az adb és a fastboot binárisok letöltése (javasoljuk, hogy
Minimális ADB és Fastboot fórumunkról), majd telepítse a megfelelőt Google USB illesztőprogram a gépedhez.Ha Pixel eszközét közvetlenül a Google-tól vásárolta, akkor csak a fastboot villogó feloldás parancsot követi fastboot oem feloldás. Ha Pixel készülékét a Verizontól vagy az EE-től vásárolta, akkor ezt meg kell tennie oldja fel a rendszerbetöltőt a dePixel8 eszközzel. De siess, mert a SunShine fejlesztői megemlítették, hogy a bootloader feloldó exploitjuk javításra kerülhet a közelgő novemberi biztonsági frissítésben!
A SuperSU telepítése a Pixelre
Ahogy Chainfire a Google+-bejegyzésében megemlíti, először le kell töltenie a boot-to-root képeket a Pixel vagy Pixel XL számára a webhelyéről. tudsz kattints ide a zip letöltéséhez a Google Pixelhez, vagy kattints ide a Google Pixel XL zip letöltéséhez. A zip letöltése után meg kell tennie fastboot boot a boot-to-root kép, NEfastboot flash a kép! Más szóval, az egyetlen parancs, amire szüksége lesz a két eszközhöz, a következő:
fastbootbootboot-to-root.imgVárjon néhány percet, és néhány újraindítás után teljes root hozzáféréssel fog elindulni. Hurrá!
A Root Access azonnali használata
Mellesleg, a szokásos funkciókon kívül, amelyeket a root hozzáférésnek biztosítania kell, előre mentünk és teszteltünk néhány olyan dolgot, amelyekről tudtuk, hogy mindenkit érdekelni fog. Először is, vissza tudod hozni a Google Asszisztenst a Tapban? A válasz Igen! Nincs más dolgod, mint szerkeszteni build.prop a következő változtatással indítsa újra, és törölje a Google App adatait, és többé nem üdvözölheti a Google Asszisztens.
változás
ro.opa.eligible_device=truenak nek
ro.opa.eligible_device=<strong>falsestrong>Mi a helyzet egy másik gyakran rejtett funkcióval: dupla koppintás az ébresztéshez? Körülnéztünk a rejtett kapcsolót keresve, és rájöttünk, mi az, ami annak tűnik.
sailfish:/sys/devices # echo 1 > ./soc/7577000.i2c/i2c-3/3-0020/input/input3/wake_gestureSajnos, amikor megváltoztattuk az értéket, úgy tűnt, hogy nem ragadt meg. Egyelőre úgy tűnik, hogy egy egyéni kernelt kell flashelni, mint pl ElementalX hogy a d2tw működjön.
Néhány egyéb, amit teszteltünk, többek között, hogy a Titanium Backup működik-e vagy sem (igen), jobb akkumulátor statisztika (művek), Aljzat/Réteg témák (úgy tűnik, hogy vannak problémák), és a hirdetésblokkolás (nem sikerül). Az Ad-away jelenleg nem működik, mert a /system alapértelmezés szerint nem csatlakoztatható írás-olvasás, ezért meg kell várnunk, amíg a TWRP elérhető lesz, mielőtt flashelhetnénk a rendszer nélküli megoldás az Ad-Away számára. És igen, már kipróbáltuk a használatát FlashFire felvillantani az Ad-Away engedélyezőt a rendszer nélküli root számára, de úgy tűnik, hogy ez sem működik jelenleg.
sailfish:/sys/devices # mount -o rw, remount /system
mount: '/system' not in /proc/mountsFrissítés: A Chainfire megerősítette, hogy a FlashFire-t és más alkalmazásokat használat előtt frissíteni kell. További részletekért lásd alább.
2. frissítés: A Chainfire egy megoldási javaslatot küldött nekünk, hogy az AdAway működjön, amíg maga az alkalmazás frissül. Lásd a kiegészítést a cikk végén.
Íme néhány képernyőkép, amelyek azt mutatják, hogy a Titanium Backup működik. Tehát ha egy másik eszközről érkezik, és vissza szeretné állítani az összes mentett alkalmazást, biztos lehet benne, hogy az összes alkalmazásadatot visszaállítjuk.
Továbbra is elmélyülünk Pixel eszközeinkben, hogy meglássuk, mit tudunk váltani. Melyik „Pixel exkluzív” funkció lesz a következő ősz?
A "küzdelem" a gyökér eléréséért
A Chainfire meglehetősen aprólékos, ha kiadási jegyzetekről van szó. Ha Ön a fejlesztő, aki több tízezer felhasználónak biztosít egy módszert a root hozzáférés elérésére, ez megtörténik A lehető legátláthatóbbnak kell lennie, nehogy zavart felhasználók hordájával nézzen szembe, akik azon töprengenek, miért van valami törött. Míg az övé Twitter fiók (@ChainfireXDA) inkább a rövid bejelentésekre van fenntartva, Chainfire általában üdvözlendő, hosszadalmas magyarázatokat tesz közzé Google+ fiókot. Ezúttal sincs ez másképp.
Először is Chainfire elmagyarázza, milyen változtatásokat hajtottak végre a két Pixel telefonon, amelyeket meg kellett oldania a root hozzáférés eléréséhez. A Chainfire először a Pixel eszközök új partícióelrendezését írja le.
Új partícióelrendezés (Pixel és valószínűleg sok jövőbeli eszköz):
- A számos Android partíció közül kettő van, rendszerindítás, rendszer, szállító
- A helyreállítási és gyorsítótár-partíciók eltűntek
- Az Android gyökér/könyvtára mostantól a rendszerpartíció része, a rendszerindító partíció (initramfs) helyett
- A helyreállítás most a normál rendszerindító képen belül van, és az initramfs-t használja (amit korábban az Android használt)
Amint azt korábban írtuk, ezek partíció megváltozik a két Pixel telefonon bizonyos módosításokat igényel az aktuális gyökérmetóduson. A Chainfire megerősítette, hogy a /system partíció ezen módosításai más megközelítést igényelnek, amely magában foglalhatja a kernel módosítását is.
A Pixel új partícióelrendezésével azok a fájlok, amelyeket megváltoztattunk, átkerültek a rendszerpartícióra (amit eredetileg /system néven gondoltunk, az most egy almappa a partíció fájlrendszerén belül). Tehát módosíthatjuk-e az összes fájlt tartalmazó rendszerpartíciót, és békén hagyhatnánk a rendszerindító lemezképet? Bár én személy szerint jobban szeretem a rendszerindító kép módosítását és békén hagyni a rendszert, a fordítottja is megoldás lehet, és tudom, hogy néhány technológiai felhasználó ezt preferálná.
Ezt azonban nem tudtam működésre bírni. A rendszerbetöltő valójában információkat küld a rendszermagnak (amely a rendszerindító lemezképben található). kényszerített dm-verity (amely a rendszerpartíció integritását kényszeríti ki), amelyet nem tudunk elfogni vagy változtatás nélkül (dobpergés) módosítja a rendszerindító képet. Az első sikeres Pixel gyökerem így készült - mindkettő módosításával (a korábban közzétett kép ebből a kísérletből származik).
Más szóval, nincs mód a dm-verity letiltására a kernel módosítása nélkül, ahogy sejtettük. Mivel a kernel kényszerítette a dm-verity engedélyezését, a Chainfire-nek kissé módosítania kellett a kernelt, hogy a dm-verity ne akadályozza meg a rendszerpartíció módosításait. Szerencsére azonban a Chainfire felfedezte, hogy a módosításához csak egy kis kernel bináris javításra van szükség, de nem egy teljes kernel-újrafordításra. Így az ő megoldásának általános megoldásnak kell maradnia az A/B partíciós sémával rendelkező Android 7.1-es eszközökhöz.
Ennek az új gyökérmódszernek a részletesebb ismertetése érdekében a Chainfire rendszer nélküli gyökeret ér el azáltal, hogy a A kernel a rendszerindító lemezkép initramfs fájlját használja gyökérkönyvtárként, nem pedig bármit a rendszerből partíció. Ehhez a rendszerpartíció gyökérkönyvtárának tartalmát a rendszer a rendszerindító lemezképbe importálja, amely lehetővé teszi ezen fájlok módosítását a rendszerfájlok módosítása nélkül. A rendszerpartíció a /rendszergyökér fájlhoz van csatolva, maga a /rendszer pedig a /rendszergyökér/rendszerhez van csatolva. És végül a kernelfoltja úgy módosítja a kernelt, hogy figyelmen kívül hagyja a rendszerbetöltőtől küldött parancsot, amely általában a dm-verity-t kényszeríti ki.
Azonban van néhány meglehetősen triviális probléma, amelyet ezzel az új módszerrel vezettek be. Egyes alkalmazások, például a FlashFire vagy az AdAway (mindkettő nem működik) elvárja, hogy a rendszerpartíciót /rendszerként, nem pedig /rendszergyökérként csatolják, és ennek megfelelően frissíteni kell őket. Megpróbálhatja azonban a rendszer visszaszerelését
mount -o rw, remount /system_rootAminek lehetővé kell tennie a /system-be írást. Még nem teszteltük, hogy mely gyökéralkalmazások javítanak, de szabadon tesztelheti saját maga. Végül Chainfire nem biztos abban, hogy suhide Ezzel az új rootolási sémával fog működni, de kijelenti, hogy továbbra is keresni fogja a megoldást.
A SuperSU Google Pixel telefonokhoz való letöltéséhez lépjen a következő oldalra: XDA fórum téma. Nagy köszönet a Chainfire-nek, hogy gyökeret hozott az eszközökön! Kezdődjenek a Tweaking Games!
Látogassa meg a SuperSU XDA Alfórumot!
Ez a történet fejlesztés alatt áll, és amint új információkhoz jutunk, frissítjük. Egy Google Pixel feláldozásra került a cikk elkészítése során. RIP Jeff adatai.
1. kiegészítés: Ideiglenes javítás az AdAway-hez
Töltse le az AdAway v3.1.2-t a mi oldalunkról fórumok, majd használja a terminál emulátor vagy ADB shellben a következő parancs beírásához:
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/50adawayIndítsa újra, és rendszerszintű hirdetésblokkolással kell rendelkeznie.