Hi at all here on the forum,
I have a quite rather frustrating problem. When I am trying to replace the fingerprintd binary in /system/bin the service can not be started again, resulting in a not functioning fingerprint sensor.
Not only when you try to replace it, simply removing the original fingerprintd file (eg. to the sdcard) and putting the original file back at /system/bin can not be started again.
I have tried to set the UID, GID right ("chown 0:2000 fingerprintd"), give the right file permissions ("chmod 755 fingerprintd"), but it will not start on its on or when you execute it manually.
Further I have tried to stop the service before i replace the file and then start it new, with the commands
"stop fingerprintd" and then "start fingerprintd". Didn't had the desired effect of starting the fingerprintsensor service.
For an example when you stop the gatekeeper daemon ("stop gatekeeperd"), you are not able to log in in your phone obviously, with "start gatekeeperd" it is possible again.
Unfortunately this behaviour can not be reproduced with the fingerprint daemon.
Another thing is when you kill the process ("kill [PID of fingerprintd or gatekeeperd]") the process will start automatically again, without doing anything, as long as it is the original binary and it hasn't moved around on the phone. A modified binary will not be started automatically.
How can I get android to restart the original fingerprintd service or even a modified version of fingerprintd?
for modifying I use
"adb shell" in the shell "su" then "mount -o rw,remount /system" to make the /system partition read and writable, and then I am copying the modified binaries from the sdcard
Device =LG Nexus 5X
Android =7.1.2
Build Number = N2G47Z
SuperSU Version = SuperSU-v2.82-201705271822.zip
TWRP Version = twrp-3.1.1-0-bullhead.img
Thanks for answers in advance!
try by using the service name "fingerprint" instead.
Related
To start with, I have a rooted Pantech Pocket that was running Carrier IQ and that is where the problem started.
I found there were 3 files that were associated with Carrier IQ. One in system/bin and two in system/lib and I moved the one from system/bin without any problem but when I moved the two from system/lib I ended up with a phone that gives me error message after error message after error message and all the errors say: "The process com.android.phone has stopped unexpectedly. Please try again."
To make a long story short those error messages pop up so quickly I can not use the "MENU" or a "Long press" anymore and I have to use "Button Savior" to use the "Back" or the "Home" buttons. Note: even though Button Savior is given superuser access the "Menu" key still does not do anything.
I can not use ES File Explorer because I can't get into the menu to set it up as a "Root Explorer" since there is no way I can get the "MENU" key pressed and I tried several different programs too.
I can not use Root Explorer because I can not use a long press since that error message cuts the long press short.
I also tried the following set of commands to try and push the two files into the lib folder but ended up with an error message there too.
adb devices
adb push psneuter /data/local/tmp
adb shell
$ cd /data/local/tmp
$ chmod 777 psneuter
$ ./psneuter
Then the error message I received was:
failed to set prot mask (inappropriate ioctl for device)
UPDATE AFTER PUTTING THE TWO FILES BACK INTO /system/lib
Turns out because my Pantech Pocket was still rooted all I had to do was type "adb shell" on one line and then after getting the '$' type "su".
After that I had to use the following command so I could copy two files back into /system/lib:
mount -o remount,rw -t rfs /dev/block/st19 /system
Then after changing the permissions the cp (copy) worked without any errors and I put the two files I had moved out of /system/lib back into /system/lib.
I learned a lot from trying to get rid of Carrier IQ and had to put carrier IQ back on the Pantech Pocket to make it usable. Dang AT&T but maybe there is something else I can do about Carrier IQ.
Roger
Hello everyone,
I have a T-Mobile L9 Optimus and I have rooted it according to this guide, it was very helpful
http://forum.xda-developers.com/showthread.php?t=2173465
After removing a bunch of bloatware, I also wanted to remove T-Mobile's Boot and Shutdown animations, which on this phone are located in system/media -> bootanimation.zip and shutdownanimation.zip
I used ADB to pull both files into Windows as a backup
Then, I used ADB to open a shell as su:
adb shell
su
Then I realized I couldn't use the rm command for those zip files because the /system folder is mounted as read-only by default. To change that I used the following commands:
mount -o rw,remount /system
then I used the rm command to remove the two zip files
then I used
mount -o ro,remount /system
to have the folder back in its default read-only state
Then I restarted my phone and voila - no shut-down animation and only a default LG and Android animation on startup
Then I re-started Command prompt to get back to ADB (I still don't know how to exit shell and get back to ADB, help on that?) and here's the problem - I can no longer access root permission in ADB.
When I type in adb root, I get "adbd cannot run as root in production builds"
When I type in adb remount, I get remount failed: Operation not permitted
If I open a shell, I can still enter su, but after the procedures above, ADB thinks that my phone is a production build and I would like to know why, and how I can fix it without returning the original bootanimation.zip and shutdownanimation.zip files.
Is there a background process on T-Mobile phones that goes through a default checklist of system files, then determines that a phone must be a production build if some of those files aren't there? Is there a way to modify that process if it exists? I would rather do that than have to put in a "dummy" bootanimation.zip and shutdownanimation.zip
Lastly, if I were to return those original files through shell, would everything return to normal regarding ADB?
So adb shell and su doesn't work for you now ?
Edit:
I missed a part of your post,
That is a normal behaviour. I don't thing you could adb root before removing animations.
Edit:
If you want to run something from command prompt you have to:
adb shell su -c command_goes_here
I am having a hard time getting certain interactive features of any shell to work with Android Terminal Emulator as soon i acquire superuser privileges by issuing the "su" command. I am no longer able to cycle through the command history which is otherwise done by pressing the volume down key (provided you have the vol. down key bound to the Ctrl key via Terminal Emulator's settings) and then the p key. It will simply display the "^P" control sequence instead of displaying the last entered command. It only becomes an issue once the su command is entered. Does anyone know of any possible workarounds?
bsimpson1 said:
I am having a hard time getting certain interactive features of any shell to work with Android Terminal Emulator as soon i acquire superuser privileges by issuing the "su" command. I am no longer able to cycle through the command history which is otherwise done by pressing the volume down key (provided you have the vol. down key bound to the Ctrl key via Terminal Emulator's settings) and then the p key. It will simply display the "^P" control sequence instead of displaying the last entered command. It only becomes an issue once the su command is entered. Does anyone know of any possible workarounds?
Click to expand...
Click to collapse
Quick answer: install Chainfire's SuperSU and don't look back
Just saw this post searching for some terminal stuff and had to reply cause this was driving me crazy trying to figure it out / fix it. The issue is with the CWM su binary. I never could exactly figure out the exact problem, and I wasn't willing to grep through its source code. I know that the permissions weren't (still might not be) configured correctly at installation. /system/xbin/su should be -srwx 06755 and Owner:Group 0:0 aka root:root at installation but the -s--- 06000 sticky-bit should not persist after installation and remounting /system, i.e., /system/xbin/su should be -rwx 0755 in the AOS. CWM's su has been re-chmod'ing the user-specific sticky-bit when I try changing it.. I'm pretty sure this is at least part of the problem with console/shell/terminal output not being (re)directed correctly with CWM-su executed processes.
Another thing to mention is the "security context" (SELinux additional file permissions) which labels the file with an "object" and "role" among other things. I know that it's set correctly during installation with SuperSU, but I didn't see a command for it in the installation zip's script for CWM-su NOV-17-beta. I'm never really sure what's going on with CWM's giant su binary these days lol This is a pretty important permission setting not to forget, especially if you're running enforced SELinux which is Android 4.4's SELinux' default security. Note: SELinux denies unconfigured files by default, and otherwise configured only allows minimum access to function when called. It then makes sense that if su doesn't have the correct security context, then it's children, shell executions might not either.
So I'm pretty sure the shortcuts (ctrl + c,x,z; esc + ...) stopped functioning correctly as a results of one or both of these issues. I checked almost all the suspects like libncurses.so (cursor library), libjackpal*[2-4].so (term library for execution of scripts), other terminals (same results in: better terminal emulator, connectbot, connectbot VX, Script Manager, JuiceSSH, Server Auditor, and a fresh Terminal IDE installation - could just take over the system with this beast if I had time). The ONLY place CWM su'd cursor works is recovery, flashing AromaFM. There's no SELinux here in this bootstrapped utopia of simplicity.
Chainfire's SuperSU recovery-installation-zip does all of the above mentioned correctly, so the cursor works everywhere(includes su binary and Superuser, and it yields complete removal of CWM's superuser files), the security context that's set to su, deamonsu, *all files that are added or modified* during installation is ubject_r:system_file:s0 via
Code:
chcon u:object_r:system_file:s0 file
. Also you can check SELinux security context with id -Z or maybe ls -Z, depends on those binaries and whether called by busybox, etc..
edit: CWM's su actually isn't used in TWRP; a supersu package is used
7175 said:
Quick answer: install Chainfire's SuperSU and don't look back
Just saw this post searching for some terminal stuff and had to reply cause this was driving me crazy trying to figure it out / fix it. The issue is with the CWM su binary. I never could exactly figure out the exact problem, and I wasn't willing to grep through its source code. I know that the permissions weren't (still might not be) configured correctly at installation. /system/xbin/su should be -srwx 06755 and Owner:Group 0:0 aka root:root at installation but the -s--- 06000 sticky-bit should not persist after installation and remounting /system, i.e., /system/xbin/su should be -rwx 0755 in the AOS. CWM's su has been re-chmod'ing the user-specific sticky-bit when I try changing it.. I'm pretty sure this is at least part of the problem with console/shell/terminal output not being (re)directed correctly with CWM-su executed processes.
Another thing to mention is the "security context" (SELinux additional file permissions) which labels the file with an "object" and "role" among other things. I know that it's set correctly during installation with SuperSU, but I didn't see a command for it in the installation zip's script for CWM-su NOV-17-beta. I'm never really sure what's going on with CWM's giant su binary these days lol This is a pretty important permission setting not to forget, especially if you're running enforced SELinux which is Android 4.4's SELinux' default security. Note: SELinux denies unconfigured files by default, and otherwise configured only allows minimum access to function when called. It then makes sense that if su doesn't have the correct security context, then it's children, shell executions might not either.
So I'm pretty sure the shortcuts (ctrl + c,x,z; esc + ...) stopped functioning correctly as a results of one or both of these issues. I checked almost all the suspects like libncurses.so (cursor library), libjackpal*[2-4].so (term library for execution of scripts), other terminals (same results in: better terminal emulator, connectbot, connectbot VX, Script Manager, JuiceSSH, Server Auditor, and a fresh Terminal IDE installation - could just take over the system with this beast if I had time). The ONLY place CWM su'd cursor works is recovery, flashing AromaFM. There's no SELinux here in this bootstrapped utopia of simplicity.
Chainfire's SuperSU recovery-installation-zip does all of the above mentioned correctly, so the cursor works everywhere(includes su binary and Superuser, and it yields complete removal of CWM's superuser files), the security context that's set to su, deamonsu, *all files that are added or modified* during installation is ubject_r:system_file:s0 via
Code:
chcon u:object_r:system_file:s0 file
. Also you can check SELinux security context with id -Z or maybe ls -Z, depends on those binaries and whether called by busybox, etc..
Click to expand...
Click to collapse
Thanks for such a detailed reply. It's nice to know that the problem wasn't on my end. I can finally stop desperately editing my bashrc file, adding all sorts of obscure environment variables and crossing my fingers.
bsimpson1 said:
Thanks for such a detailed reply. It's nice to know that the problem wasn't on my end. I can finally stop desperately editing my bashrc file, adding all sorts of obscure environment variables and crossing my fingers.
Click to expand...
Click to collapse
Man I'm right there with you. lol yeah my 1MB of cursor-fix bashrc and mksh edits are now resting in peace, blasted that tar.gz coffin out to space with my "working-key-signal" su'd ssh terminal the other day like Spock in The Wrath of Khan, oh yeah. I'm glad to know I wasn't the only person who cared about this so much.
Hi, I'd like to ask a general question (I suppose) about device boot process. I've made some changes in init.rc and I packed again boot.img. Then I flashed it. So, phone shows logo screen. I've changed boot.img again to enable adb by making changes to default.prop.
So, I've packed boot.img and flashed it again. So, phone shows logo screen and I can use adb during boot process, but I don't know how to use adb to get info about android failed boot (adb has not root permissions, though).
What methods could I follow in these cases? Any ideas?
P.S.
My changes at boot.img: I've moved /system, /usrdata and /cache mount commands into an .sh script in ramdisk root directory.
P.P.S.
I've tried also adb pull last_kmsg and I don't see error messages in the little log (~87 kb). When I look at last_kmsg, I see some lines about phone charging (connected to pc), so I think these messages could be related at the moment which phone is connected to pc but turned off (I'm not sure, though) because last_kmsg is related to previous boot process (charging mode with phone turned off?) and the current one (I think). I'd like to read kmsg and not last_kmsg, however, but kmsg can be read only by root (and my current adb has not root permissions, as I said before).
P.P.P.S.
During the boot process, I can pull directories and files from ramdisk root directory (related to boot partition) into my pc by using adb pull command. I've found that 'dev', 'proc' and 'sys' are very well populated of files and sub-directories. Instead, 'data' and 'system' directories are sadly empty. So, I suppose /usrdata and /system related partitions are not mounted at that moment and such thing prevents to load android system.
Solved
I've found a way to get dmesg without using adb shell. It's possible to use busybox dmesg command inside a shell script (placing busybox binary and shell script into ramdisk root directory of boot.img) and run the script by busybox ash command from init.rc, redirecting the output to a logfile. The command inside shell script should look like as the following:
Code:
/busybox dmesg >> /path/to/my/logfile.txt 2>&1
(That way, stderr and stdout will be redirected to a log file, that can be pulled down by adb pull command)
Hi, I'd like to ask a general question about busybox. I've added busybox binary into ramdisk root directory of boot.img. I've set busybox binary permissions to 0777 in init.rc, in order to be sure not getting any denied permissions issues.
I've put an exec command into init.rc for using busybox cp and it worked because it really made a copy of default.prop in ramdisk root directory. I've also put a start service line into init.rc That service is essentially a busybox sh call for launching a shell script. Unfortunately, it seems shell script is not executed because some cp and echo commands which I put inside it have not effects.
Looking for around the www, it looked like redirection ('>', '>>', ...) is not prohibited by busybox. So, i've also tried to redirect
command output to a file, but file was not created.
So, how could I debug busybox? Any ideas?