Rooting an Android test deviceTest device you own.

No prior experience needed. This walks you through rooting a Google Pixel with Magisk, one small action at a time. Every step says what you should see, so you always know whether it worked. If anything looks different, stop and check If something goes wrong further down before you continue.

Root means getting full administrator access to the phone, which normal apps and users never have. Security apps (including this library) try to detect it. You root a test phone so you can check that detection works.

Plan for about an hour the first time. The whole journey has six stages:

1. 01Set up your computer — install two small command-line tools, adb and fastboot.
2. 02Prepare the phone — back it up and switch on a few hidden developer settings.
3. 03Unlock the bootloader — this erases the phone completely.
4. 04Download the right system file — a copy of one part of the phone's software that exactly matches your phone.
5. 05Patch it with Magisk — an app modifies that file to include root.
6. 06Flash it back and test — copy the modified file onto the phone and confirm root works.

1. 01A spare Android phone you own — ideally a Google Pixel (Pixel 7 or newer is easiest). Not your everyday phone: it will be erased.
2. 02A USB cable that carries data, not just power. The cable that came with the phone is best. If the computer never sees the phone, the cable is the first suspect.
3. 03A Mac or Windows computer with internet access and about 5 GB of free space.
4. 04A backup of anything on the phone you care about (photos, files, two-factor authenticator codes). Unlocking erases everything.

On a Mac: install Homebrew if you don't have it (copy the one-line command from its homepage into Terminal). Then run the install command below.

On Windows: download SDK Platform-Tools for Windows from Google's platform-tools page and unzip it to C:\platform-tools. Open that folder in File Explorer, click the address bar, type cmd and press Enter — a Command Prompt opens in that folder. Run every command in this guide from that window, and put any downloaded phone files in C:\platform-tools too. If the phone is never detected later, also install the Google USB Driver.

Then check it worked. You should see: a version number for each tool. If you see command not found (Mac) or is not recognized (Windows), the install didn't finish or you're in the wrong folder.

# Mac only:
brew install --cask android-platform-tools

# Mac and Windows — check both tools respond:
adb version
fastboot --version

This trips up almost everyone, so it's worth two minutes. adb and fastboot both talk to the phone over the same USB cable, but they talk to two different programs on the phone, and only one of those programs is running at any moment. That's why one tool can see the phone while the other says no devices found — nothing is broken, the phone is just in the other mode.

adb talks to Android itself. When Android is running and USB debugging is switched on, a small background service on the phone listens for adb. That service is part of Android, so it only exists once Android has started. adb can therefore do anything that needs a running phone: install apps, copy files to and from storage, open a command line on the phone (adb shell), read settings like the build number, and tell the phone to restart into fastboot mode. Because it's this powerful, the phone asks you to approve each computer first (the "Allow USB debugging?" prompt).

fastboot talks to the bootloader. The bootloader runs *before* Android, and Android isn't running at all while you're in fastboot mode — so there's no adb service to answer. The bootloader understands only a short list of low-level commands: unlock or lock itself, write (flash) a system file onto a part of the phone's storage, report basic facts (fastboot getvar …), and restart. It can't see your apps or files, and it doesn't need USB debugging or the approval prompt.

So the rule is: anything about apps, files, or reading the phone's software → adb, with the phone switched on normally. Anything about unlocking or replacing system files → fastboot, with the phone in fastboot mode. Most of this guide is switching between the two: adb to get into fastboot mode, fastboot to flash, then back to Android and adb again.

adb devices
# 1A2B3C4D5E6F	device      -> Android is running, adb works
# (empty list)                   -> not in Android, or USB debugging off / not allowed

fastboot devices
# 1A2B3C4D5E6F	fastboot    -> in fastboot mode, fastboot works
# (no output)                    -> not in fastboot mode

# Switch modes:
adb reboot bootloader    # Android  -> fastboot mode
fastboot reboot          # fastboot -> Android

One more idea that saves a lot of confusion. A terminal window is always sitting in one folder on your computer — called the current folder. Commands that read or save files use that folder unless you say otherwise: adb pull saves the copied file there, adb push and adb install look for your file there, and payload-dumper-go reads the package from there and writes its extracted folder there.

So most "file not found" or "cannot create" errors aren't about the phone at all — the terminal is just looking in, or saving to, the wrong folder on your computer. The fix is always the same: move into the folder where your files are, or type the full location as part of the command.

