adb, fastboot and ssh and other system stuff on Google Pixel 6 Pro

About this messy post

As I rooted my Google Pixel 6 Pro, there were a few things to get in place on my Linux Mint 19 machine. These are random notes I took as I went along.

Install ADB and fastboot

# apt install android-tools-adb android-tools-fastboot

So that was easy.

Next, opening the phone for ADB access, the standard Android way: Go to the phone settings, into About Phone. Tap seven times on Build Number. The phone prompts for the PIN number, and then the “You are now a developer” message appears.

Now, under System, there’s the Developer options. Enable USB debugging. And then at shell prompt:

$ adb devices
List of devices attached
23011xxxxxxxx	no permissions (user in plugdev group; are your udev rules wrong?); see [http://developer.android.com/tools/device.html]

Arghh. This was because of a lacking udev rule for when the phone isn’t in File Transfer / Android Auto mode. So I enabled file transfer (even though the real solution is to fix the udev file, as described below). And that’s when a popup appears asking if the computer should be allowed USB debugging. So yes, and pick “Always allow from this computer”.

Now we’re talking:

$ adb devices
23011xxxxxxxx	device

Yey. Even more yey: Using adb shell, I got

$ id
uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),1078(ext_data_rw),1079(ext_obb_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid) context=u:r:shell:s0

The privileges in this mode is much better than as an SSH client (see below). For example, one can list the files in /system/bin and /dev with adb shell and not through ssh (unless the ssh session gets root). Same goes with using “top”: It shows all processes, not just the same users’, as with ssh (once again, if the ssh session gets root, sky’s the limit).

There are nice executables in /vendor/bin too (even ifconfig and nc)

Getting the udev rule right

To resolve the “permission denied” thing with adb without file system access and fastboot, a udev rule needs to be added.

With MTP, file transfer on and off, I checked which udev rules got in action for the device with

$ udevadm test -a add $(udevadm info -q path -n /dev/bus/usb/002/004)

The 002/004 in the end are the bus and device numbers as found in lsusb.

It turns out that the relevant rule was in /lib/udev/rules.d/69-libmtp.rules:

# Google Inc Nexus/Pixel (MTP+ADB)
ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee2", SYMLINK+="libmtp-%k", MODE="660", GROUP="audio", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"

Note that it sets the group to “audio” and not “plugdev” The ENV{} assignments prevent the call to mtp-probe in this same udev file.

The truth is that I don’t completely understand why that works at all.

Anyhow, I ended up adding the following as /etc/udev/rules.d/20-google-pixel.rules:

# Google Inc Pixel 6 Pro, support for no-file transfer ADB mode
ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee7", MODE="660", GROUP="plugdev"
# Google Inc Pixel 6 Pro, support for USB tethering + ADB mode
ATTR{idVendor}=="18d1", ATTR{idProduct}=="4eec", MODE="660", GROUP="plugdev"
# Google Inc Pixel 6 Pro, support for MIDI + ADB mode
ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee9", MODE="660", GROUP="plugdev"
# Google Inc Pixel 6 Pro, support for fastboot mode
ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee0", MODE="660", GROUP="plugdev"

and don’t forget

$ sudo udevadm control --reload

I assigned the group “plugdev” or else fastboot required root (on the host computer) to detect the device. Also, I didn’t add any of the ENV{ID_MTP_DEVICE}=”1″ commands, because doing so prevents running mtp-probe. And oddly enough, if mtp-probe doesn’t run, I get a popup saying “Unable to mount mtp device”.

As a side note, mtp-probe runs on virtually every USB device. This is quite ugly, actually.

Backing up some of the phone’s data

You can’t just use tar to backup the root directory. Not sure why, but nothing happened when I tried. Maybe an SeLinux thing? So it boils down to something like this:

$ time adb shell 'su -c "tar -cz /storage/emulated/0/"' | sudo tar -xvz -C /mnt/tmp/googlepixel/

This backs up the visible user data. For hidden application data, repeat this with data/:

$ time adb shell 'su -c "tar -cz /data/"' | sudo tar -xvz -C /mnt/tmp/googlepixel/

And here’s the crux: There are several duplicate mounts in the filesystem. It seems like a lot under /data/user/0 is a repeated backup. And even more so, /data/media/0 is apparently a duplicate of /storage/emulated/0/ (or the other way around? I’m confused), so maybe there’s no point backing up /storage/emulated/0  if /data is backed up.

For a round-up of backing up things that are probably completely useless:

