This thread is meant for ROM developers and the not the general public. Please don't comment asking questions unless you are a ROM developer planning on implementing this in your ROM.
I've taken the existing init.d framework and taken it to the next level.
Changes made:
Added a global scripts log directory so we can consolidate where we put our log files and help clean the system clean. It's located in /data/scriptlogs
Added logging to each init file which has its own individual logfile
Each init will set the following properties once it has completed. init.name_of_initfile.status & init.name_of_initfile.completed so we have record of its exit status and whether it finished running.
Wrote a shell script named bootstatus that will output a summary of the init scripts exist statuses.
If the phone is not booting or having issues you can verify init completed successfully by using bootstatus. If an init script failed it will tell you the location to the logfile containing a more descriptive log that should help explain why it failed. No more guessing game
Wrote a script to dump the stats from compcache. Previously this was done with rzscontrol, that no longer works on compcache 0.5 and up. The script is named ccstat
Lines to add to init.rc
Code:
start sysinit
on property:init.complete=1
class_start default
service sysinit /system/xbin/busybox run-parts /system/etc/init.d
disabled
oneshot
Output from bootstatus
Code:
# bootstatus
-----------------------------------------
| SCRIPT | STATUS | DETAILS
-----------------------------------------
sysctl PASS
firstboot PASS
a2sd PASS
userinit PASS
compcache PASS
linuxswap PASS
cpu PASS
virtualmem PASS
Properties that got set after init.d finished
Code:
[init.sysctl.complete]: [1]
[init.firstboot.complete]: [1]
[init.a2sd.complete]: [1]
[init.userinit.complete]: [1]
[init.compcache.complete]: [1]
[init.linuxswap.complete]: [1]
[init.complete]: [1]
[init.sysctl.status]: [PASS]
[init.firstboot.status]: [PASS]
[init.a2sd.status]: [PASS]
[init.linuxswap.status]: [PASS]
Output from ccstat
Code:
DiskSize: 32768 kB
NumReads: 245
NumWrites: 2063
FailedReads: 0
FailedWrites: 0
InvalidIO: 0
NotifyFree: 0
ZeroPages: 787
GoodCompress: 70 %
NoCompress: 4 %
PagesStored: 1276
PagesUsed: 457
OrigDataSize: 5104 kB
ComprDataSize: 1783 kB
MemUsedTotal: 1828 kB
Snapshot of the logs directory, /data/scriptlogs
Code:
# ls -l
-rw-rw-rw- root root 71 2010-02-02 20:43 09virtualmem.log
-rw-r--r-- root root 105 2010-02-02 13:48 06compcache.log
-rw-r--r-- root root 64 2010-02-02 20:42 08cpu.log
-rw-r--r-- root root 70 2010-02-02 20:30 07linuxswap.log
-rw-r--r-- root root 67 2010-02-02 13:48 05userinit.log
-rw-r--r-- root root 462 2010-02-02 13:48 04a2sd.log
-rw-r--r-- root root 66 2010-02-02 13:48 03firstboot.log
-rw-r--r-- root root 92 2010-02-02 13:48 01sysctl.log
-rw-r--r-- root root 102 2010-02-02 13:48 init.log
Snippet from a2sd logfile
Code:
04a2sd Starting: 13:48 02/02/2010
Running fsck on ext partition: Done
Mounting /system/sd Done
Clean old symlinks, create data directories:
------------------------
------------------------
Done
Copying /data/dalvik-cache contents to /system/sd/dalvik-cache
Removing /data/dalvik-cache directory
Binding /system/sd/dalvik-cache to /data/dalvik-cache: Done
Removing any .odex files in /system/sd/app: Done
Finished at 13:48 02/02/2010
Ok I finished up my changes and they are attached to this post now.
EDIT
Going to release in King's Eclair ROM and give it a test first. If mods want to delete this thread for now that's fine. I'll recreate later
Ok the files have been attached to the first post. Enjoy.
This should make the init process more stable and easier to debug from a user & developer standpoint.
Holy heck I wish I had found this before!!! You have answered so many questions for me about the new Eclair builds. Between this post and the King Eclair post in your sig you have answered many many ROM building questions I've had for weeks.
One last question -- Do you know if it matters where in init.rc I put start sysinit ?
EDIT: Well, I'm doing something wrong because it gave me init: invalid command 'start'
EDIT2: start sysinit needs to be added as a subcommand of 'on boot', cyanogen has it after setprop net.tcp.buffersize
Thanks again, fellow ROM builder
polyrhythmic said:
Holy heck I wish I had found this before!!! You have answered so many questions for me about the new Eclair builds. Between this post and the King Eclair post in your sig you have answered many many ROM building questions I've had for weeks.
One last question -- Do you know if it matters where in init.rc I put start sysinit ?
Thanks again, fellow ROM builder
Click to expand...
Click to collapse
No problem glad I could help. You can put the start sysinit right before the service definitions. Here is a larger snippit in init.rc so you can see where I placed it
Code:
setprop net.tcp.buffersize.edge 4093,26280,35040,4096,16384,35040
setprop net.tcp.buffersize.gprs 4092,8760,11680,4096,8760,11680
start sysinit
on property:init.complete=1
class_start default
## Daemon processes to be run by init.
##
service console /system/bin/sh
console
I'm seeing it all now... thanks again!
shafty023 said:
EDIT
Going to release in King's Eclair ROM and give it a test first. If mods want to delete this thread for now that's fine. I'll recreate later
Click to expand...
Click to collapse
And where i can find this script ?
Bladyle said:
And where i can find this script ?
Click to expand...
Click to collapse
FEBUARY....................7 months ago............
FEBUARY....................7 months ago............
Click to expand...
Click to collapse
so what
shafty023 said:
Ok the files have been attached to the first post. Enjoy.
This should make the init process more stable and easier to debug from a user & developer standpoint.
Click to expand...
Click to collapse
Hi,
I'm having an issue with all terminal emulators (Android Terminal Emulator, ConnectBot, ...) after upgrading my Nexus 10 from Android 4.2.2 to 4.3.
The terminal is not recognizing the actual size of the screen and it is fixed to 80 columns and 20 rows. I can temporarily fix it typing "stty cols 180 rows 35", but those values depend on the screen rotation, font size, etc.
This is really weird, and I wasn't having this issue before the upgrade.
Anyone else has this problem or know how to solve it?
Thanks!
Ok, i've been doing some tests.
It seems to be a 'su' bug, it is not receiving the SIGWINCH signal.
If I type without su:
trap 'echo sigwinch' SIGWINCH
It is executed every time I rotate the tablet or popup the keyboard.
But, under su, the same command is not working.
It may be a permission issue.
Any ideas?
I can confirm having the same issue with my Nexus 10 and android 4.3. As soon as I run su - from the terminal (Android Terminal Emulator) the lines start wrapping at 80 characters.
Hi,
i've been working on this trying to find a solution.
Here is what I saw:
Every time I enter su or enter chroot (i have a chrooted debian), the tty number is changed to another one. That isn't the usual tty behavior!
So, if the normal user is in /dev/pts/0 , root could be in /dev/pts/1 and chroot in /dev/pts/2.
If I rotate the screen /dev/pts/0 cols and rows are changed even if I am as root, I can verify that by typing:
stty -F /dev/pts/0 -a
But, if I am at /dev/pts/1 i'm not receiving that SIGWINCH signal. In common linux distributions, that is not happening as pts number doesn't change.
Here is my (not so perfect) solution for the chrooted debian:
Write a fix_stty.sh script as root:
#!/bin/bash
sttypath=/bin
tty0=$(ls --sort time /dev/pts/ | head -n 1 | awk '{print $1}')
stty0=$($sttypath/stty -F /dev/pts/$tty0 -a | head -n1)
rows=$(echo $stty0 | sed -e 's:.*rows\ \([0-9]\+\).*:\1:g')
cols=$(echo $stty0 | sed -e 's:.*columns\ \([0-9]\+\).*:\1:g')
$sttypath/stty rows $rows cols $cols
Save it in /usr/local/bin
Make it executable:
chmod +rx /usr/local/bin/fix_stty.sh
Add to ~/.bashrc this line:
trap '/usr/local/bin/fix_stty.sh' DEBUG
Or if you use non-root users:
trap 'sudo /usr/local/bin/fix_stty.sh' DEBUG
And add to sudoers file:
%sudo ALL = (ALL) NOPASSWD: /usr/local/bin/fix_stty.sh
Logout and login again, and it will fix the rows and columns before each command.
----
For su, outside the chrooted linux write a script fix_stty.sh:
sttypath=/system/xbin
tty0=$(/system/xbin/busybox ls -t /dev/pts | head -n1)
stty0=$($sttypath/stty -F /dev/pts/$tty0 -a | head -n1)
rows=$(echo $stty0 | sed -e 's:.*rows\ \([0-9]\+\).*:\1:g')
cols=$(echo $stty0 | sed -e 's:.*columns\ \([0-9]\+\).*:\1:g')
$sttypath/stty rows $rows cols $cols
Save it to /system/xbin
(You should remount /system as rw: mount --remount -orw /system)
Then, make it exec:
chmod 755 /system/xbin/fix_stty.sh
And, finally you should type at each su login:
trap '/system/xbin/fin_stty.sh' SIGINT
(i don't know why DEBUG isn't here)
So you have to press Ctrl+C to fix it.
----
Alternatively, you can write an infinite loop or a simple daemon to fix it, but i don't like daemons on my tablet.
If anyone has a better solutions, please post it.
Hi all. I've been mulling over this problem as well. I believe the issue is because in 4.3, SuperSU now uses a "proxy", where commands are sent form the process which called su to daemonsu, which is launched at system startup. Chainfire explains a bit more in his G+ posts the reasons for doing this, but I think the key here is that root processes are now launched on a different tty, because they are launched by a different process (namely, daemonsu). Starting a root shell (whether system shell or ubuntu/debian chroot) now results in the creation of three pts devices, as opposed to the usual one. However, other shells not launched locally are fine. For example, starting the SSH server in my chroot and logging in via SSH is always fine.
I'm still trying to figure out a permanent solution to this problem. I still don't have a full understanding of the problem as I'm still trying to wrap my head around how Linux handles terminals and TTYs. I do have a few ideas floating around my head, though:
Change daemonsu and su to support full termios/line-discipline/whatever-we-need through the "pts bridge" that he is using
Create TTY(pts) pairs on demand, and have a modified Terminal Emulator connect to those directly when we want a shell
Have a background-ed process in the original terminal catch SIGWINCH and pass it to the root terminal
Still quite a bit a figure out though. I may just go through Terminal Emulator's source code to see how it work to get a better picture too. But that's gonna take time. I've also created a little native utility which creates two pts pseudo-TTYs and shuffles data between them. I'm still experimenting. Will post more as I learn more.
Just to let you all know that I've got a system working for myself: http://blog.tan-ce.com/android-root-shell/
The way I'm doing it uses a daemon, much like the su daemons ChainFire and Koush are using. The benefit of doing it this way is that I'm not confined by the application container, which is good for security when used by applications, but is annoying when you are using the terminal itself. I remember having to do hacks with adb servers to get around those.
But if you don't want a daemon, you can still set one up manually, just look at the last section of the README on how to use pts-wrap and pts-exec.
I gave this a try.
First, I've noticed that pts-wrap and pts-exec symbolic links were missing.
And I don't think the line '/system/etc/install-recovery-2.sh' in pts-daemon-start file is needed at all.
I'm using ChainFire SuperSU and pts-shell is not working as expected or catching SIGWINCH signals. I just don't see any difference with the standard shell. Maybe I misunderstood how it works.
alf_tux said:
I gave this a try.
First, I've noticed that pts-wrap and pts-exec symbolic links were missing.
And I don't think the line '/system/etc/install-recovery-2.sh' in pts-daemon-start file is needed at all.
Click to expand...
Click to collapse
My mistake, I forgot to create the symlinks for those two.
install-recovery-2.sh is an idea I took from CharinFire's SuperSU. Basically, it seems as if people are using install-recovery.sh to install startup scripts, and having the script try to call install-recovery-2.sh allows you to chain recovery scripts. For example, if you install this on a system with SuperSU, it will be installed as install-recovery-2.sh. If the system doesn't already have an install-recovery.sh, it'll install itself as install-recovery.sh.
Anyway, I've fixed and uploaded a new zip.
alf_tux said:
I'm using ChainFire SuperSU and pts-shell is not working as expected or catching SIGWINCH signals. I just don't see any difference with the standard shell. Maybe I misunderstood how it works.
Click to expand...
Click to collapse
Are you running pts-shell from a regular (non-root) shell, or from a root shell? It should be run from a non-root shell. (It will give you a root shell once it runs.) Only pts-passwd and pts-daemon is meant to be run as root.
tan-ce said:
Are you running pts-shell from a regular (non-root) shell, or from a root shell? It should be run from a non-root shell. (It will give you a root shell once it runs.) Only pts-passwd and pts-daemon is meant to be run as root.
Click to expand...
Click to collapse
Yes, here is my the terminal output:
[email protected]:/ $ ps | grep pts
root 136 1 760 180 ffffffff 00000000 S /system/xbin/pts-daemon
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Permission denied
255|[email protected]:/ $ su pts-shell /system/bin/sh
[email protected]:/ #
As you see, I can only run pts-shell as root.
alf_tux said:
Yes, here is my the terminal output:
[email protected]:/ $ ps | grep pts
root 136 1 760 180 ffffffff 00000000 S /system/xbin/pts-daemon
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Permission denied
255|[email protected]:/ $ su pts-shell /system/bin/sh
[email protected]:/ #
As you see, I can only run pts-shell as root.
Click to expand...
Click to collapse
Sorry, I realized that the correct command should be:
[email protected]:/ $ su -c pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
(pts-shell) Enter your password:
[email protected]:/ #
Anyway I can only run this as root.
Oh yeah, I found the bug. Sorry, my bad. I've fixed it and uploaded a new copy of the update ZIP, but you don't have to upgrade if you don't want to. Running
Code:
# chmod 0701 /data/pts
should be sufficient to fix the problem. Then you should be able to run pts-shell from a regular (non-root) shell.
tan-ce said:
Oh yeah, I found the bug. Sorry, my bad. I've fixed it and uploaded a new copy of the update ZIP, but you don't have to upgrade if you don't want to. Running
Code:
# chmod 0701 /data/pts
should be sufficient to fix the problem. Then you should be able to run pts-shell from a regular (non-root) shell.
Click to expand...
Click to collapse
I don't think that was the the bug:
[email protected]:/ $ su
[email protected]:/ # ls -l /data/pts
-rw------- root root 61 2013-08-28 19:09 passwd
srw-rw-rw- root root 2013-08-28 18:59 pts
[email protected]:/ # chmod 0701 /data/pts
[email protected]:/ # ls -l /data/pts
-rw------- root root 61 2013-08-28 19:09 passwd
srw-rw-rw- root root 2013-08-28 18:59 pts
[email protected]:/ # ^D
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Connection refused
255|[email protected]:/ $
I have also tried:
chmod 0701 /data/pts/pts
And
chmod 0701 /data/pts/*
I'm getting the same connection refused. Maybe you can send me a debug version, I can run it just to find what is going on.
alf_tux said:
I'm getting the same connection refused. Maybe you can send me a debug version, I can run it just to find what is going on.
Click to expand...
Click to collapse
That's strange. Could you show me the output of ls -la? (The "a" is needed to see the permissions for /data and /data/pts itself)
After that, perhaps you could try "chmod 0711 /data/pts"
There isn't a debug version. The error message comes from the part of the code which tries to open a unix socket located at /data/pts/pts. For this to work, /data and /data/pts must have the execute bit set, and /data/pts/pts needs to have the readable and writable bit set for you. Otherwise you'll get a "permission denied".
Perhaps it might be easier for me to just move the socket to /dev like what koush does for Superuser... it's possible the permissions on my /data is non-standard.
On a side note, I'm also currently trying to contribute to koush's Superuser project to fix terminal handling. With any luck, I (or someone else?) will succeed and we won't really need my pts-multi tools anymore.
tan-ce said:
That's strange. Could you show me the output of ls -la? (The "a" is needed to see the permissions for /data and /data/pts itself)
After that, perhaps you could try "chmod 0711 /data/pts"
There isn't a debug version. The error message comes from the part of the code which tries to open a unix socket located at /data/pts/pts. For this to work, /data and /data/pts must have the execute bit set, and /data/pts/pts needs to have the readable and writable bit set for you. Otherwise you'll get a "permission denied".
Perhaps it might be easier for me to just move the socket to /dev like what koush does for Superuser... it's possible the permissions on my /data is non-standard.
On a side note, I'm also currently trying to contribute to koush's Superuser project to fix terminal handling. With any luck, I (or someone else?) will succeed and we won't really need my pts-multi tools anymore.
Click to expand...
Click to collapse
Yes, I agree that fixing su would be better.
I don't have my tablet right know, i don't remember well /data /data/pts and /data/pts/pts read and exec bits. I will see better whan I have my tablet with me.
Here is the output:
/data:
drwxrwx--x system system 2013-08-28 18:59 data
/data/pts:
drwxr-xr-x root root 2013-08-28 19:06 pts
[email protected]:/ $ ls -la /data/pts
-rwxrwxrwx root root 61 2013-08-28 19:09 passwd
srwxrwxrwx root root 2013-08-28 18:59 pts
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Connection refused
255|[email protected]:/ $
I suppose it isn't a permission problem.
alf_tux said:
I suppose it isn't a permission problem.
Click to expand...
Click to collapse
You're probably right, my Nexus 10 could be a bit different because of the semi-botched update I went through. Well, good news on two fronts: First, I updated pts-multi (latest update zip here) to use /dev/pts-daemon as the socket instead of /data... It works on mine, and I think it should work on yours, because Superuser puts its socket there too.
Second, I finished some modifications to the su binary in Superuser (source code here), and I've submitted a pull request to Koush. He says he'll do a code review of my changes, and we'll see how it goes.
tan-ce said:
You're probably right, my Nexus 10 could be a bit different because of the semi-botched update I went through. Well, good news on two fronts: First, I updated pts-multi (latest update zip here) to use /dev/pts-daemon as the socket instead of /data... It works on mine, and I think it should work on yours, because Superuser puts its socket there too.
Second, I finished some modifications to the su binary in Superuser (source code here), and I've submitted a pull request to Koush. He says he'll do a code review of my changes, and we'll see how it goes.
Click to expand...
Click to collapse
T/hanks! I tried your new update and I think it's working!
Can you add a passwordless option? Or if password is blank just don't ask for it
alf_tux said:
T/hanks! I tried your new update and I think it's working!
Can you add a passwordless option? Or if password is blank just don't ask for it
Click to expand...
Click to collapse
Ok, but I took the easiest way out... If you set the environment variable PTS_AUTH, pts-shell will read the password from there instead of prompting you for it. So, if you're writing a script to spawn a root shell, do:
Code:
#!/system/bin/sh
export PTS_AUTH="your password here"
pts-shell /system/bin/sh
The latest update zip is here.
Thanks a lot tan-ce!!
It's working just as I expected!
Glad to hear it.
Hello Everyone!
I have spent the last 4 full days trying to fix device and every road I go down leads to a dead end. At this point my frustration and exhaustion has got to the point where I am afraid to proceed for fear I will destroy my phone making the whole ordeal pointless. I will spare you all the details as they are comical at this point and try to provide only the basic information. I used the nexus 5 root kit to gain root access in order to repair an issue with my phone and this is what root checker pro said...
Congratulations! You have root access!
Super User Application Status:
SuperSU application - version 2.02 - is installed!
System File Properties for Root Access:
Standard Location
Check Command: ls -l /system/bin/su:
Result: /system/bin/su: No such file or directory
Analysis: File /system/bin/su does not exist.
Standard Location
Check Command: ls -l /system/xbin/su:
Result: -rwxr-xr-x root root 125424 1970-01-05 10:08 su
Analysis: Setuid attribute is not present BUT root user ownership is present. Root access IS correctly configured for this file! Executing this file can grant root access!
Alternative Location
Check Command: ls -l /sbin/su:
Result: /sbin/su: Permission denied
Analysis: File system permissions restricted and denied access.
Alternative Location
Check Command: ls -l /system/xbin/sudo:
Result: /system/xbin/sudo: No such file or directory
Analysis: File /system/xbin/sudo does not exist.
Root User ID and Group ID Status:
Root user id:
uid=0(root)
Root group id:
gid=0(root)
System Environment PATH: /sbin /vendor/bin /system/sbin /system/bin /system/xbin
ADB Shell Default User:
ADB shell setting for standard access, stored in default.prop, is configured as: shell (non root) user - ro.secure=1
Results provided on your Nexus 5 - Android 4.4.4 device by Root Checker Pro version 1.3.7 from joeykrim in the Android Market
If someone could provide me with instructions on how to proceed I would be eternally grateful, I have become a wash in all the information out there as well as paralyzed by it. Even better if anyone has a spare few moments having a skype buddy there while I execute the instructions would be so very comforting although I realize people have better things to do with their time.
The one good thing to come of this is I now have a keen interest in Android development and look forward to finding and taking classes so in future I am not such a lost fool.
Very grateful for any help offered,
Garrett
[email protected]
Skype ID: thisguyto
1. using fastboot, unlock your bootloader. if its unlocked, ignore this step.
2. flash a custom recovery via fastboot.
3. flash SuperSU via your custom recovery.
4. boot up with root.
no root toolkit needed.
or, read the stickie threads here on xda to get detailed instructions http://forum.xda-developers.com/goo...urce-guides-info-threads-linked-read-t2784527
I'm trying to modify the cacerts file on the system partition of a non-Google Play emulator to avoid annoying messages during development / Pen Testing on Nougat, related to an app I'm working with and I'm running into some issues. Even though I successfully copy the file to the /etc/security/cacerts/ directory and have confirmed the certificate is in the same format, its not showing as a Trusted Credential and gives a permission denied error when utilizing ls -al as a regular user (but displays fine as root). Permissions and file ownership are the same on all certificates, including mine; but my certificate shows up as "unlabeled" when I do an ls -aZl, verses all the working certificates show a label of "system_file". As a result, I'm assuming this is due to SELinux on the emulator, but I'm new to SELinux and I can't figure out what is setting that label. I utilized the following tool to convert file_contexts.bin, but nothing in there appears to reference cacerts. I'm not quite sure where to poke next.
In case it matters, and from a techniques standpoint in case anyone wants to get as far as I have in this:
I utilized Arsenal Image Mounter to mount the system.img file as writeable that was found in the following location:
%USERPROFILE%\AppData\Local\Android\Sdk\system-images\android-25\default\x86_64
Utilizing that I copied my certificate to /etc/security/cacerts/9a5ba575.0 (A copy of this cert is attached as 9a5ba575.0.txt ) . (I did this both as a copy & paste of the local file in Windows, and by duplicating an existing working certificate file utilizing a cygwin bash, and replacing the file contents. Neither method made a difference)
I then built an Android Virtual Device (AVD) and booted it up.
The command ' adb shell "ls -aZl 9a*" as non-root yields (First result is my cert, 2nd is another cert):
Code:
ls: /etc/security/cacerts/9a5ba575.0: Permission denied
-rw-r--r-- 1 root root u:object_r:system_file:s0 7537 2018-08-03 14:57 /etc/security/cacerts/9ab62355.0
The same command run as root yields:
Code:
-rw-r--r-- 1 root root u:object_r:unlabeled:s0 4246 2022-07-06 10:50 /etc/security/cacerts/9a5ba575.0
-rw-r--r-- 1 root root u:object_r:system_file:s0 7537 2018-08-03 14:57 /etc/security/cacerts/9ab62355.0
This shows my certificate is being loaded properly, but has "permission" issues. As you can tell from the ls -aZL output though, the only difference is the security label.
Thanks for your help!
Out of nowhere the screen went black and started flickering without being dropped.
I can interact with the phone via adb commands and was trying to recover data.
I ran the commands below and it's as if the /storage/emulated/0 folder is nonexistent.
Is the phone's storage permanently damaged? I can't adb backup or reset the phone since the screen does not work
I was thinking of booting twrp and using the command line to perform a backup but to my knowledge there is not a twrp image for the Pixel 5a on Android 13.
Code:
barbet:/storage/emulated/0 $ du -ms *
du: *: No such file or directory
barbet:/storage/emulated/0 $ ls -la
total 0
drwxr-xr-x 2 root root 40 1971-07-28 00:58 .
drwxr-xr-x 3 root root 60 1971-07-28 00:58 ..
barbet:/ $ ls
acct cache data_mirror etc lost+found odm_dlkm proc storage system_ext
apex config debug_ramdisk init metadata oem product sys vendor
bin d dev init.environ.rc mnt persist sdcard system vendor_dlkm
bugreports data dsp linkerconfig odm postinstall second_stage_resources system_dlkm
$ adb push file.txt /storage/emulated/0/
file.txt : 1 file pushed, 0 skipped. 1.1 MB/s (316 bytes in 0.000s)
adb: error: failed to copy 'file.txt ' to '/storage/emulated/0/file.txt ': remote couldn't create file: Permission denied
$ adb pull /storage/emulated/0/
/storage/emulated/0/: 0 files pulled, 0 skipped.
This errror msg says
Code:
adb: error: failed to copy 'file.txt ' to '/storage/emulated/0/file.txt ': remote couldn't create file: Permission denied
says all.
Your device's Android 13 does not allow ADB to access storage /data/media/0 ,
BTW:
/storage/emulated/0/ is actually /data/media/0/ exposed through an emulated / virtual filesystem, not the actual one.
I see. I have used the prior commands before on other Android versions and it did not occur to me it was an Android 13 limitation.
I have Magisk installed. Is there a way for me to grant adb root access without being able to see the screen?
The below command works on an android 11 phone but on the Pixel 5a the storage is mounted and when I click on it it unmounts.
Code:
adb shell svc usb setFunctions mtp true
first, find your .android directory on PC and backup your adbkey.pub
then use scrcpy to mirror screen to PC via adb.
Control your Android Smartphone from your PC for free with scrcpy
A new tool called "scrcpy" allows you to display your phone screen on your computer with just a USB connection and ADB. No root required.
www.xda-developers.com
Your phone is rooted, so don't reboot or do anything to get stuck in BFU state. use the power of root instead.
type su and check data is decrypted. you can list files in /data/media/0
Thanks for the replies. I was able to get a free screen replacement at Ubreakifix through an extended Google warranty. The employee was not to knowledgeable about which specific one but I think it's this one.
I tried scrcpy and it worked to enable adb shell root access.
Interestingly, the adb command to enable mtp worked when the screen was repaired.