In this guide: on a Mac, keep everything in Downloads and run cd ~/Downloads in each new Terminal window. On Windows, keep everything in C:\platform-tools and open Command Prompt from that folder (Step 1). The ~ on a Mac is short for your home folder, so ~/Downloads is your Downloads folder.

pwd                 # show the current folder      (Windows: cd)
cd ~/Downloads      # move into Downloads           (Windows: cd C:\platform-tools)
ls                  # list the files in it          (Windows: dir)

# Saving to a specific place, wherever you are:
adb pull /sdcard/some-file.zip ~/Downloads/some-file.zip

1. 01Back up everything you want to keep. The next stage erases the phone.
2. 02Turn on Developer options: Settings → About phone → tap Build number 7 times. Enter your PIN if asked. You should see: "You are now a developer!"
3. 03Open Developer options: Settings → System → Developer options.
4. 04Turn on OEM unlocking. If it's greyed out, connect to Wi-Fi and wait a few minutes. If it stays greyed out, the phone is carrier-locked and can't be unlocked.
5. 05Turn on USB debugging in the same menu.
6. 06Plug the phone into the computer and run adb devices.
7. 07On the phone, a box asks "Allow USB debugging?" Tick "Always allow from this computer" and tap Allow.
8. 08Run adb devices again. You should see: a serial number followed by device. If it says unauthorized, look for the prompt on the phone. If the list is empty, try another cable or USB port.

adb devices
# List of devices attached
# 1A2B3C4D5E6F	device      <- good

This erases everything on the phone. You only do it once. The terminal output below is what you'll really see — including some scary-looking lines that are fine. Phones differ after the confirmation step, so the steps say what Pixels and other brands (OnePlus, Nothing, …) do.

1. 01Run adb reboot bootloader. You should see: the phone restart into the fastboot screen. The terminal prints nothing — that's fine.
2. 02Run fastboot devices. You should see: your serial number followed by fastboot. On a Mac, if nothing appears, unplug and replug, or use a port directly on the computer.
3. 03Run fastboot flashing unlock. On a Mac the terminal may first print two ERROR: could not clear … pipe lines — ignore them, they're harmless. Some phones then print (bootloader) Start unlock flow. Finally it prints OKAY and Finished. That only means the phone is now asking you — the unlock hasn't happened yet. If it prints FAILED, see the note below.
4. 04On the phone: a warning screen asks whether to unlock. Use the Volume keys to highlight Unlock the bootloader (the wording varies), then press Power.
5. 05What happens next depends on the phone. Pixel: it erases itself and returns to the fastboot screen showing Device state: unlocked — run fastboot reboot. OnePlus, Nothing and many others: it erases itself and restarts straight into Android on its own — no command needed. If the terminal is just sitting there, that's fine; you're done with it for now.
6. 06Optional check, while still on the fastboot screen: fastboot getvar unlocked prints unlocked: yes on Pixels. Many other phones answer FAILED (remote: 'GetVar Variable Not found') or the command just hangs — because the phone is showing the confirmation screen or has already restarted to erase itself, so nothing answers. Press Ctrl+C; it's safe. Check after setup instead (Step 4: verifiedbootstate = orange).
7. 07If the phone stays on the fastboot screen and fastboot reboot does nothing: on a Pixel, press Volume until Start shows and press Power. On a phone whose fastboot screen has no menu (newer OnePlus/OPPO/Realme), unplug and hold Power + Volume Up for 10–15 seconds.
8. 08The first start takes 5–10 minutes, and from now on every start shows a warning that the bootloader is unlocked ("orange state" on OnePlus). That's normal — wait or press Power to continue.
9. 09Set the phone up again (you can skip most options and accounts). Then repeat Step 2's developer settings: Developer options, USB debugging, and allow the computer again. The erase switched them off.

% adb reboot bootloader
% fastboot devices
1A2B3C4D5E6F	 fastboot

% fastboot flashing unlock          # older phones: fastboot oem unlock
ERROR: could not clear input pipe; result e0005000, ignoring...    <- harmless (Mac)
ERROR: could not clear output pipe; result e0005000, ignoring....  <- harmless (Mac)
(bootloader) Start unlock flow       <- some phones print this
OKAY [  4.408s]
Finished. Total time: 4.408s
# now LOOK AT THE PHONE and confirm there — nothing else happens until you do