$ time adb shell 'su -c "tar -cz /mnt/vendor /apex /metadata"' | sudo tar -xvz -C /mnt/tmp/googlepixel/

Have I missed something that should be backed up? I don’t know.

Grabbing system info

Be sure to check out this reference and  this cheat sheet for adb commands.

There’s a utility, dumpsys, that allows getting system information easily from the phone.

So, to tell which application is responsible for a window that just showed up:

$ adb shell dumpsys window windows > windows.txt

Or get some memory info (which application takes how much memory?):

$ adb shell dumpsys meminfo > mem.txt

What caused apps to terminate? This gives a log of last exits for each package.

$ adb shell dumpsys activity exit-info > exit.txt

Or everything at once (takes about 30 seconds to run, and emits a lot of error messages):

$ adb shell dumpsys > all.txt

Note that the file is output on the host, not on the phone with these commands.

To get the system log, use logcat:

$ adb shell logcat -d > all-log.txt

The -d flag tells logcat to terminate when it reaches the end of the log. Otherwise it continues running in “tail -f” style.

To get a list of all running processes:

$ adb shell ps -A > ps-all.txt

Look at this page for some additional utilities, in particular the Package Manager (pm) and Activity Manager (am). For a more in-depth understanding of the machinery, look for information on Intents and Activities.

Also try

$ adb shell device_config list

Bonus: device_config also allows to set the listed parameters, and these settings survive reboot (generally speaking).

List all installed packages:

$ adb shell cmd package list packages > packages.txt

Remove all user data for a package (at adb prompt, com.tencent.mm is WeChat)

pm clear com.tencent.mm

Where apps keep their data

For example, Whatsapp:

• /data/data/com.whatsapp/
• /mnt/installer/0/emulated/0/Android/data/com.whatsapp

The sensitive stuff is in the former. The latter may be accessible to anyone.

System startup

Services that are started during boot are listed in /etc/init/. There’s update_engine.rc and update_verifier.rc services there by the way.

Linux kernel

To download the Linux kernel, go

git clone https://android.googlesource.com/kernel/gs

This is a Generic Kernel Image kernel, meaning that it includes the parts that are common to all devices. Device-specific drivers are applied as kernel modules instead.

The Linux kernel that runs on my machine is commit 740f7fbe5f3917e0a5fa0582b98543af4a15a7ba (with no special tag), which identifies itself as v5.10.43. I deduced the commit based upon the “g740f7fbe5f39″ part in the kernel version that appears in the phone’s about part (5.10.43-android12-9-00005-g740f7fbe5f39).

Note however that some drivers don’t come from this kernel tree, but are rather loaded as modules from other sources. google_charge.c, for example.

SSH session with simpleSSHD

This is a no-cost app, which is essentially the Dropbear server.

Note: It’s also possible to connect with “adb shell” through a plain USB cable, and there’s “adb push” and “adb pull” to transfer files. So the advantage of SSH is limited.

Having SimpleSSHD running and started on the phone, I connected with the address provided on the screen

$ ssh -p 2222 user@10.11.12.13

the password appears on the phone’s screen. To use automatic login, go

cat > ~/authorized_keys

and copy-paste the content of ~/.ssh/id_rsa.pub there. Note that the file on the phone is not under a .ssh/ directory, which is probably why the ssh-copy-id utility doesn’t cut. Note however that once this file is found, a password login is not attempted if the host’s public key doesn’t match, so now try to log in from a computer that doesn’t have one of the listed keys.

In principle, the available executables are in /system/bin. The path contains more directories, but this is the only effective one.

Who am I?

$ id
uid=10225(u0_a225) gid=10225(u0_a225) groups=10225(u0_a225),3003(inet),9997(everybody),20225(u0_a225_cache),50225(all_a225) context=u:r:untrusted_app_29:s0:c225,c256,c512,c768

Backing up directly from phone (command run on receiving host):

$ ssh -p 2222 user@10.11.12.13 tar -cvz /storage/emulated/0/

The execution path…?

$ echo $PATH
/sbin:/system/sbin:/system/bin:/system/xbin

Unfortunately, these directories aren’t readable as a regular user, so it’s impossible to do a plain “ls” on them. Just in case I was looking for excuses to root the phone.

“more” also works fine, but there’s no “less”.

“top” works nicely, but shows only the same user’s processes. There’s also “ps”, but it seems to do the same. But hey, I rooted the phone. So

$ su
# id
uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0

And that’s the reason I rooted the phone, actually.