How to create development build capable of sudo/root access

joSS

I have been trying out GrapheneOS on my Pixel 9 for a while and have found access to some of its files by using 'adb shell'. I noticed several files in the source code (.rc files) that seem to reference files here, and I wanted to explore more of what is happening (yes, I am interested in getting involved in the code, perhaps related to this).

However, when I try taking a look at the files, some of the details are not accessible. For example:
tokay:/sys/devices/tracepoint/power $ ls -l
total 0
-????????? ? ? ? ? ? async
-????????? ? ? ? ? ? autosuspend_delay_ms
-????????? ? ? ? ? ? control
-????????? ? ? ? ? ? runtime_active_kids
-????????? ? ? ? ? ? runtime_active_time
-????????? ? ? ? ? ? runtime_enabled
-????????? ? ? ? ? ? runtime_status
-????????? ? ? ? ? ? runtime_suspended_time
-????????? ? ? ? ? ? runtime_usage
tokay:/sys/devices/tracepoint/power $ cat runtime_usage
cat: runtime_usage: Permission denied

I figured this may have been a sudo issue, so I exited the shell and tried 'adb root' to give myself the necessary permissions. But the output says 'adbd cannot run as root in production builds'.

So now I'm looking into the official build instructions to see if it mentions how to make a non-production build. But the best I could find is references about a "development build" and creating a faster build by "using the default build target rather than target-files-package". It seems to end the instructions with "Leave the bootloader unlocked and flashing the raw images that are signed with the default public test keys".

I have previously been building GrapheneOS and making "signed factory images"; I would unzip the factory zip and be able to flash the new image onto my Pixel 9. But when doing it in the same directory, but just adjusting the commands to try building for development build, it hasn't been working. I tried the following, but all still lead to my 'cannot run as root' issue:

Ensured I did 'lunch tokay-cur-userdebug' instead of 'lunch tokay-cur-user'
Tried running 'm' instead of 'm vendorbootimage vendorkernelbootimage target-files-package'
Did 'rm -r out' and run 'm' again i.e., build from scratch
Instead of making signed factory image, grab just the output images (vendor_boot.img and vendor-bootconfig.img from out/target/product/tokay/) and replace the old ones from a previous signed factory image, and run .\flash_all.bat from this previous signed factory image

In short, could I get some help making a non-production build, capable of having root access in the 'adb shell' please?

de0u

joSS Instead of making signed factory image, grab just the output images (vendor_boot.img and vendor-bootconfig.img from out/target/product/tokay/) and replace the old ones from a previous signed factory image, and run .\flash_all.bat from this previous signed factory image.

I don't think that's what the build instructions suggest. What happens if all of the directions for building and flashing a userdebug build are followed?

joSS

de0u
Hello. The instructions seemed vague about this point, and because it mentioned "flashing the raw images", I suspected a different approach was required. I just randomly gave this a shot as I had run out of ideas.

The earlier suggestions I mention about 'lunch tokay-cur-userdebug' and 'm' did go through all the instructions. Assuming it's not the first time i.e., I already extracted vendor files for Pixel devices and already generated release signing keys, then I ran the following commands:

source build/envsetup.sh
lunch tokay-cur-userdebug
rm -r out
m
m otatools-package
script/finalize.sh
script/generate-release.sh tokay 2025090800
(get the zip from the 'releases' directory, and follow CLI install instructions)
Again, I followed this process before when making the 'user' builds.

de0u

joSS At first glance that looks right. Did it work?

joSS

de0u
No it didn't work. So I'm checking around in the forums to see if there's some other approach that I'm not aware of.

de0u

joSS No it didn't work.

What went wrong?

joSS

de0u
I try 'adb root' and I still get output saying 'adbd cannot run as root in production builds'.

de0u

joSS I try 'adb root' and I still get output saying 'adbd cannot run as root in production builds'.

Is ro.debuggable=1 if you run adb shell "cat /system/build.prop"?

Edit: What is ro.debuggable in out/target/product/tokay/system/build.prop?

joSS

de0u
I cannot tell. Getting permission errors with this command as well, though with build.prop I can at least see details with "ls -l":

PS C:\Users\mydesktop> adb shell "cat /system/build.prop"
cat: /system/build.prop: Permission denied
PS C:\Users\mydesktop> adb shell
tokay:/ $ cd system
tokay:/system $ cat build.prop
cat: build.prop: Permission denied
1|tokay:/system $ ls -l
total 80
drwxr-xr-x 2 root root 4096 2009-01-01 00:00 apex
drwxr-xr-x 29 root root 4096 2009-01-01 00:00 app
drwxr-x--x 4 root shell 8192 2009-01-01 00:00 bin
-rw------- 1 root root 5357 2009-01-01 00:00 build.prop
drwxr-xr-x 19 root root 4096 2009-01-01 00:00 etc
drwxr-xr-x 2 root root 8192 2009-01-01 00:00 fonts
drwxr-xr-x 4 root root 4096 2009-01-01 00:00 framework
drwxr-xr-x 2 root root 4096 2009-01-01 00:00 lib
drwxr-xr-x 5 root root 24576 2009-01-01 00:00 lib64
drwxr-xr-x 45 root root 4096 2009-01-01 00:00 priv-app
lrw-r--r-- 1 root root 8 2009-01-01 00:00 product -> /product
lrw-r--r-- 1 root root 11 2009-01-01 00:00 system_ext -> /system_ext
drwxr-xr-x 7 root root 4096 2009-01-01 00:00 usr
lrw-r--r-- 1 root root 7 2009-01-01 00:00 vendor -> /vendor
tokay:/system $

de0u

joSS

In your build tree, what is ro.debuggable in out/target/product/tokay/system/build.prop?

joSS

de0u
Looks like it was set to ro.debuggable=0. Is this something I can directly change to a 1? I assume it won't persist across incremental builds if I change it in the ./out/ directory, but so far I haven't found where I would need to edit to change it.

de0u

joSS Looks like it was set to ro.debuggable=0.

Then, I think, effectively it's a user build rather than a userdebug build. Maybe some state was left over from the previous build, or maybe a different build was flashed than was expected.

joSS

de0u
Yes that's what it seems like is happening.

I believe doing 'rm -r out' should fix that leftover state issue (unless there's something else I'm not aware of?). I double checked the build I used to flash and am pretty sure I didn't flash some older/other build.

de0u

joSS I believe doing 'rm -r out' should fix that leftover state issue (unless there's something else I'm not aware of?).

I would expect so...