% fastboot getvar unlocked          # optional; Pixel only, after confirming
unlocked: yes                       # may hang instead on other phones: Ctrl+C

% fastboot reboot                   # Pixel only — others restart by themselves
Rebooting
Finished. Total time: 0.050s

You're about to download a copy of your phone's software. It has to match your phone exactly — same model, same region, same version — or the phone may not start. These commands read the details you need. Run them with the phone switched on normally and connected (adb devices shows device).

Got a Pixel? You only need the first two lines. Any other brand (OnePlus, Nothing, Xiaomi, Motorola…)? Run the bottom four.

# Pixel
adb shell getprop ro.build.id              # e.g. BP2A.250805.005
adb shell getprop ro.product.device        # e.g. caiman

# Every other brand
adb shell getprop ro.product.model             # e.g. CPH2581
adb shell getprop ro.build.display.id          # e.g. CPH2581_15.0.0.406(EX01)
adb shell getprop ro.product.first_api_level   # e.g. 34  -> init_boot.img
adb shell getprop ro.boot.verifiedbootstate    # orange = unlocked

Not a Pixel? Skip to Step 5 (other brands).

1. 01Open Google's Pixel factory images page and click Acknowledge to accept the terms.
2. 02Find the section for your codename (the page lists them like "caiman for Pixel 9 Pro").
3. 03In that list, find the row whose name contains your exact build number, e.g. BP2A.250805.005. Some builds have carrier-specific variants — the build number must match character for character. Click Link to download (a large .zip, 2–4 GB).
4. 04Unzip the download. Inside its folder is a second zip named like image-caiman-bp2a.250805.005.zip. Unzip that too.
5. 05Look inside for init_boot.img. If it's there, that's your file (Pixel 7 and newer). If there's only `boot.img`, use that instead (Pixel 6 and older). Use this file name wherever the next steps say init_boot.img.
6. 06Copy the file somewhere easy: Mac — your Downloads folder. Windows — C:\platform-tools. Also keep an untouched copy elsewhere: it's how you undo root later. Then go to Step 6.

Google's factory images page is unusually tidy: one official page, every Pixel, every version, one download per row. Other makers have the same ingredients, just scattered and named differently. Use the first table to translate each thing you'd do on Google's page into what to look for at your brand. The second shows how to read a version string so you can tell whether a download matches your phone.

The rule never changes: same model, same region, same version, full package. If any of the four doesn't match, don't use the file.

Other makers don't publish a simple list of images like Google does. Instead you download the same update package the phone uses to install a system update, and pull the one file you need out of it (next step).

Two things must be right: it must be the full package (often 4–7 GB), not a small "incremental" update, and it must be for your exact version from Step 4, including the region.

1. 01Easiest way to get a match: update the phone first. Go to Settings → About device → check for updates, and install everything until it says it's up to date. Most download sources offer the newest version, so this makes them match. (If you just unlocked and the phone is freshly set up, do this now — it doesn't relock anything.)
2. 02Run adb shell getprop ro.build.display.id again and write down the new version.
3. 03Download the full package for that exact version from the source for your brand in the table below. Links: Oxygen Updater and OnePlus Software Upgrade · Nothing Archive · Xiaomi Firmware Updater · Motorola Software Fix. Not sure what you're looking at? Google's page vs. other brands above translates each part.
4. 04Check the file name or the page you downloaded from: the version and region must match what you wrote down, character for character. If you can't find an exact match, stop here — a mismatched file is the main way phones get bricked.
5. 05Put the .zip on your computer: Mac — Downloads. Windows — C:\platform-tools. If you downloaded it on the phone (e.g. with Oxygen Updater), find it with adb shell ls /sdcard/ /sdcard/Download/. Oxygen Updater saves it in /sdcard/ with a random-looking name like 7da5df3feec64d12ac1b07f28435a09f.zip. Copy it over and give it a readable name by saying where to save it: adb pull /sdcard/7da5df3feec64d12ac1b07f28435a09f.zip ~/Downloads/phone-full.zip (Windows: just phone-full.zip at the end, from C:\platform-tools). It takes a few minutes; the last line shows the size — several GB means full, a few hundred MB means you got an incremental one.

adb shell ls /sdcard/ /sdcard/Download/      # find the .zip (Oxygen Updater: random name in /sdcard/)
cd ~/Downloads                               # work in Downloads
adb pull /sdcard/7da5df3feec64d12ac1b07f28435a09f.zip ~/Downloads/phone-full.zip
# ... progress ...
# /sdcard/7da5df…zip: 1 file pulled, 0 skipped. ... (5432109876 bytes ...)   <- several GB = full

# Windows (from C:\platform-tools):
# adb pull /sdcard/7da5df3feec64d12ac1b07f28435a09f.zip phone-full.zip

Inside the update .zip is one big file called payload.bin that holds every part of the phone's software. A small free tool, payload-dumper-go, copies out just the part you need. You don't even need to unzip the package first.

1. 01Install the tool. Mac: run brew install payload-dumper-go. Windows: download the …_windows_amd64.tar.gz file from its releases page, then in your Command Prompt (in C:\platform-tools) run tar -xzf followed by that file name. That puts payload-dumper-go.exe next to adb.
2. 02Mac only: run cd ~/Downloads. (Windows: you're already in C:\platform-tools.)
3. 03See what's inside: run payload-dumper-go -l followed by your .zip's name. You should see: a list of parts such as boot, init_boot, system, vendor… If it prints Delta payload … pass -old, or the parts are marked delta, you downloaded an incremental update (only the changes between two versions) — extracting will fail with an error like not supported yet: boot (PUFFDIFF). Go back and get the Full one. A random-named .zip in the phone's storage is usually the phone's own incremental system update, not what you want.
4. 04If the list contains `init_boot`, extract that. Otherwise extract boot. (This matches the first_api_level rule from Step 4.)
5. 05Run the extraction (commands below). It takes under a minute. You should see: a new folder named extracted containing init_boot.img (or boot.img).
6. 06Move that .img file out of the extracted folder into Downloads (Mac) or C:\platform-tools (Windows). Keep an untouched copy elsewhere — it's your undo. Then go to Step 6.

cd ~/Downloads
payload-dumper-go -l your-update.zip          # list the parts (use your real file name)
payload-dumper-go -p init_boot -o extracted your-update.zip
# no init_boot in the list? use:  -p boot
ls extracted                                                           # init_boot.img

1. 01Download the newest Magisk-vXX.X.apk from the Assets list on Magisk's official releases page. This GitHub page is the only official source — Magisk on the Play Store or other websites is fake.
2. 02Mac only: in Terminal, run cd ~/Downloads so the commands can find your files. (Windows: you're already in C:\platform-tools.)
3. 03Install the app: run adb install Magisk-vXX.X.apk using the real file name. You should see: Success.
4. 04Copy the system file to the phone: adb push init_boot.img /sdcard/Download/.
5. 05On the phone: open Magisk. Next to Magisk, tap Install → choose Select and Patch a File → pick init_boot.img from Downloads → tap Let's Go.
6. 06You should see: "All done!" and an output file name like magisk_patched-29000_aB1cD.img. It's saved in the phone's Download folder.

1. 01Find the exact patched file name: run adb shell ls /sdcard/Download/.
2. 02Copy it to the computer: adb pull /sdcard/Download/magisk_patched-29000_aB1cD.img (use your real name).
3. 03Reboot into fastboot: adb reboot bootloader.
4. 04Flash it: fastboot flash init_boot magisk_patched-29000_aB1cD.img. If your file was boot.img, type boot instead of init_boot. You should see: Sending…OKAY and Writing…OKAY.
5. 05Restart: fastboot reboot. You should see: the phone start normally (after the unlock warning).

adb shell ls /sdcard/Download/
adb pull /sdcard/Download/magisk_patched-XXXXX.img
adb reboot bootloader
fastboot flash init_boot magisk_patched-XXXXX.img   # 'boot' if you patched boot.img
fastboot reboot

1. 01Open the Magisk app. You should see: a version number next to Installed (not "N/A"). If it asks for additional setup, tap OK and let it reboot.
2. 02On the computer, run adb shell, then su.
3. 03On the phone: Magisk asks whether to grant Shell superuser access. Tap Grant.
4. 04Back in the terminal, run id. You should see: uid=0(root). Your phone is rooted. Type exit twice to leave.
5. 05Now install your app (or this library's example app) and see whether it detects root. With library 0.3+ and no hiding, you should see: COMPROMISED with bootloader_unlocked, root_su_binary, root_management_apps and root_magisk_files. On a physical phone the example's debug build needs Metro: run adb reverse tcp:8081 tcp:8081 (again after every reconnect), or it shows Unable to load script.

adb shell
su            # approve the prompt on the phone; the prompt changes to #
id            # uid=0(root) ...
exit
exit

Find the message you're seeing in the list below.

1. 01To remove root, flash the untouched file you kept from Step 5 / 5b the same way you flashed the patched one.
2. 02Put the phone in fastboot mode: adb reboot bootloader, or power off and hold Power + Volume Down.
3. 03Run fastboot flash init_boot init_boot.img (or boot boot.img), then fastboot reboot.
4. 04To restore the whole phone to factory software, run the flash-all.sh (Mac) or flash-all.bat (Windows) script inside the factory image folder while in fastboot mode — or use Google's browser-based Android Flash Tool.
5. 05Only re-lock the bootloader (fastboot flashing lock) after the phone is fully back to factory software. Locking with root still installed leaves a phone that won't start.

adb reboot bootloader
fastboot flash init_boot init_boot.img   # the untouched one; or: boot boot.img
fastboot reboot

Magisk is the right first test. Once it works, two other methods hide root more deeply and are worth testing your detection against. They differ in where the root hook lives, which drives how detectable and how portable they are. These assume you're comfortable with the steps above.

Root implemented inside the kernel. More powerful isolation and harder to detect from userspace, but requires a GKI-compatible kernel (generic kernel image, Android 12+) or a device-specific kernel build. KernelSU-Next is the community fork most people run in 2026 because it tracks fixes and pairs with SUSFS for hiding. Best for stronger root isolation, kernel-level testing, and better hiding when combined with SUSFS. Requires exact kernel matching — more fragile than Magisk.

1. 01Determine your kernel version: adb shell uname -r (e.g. 5.10.x, 5.15.x, 6.1.x).
2. 02Match it to a prebuilt KernelSU / KernelSU-Next AnyKernel3 zip or boot image for your exact kernel from KernelSU or KernelSU-Next releases (WildKernels GKI+SUSFS builds bundle SUSFS).
3. 03Flash the patched kernel/boot image (see command below).
4. 04Install the KernelSU Manager app; it should report Working with the kernel version.

fastboot flash boot kernelsu-boot.img
fastboot reboot

A middle ground: patches the kernel binary directly (like KernelSU's power) but works without a matching prebuilt kernel by patching your own boot.img — closer to Magisk's convenience. Provides KPM (kernel patch modules) and APM (Magisk-style modules). Newer and smaller community than the other two. Best for kernel-level root when no prebuilt KernelSU kernel exists for your device.

1. 01Extract boot.img from your factory image.
2. 02Install the APatch app (bmax/APatch on F-Droid or GitHub releases).
3. 03In the app, patch boot.img with a superkey you set, then flash the output the same fastboot flash boot way.
4. 04Verify in the app.

For app QA this is usually the point — you want to see whether your app (or a third-party one) detects root, and whether standard hiding defeats it.

Magisk: DenyList to hide root from selected apps; the built-in Zygisk. Pair with Play Integrity Fix / PIF modules to spoof a passing device fingerprint for BASIC/DEVICE verdicts. STRONG integrity (hardware-backed) generally cannot be passed on an unlocked bootloader — that is expected and is itself a useful test result.

KernelSU-Next + SUSFS: hides root at the kernel/filesystem layer (mounts, props), which defeats more aggressive detectors than DenyList alone.

APatch: similar hiding via its module system.

For app-resilience testing, run each config against tools like Play Integrity API checkers, RootBeer-based detectors, and your own root checks, and record which verdicts each method yields.

To test multiple root methods systematically, root the device, capture results, restore to stock, and repeat with the next method. Keep a simple results sheet: method × (su works / DenyList hides / PIF BASIC / PIF DEVICE / your-app detects Y-N).

1. 01Flash stock boot/init_boot to return to an unrooted baseline.
2. 02Install method A → run your full detection/integrity test suite → log results.
3. 03Restore stock → install method B → repeat.
4. 04Restore stock → method C → repeat.

1. 01Match every image to your exact build. Wrong boot.img = bootloop or brick.
2. 02Samsung Knox and hard-locked carrier devices are the ones that punish rooting permanently — avoid for testing unless that is specifically what you are testing.
3. 03STRONG Play Integrity on an unlocked bootloader is meant to fail — do not chase it.
4. 04Prefer a Pixel or other GKI device so all three methods are testable on one phone.