Related
HOWTO: Disable Camera Sound (completely silent)
Without deleting anything.
Edit: As pointed out by nickbarbs, after you have completed one of the below methods, the Camera sound is controlled via "System Sounds". If you turn up, down, or off the "System Sounds", the Camera sound would be changed respectively.
This means that you can now control the camera sound at will via volume control functions.
METHOD 1
1. Create a file called "local.prop" in /data/ if it doesn't exist. Example: "/data/local.prop"
2. Open the file "/data/local.prop"
3. add the line to the file:
Code:
ro.camera.sound.forced=0
4. Reboot and all sound in the camera app is completely silent.
5. To recover the sound, you can either delete the local.prop file or change the code to:
Code:
ro.camera.sound.forced=1
METHOD 2: ADB
1. unrar the attached file "local.prop.rar"
2. copy the "local.prop" file to your ADB folder
3. ADB push local.prop /data/local.prop
4. Reboot phone.
5. To restore sound, just delete local.prop and reboot
-----
POSSIBLE BATTERY DRAIN FIX
In addition, for those who are having huge battery drains from Android OS, I also had it. On original KDD firmware, no problem at all, but after updating to KE2 with KIES, I had it all afternoon. I did a hard reset, and the battery drain seemed to go away, but I can neither guarantee or give a 100% confirmation (considering the fact that the Android OS battery usage is based on %, so if I constantly use the phone, Display goes up to 54% and Android OS drops to 10%)
Did a hard reboot by the following method:
WARNING: Will delete apps and all data; phone will boot like new phone.
1. Make sure phone is root first if you want root, and both SU and BUSYBOX installed
2. Shut down phone
3. Hold on the "UP" and "HOME" key, and press the "POWER" button for 2-3 seconds to turn on the phone (make sure to release the "POWER" key after the phone turns on, but continue holding "UP" and "HOME")
4. Select "wipe data/factory reset" and then "wipe cache partition" to remove both.
5. "Reboot system"
6. Once phone has rebooted, Root stays if properly installed, and phone starts off like new.
7. I have been using the phone since for 7 hours now, and seems better.
still have sound when focusing when taking pictures.
[email protected] said:
still have sound when focusing when taking pictures.
Click to expand...
Click to collapse
It needs to be disabled within Camera.apk
I'll look at that just now then.
Sorry; I live in Hong Kong and posted it at 2am in the morning and made a typo. It should be:
ro.camera.sound.forced=0
Will correct original post now.
kohiiou said:
Sorry; I live in Hong Kong and posted it at 2am in the morning and made a typo. It should be:
ro.camera.sound.forced=0
Will correct original post now.
Click to expand...
Click to collapse
Still not working...
mrfreddan said:
Still not working...
Click to expand...
Click to collapse
Did you reboot your phone? The changes doesn't persist till after a hard reboot.
Make sure it's also in:
/data/local.prop
And not
/data/data/local.prop
Double check to make sure you have it in the right place too and for example NOT in /sdcard/data/local.prop.
YES!! works great for me! not only that - but it follows the setting of you phone therefore
- Phone silenced = NO Camera sound at all (focus OR snap)
-Phone sound on = Camera sound with Focus AND snap
Thanks a lot dude. finally.
cheers
nick
by the way i extracted your .Rar file to my phone's SD card from my windows machine. Then i copied the file with Root Explorer to /data
= Profit
nickbarbs said:
YES!! works great for me! not only that - but it follows the setting of you phone therefore
- Phone silenced = NO Camera sound at all (focus OR snap)
-Phone sound on = Camera sound with Focus AND snap
Thanks a lot dude. finally.
cheers
nick
Click to expand...
Click to collapse
Confirmed - it's now related to the system volume.
Is possible to create tweak which enable digital zoom while recording 1080p video? Yeah, I know it is digital zoom but sometimes it would be usefull. Now zoom is possible only with 720p or less.
You need to have root for this, no?
Because I haven't rooted it yet and it doesn't work.
El Salvador said:
You need to have root for this, no?
Because I haven't rooted it yet and it doesn't work.
Click to expand...
Click to collapse
Unfortunately, yes you do.
kohiiou said:
POSSIBLE BATTERY DRAIN FIX
In addition, for those who are having huge battery drains from Android OS, I also had it. On original KDD firmware, no problem at all, but after updating to KE2 with KIES, I had it all afternoon. I did a hard reset, and the battery drain seemed to go away, but I can neither guarantee or give a 100% confirmation (considering the fact that the Android OS battery usage is based on %, so if I constantly use the phone, Display goes up to 54% and Android OS drops to 10%)
Click to expand...
Click to collapse
it works for me too! on KE1 rom, after 8 hours, battery is at 5%!
after hard reset, after 8 hours, i still have 50% battery left!
So far it looks like hard reset fixed my battery life problem too
yep same here hard reset, root still remains, all apps gone, but hey after 9hr used only 25% battery....thanks for the tip....may try the camera trick aswell later...
kohiiou said:
Did you reboot your phone? The changes doesn't persist till after a hard reboot.
Make sure it's also in:
/data/local.prop
And not
/data/data/local.prop
Double check to make sure you have it in the right place too and for example NOT in /sdcard/data/local.prop.
Click to expand...
Click to collapse
When you say hard reboot, do you mean reset back to factory settings or turn phone off completely then turn on again??
sheridan2000 said:
When you say hard reboot, do you mean reset back to factory settings or turn phone off completely then turn on again??
Click to expand...
Click to collapse
The latter - don't confuse hard reboot with hard reset
Summered said:
The latter - don't confuse hard reboot with hard reset
Click to expand...
Click to collapse
Thanks....just pushed the file...thought that it did not work but noticed that you have to turn off all sounds inorder for camera sounds to turn off as well. When sound is on then camera sounds are back.
Great.
works like a charm! both focus and snap sound are now disabled on silent mode. thanks=)
How do you detect if you have the Battery Drain Issue?
Battery Usage stats?
NOTE:
If you came here looking to fix recent problems with LoS in recent builds of Jelly Bean, be aware that this utility has not been tested with JB or ICS at this time. I figured LoS was a solved problem, so retired the project. I'm looking into it again, and may have something out later depending on how much has changed in the OS updates.
Introduction
Has your phone ever had a circle with a line through it instead of signal bars? Has your phone ever shown signal bars, but all calls and texts fail until you reboot? Well, those situations are called Loss of Service, or LoS, and while we can't actually stop them from happening yet, those situations can be detected and repaired. The Loss of Service Daemon (LoSD) does that, so you don't have to!
It does this by:
Restarting problematic radio daemons when detected.
Rebooting when all attempts to fix have failed.
In addition, it can create a log dump of various system logs for debugging purposes.
Requirements
Phone must be rooted.
An init.d compatible kernel.
Busybox must be installed.
Many ROMs and custom kernels do this automatically, but check the feature of your basic tool-chain before installing.
Installation
All files are located in my github projuct, if you'd like to get a closer look at how all LoSD works. But what you really want to to know:
Download LoSD
This will be a file you can flash using ClockWorkMod. Simply copy it to your internal or external SD card, reboot into recovery, and flash. The next reboot will be running LoSD.
NOTE : Installing LoSD will automatically remove -viperboy-'s LoSChecker, as they should not both run at the same time.
Download LoSD Uninstall
The above package will fully remove all traces of LoSD from your phone. Flash if you're having problems or no longer need/want LoSD.
WARNING! Do not wipe anything before or after install of this utility! It is not a ROM. You will be left with an unbootable system.
Usage
If you installed the flashable zip, your phone will automatically launch the LoS daemon at every boot.
Or you can call it manually to obtain debugging logs!
Code:
LoSD dump
When called with the 'dump' command, LoSD will dump all debugging logs and exit, creating a timestamped directory in LOGPATH (/data/local/LoSD by default), as well as a tar archive named logs.tar.gz. This lets you capture situations where LoSD did not detect a LoS, and send the logs for analysis.
Frequently Asked Questions
These are taken from the README file that gets installed with LoSD. There's more dev-related info in that file, so give it a look!
Q: Will this restart the radio or the phone if I lose 4G?
No. 4G is actually a separate radio from the CDMA radio used for texts and phone calls. This script ignores the 4G radio entirely and can not trigger no matter what happens to the 4G radio.
Q: Will this restart the radio or the phone if I'm using WiFi?
No. Turning on WiFi *will* disable your 3G data, but will leave the CDMA radio in an available state so you can still receive phone calls and texts. The LoS daemon knows the difference, so feel free to use your WiFi as you please. LoSD may restart your radio while you're on WiFi, but only because your CDMA radio stopped responding and you wouldn't have received any texts or phone calls if it didn't try and fix the radio.
Q: Where do I find the logs?
Logs produced when the radio is restarted, or the phone is rebooted, are stored by default in /data/local/LoSD in a directory time and date stamped for when the fix was attempted, or a reboot was triggered.
Q: Help! My log directory is getting huge!
By default, LoSD will not dump system logs when it repairs a LoS. But you may have enabled it on your own if you modified the configuration file. If you're in a spotty coverage area, the log directory may start to fill with several timestamped log dumps, each of which are around 5MB. If you'd like to stop this, please ensure your LoSD.ini configuration file does not contain the following line:
Code:
DUMPLOGS=1
Such a line will enable log dumping, which again, is disabled by default!
Q: I think I have LoS the daemon didn't detect. How do I get logs?
Very easily! LoSD has a built-in logging command! Just type this into a terminal, or an 'adb shell':
Code:
su
LoSD dump
This will create a timestamped directory just like LoSD had detected it. In addition, a file named logs.tar.gz will be dropped in your LOGPATH directory (that's /data/local/LoSD by default) you can send to us. We recommend putting it in dropbox, or some other binary-file hosting site.
Credits
Many thanks to -viperboy- for the original concept of checking for LoS with a script.
HaiKaiDo gave us the idea of restarting the radio daemon before rebooting.
If I'm forgetting anyone, please PM me!
Configuration
There are several settings you can apply to the LoS daemon while it's working. These settings should be placed in a file named LoSD.ini in the /data/local/LoSD directory of your phone. If you change any settings, you must either restart the daemon, or reboot your phone.
Currently recognized settings:
DEBUG
Many log entries are only informative in nature and can be very noisy. If you are having trouble and want to see LoSD activity reported in the system logs and LoSD.log, set this to 1. Default is 0.
DUMPLOGS
Whether or not logs should be dumped during a LoS repair or system reboot. Should be 0 for false, or 1 for true. Default is curently 0.
LOGPATH
Full path to where logs should be dumped. This is also where LoSD keeps its own LoSD.log file. Default is /data/local/LoSD because the daemon knows that directory exists. Feel free to place it somewhere on your SD card. If this directory does not exist, LoSD will attempt to create it for you. Please make sure the path is writable!
RESTARTS
How may times should the daemon attempt to restart the radio before giving up and initiating a system reboot. Default is 2. This setting was primarily defined because ghost LoS can sometimes degrade into full LoS, and subsequent radio restarts may be necessary to regain service.
RESTART_LIMIT
How many successful radio restarts before LoSD considers the phone state tainted? Too many RILD restarts may damage other services, or cause other unknown side effects. After this limit is reached, further LoS events will not result in an RILD restart, but a full reboot. Default is 3.
SLEEP
How long to wait between radio checks, in seconds. Default is two minutes.
Example:
Code:
LOGPATH=/sdcard/los
RESTART_LIMIT=1
Again, if these settings are changed, you must either restart the LoS daemon, or restart the phone. To restart the daemon, execute the following in an ADB shell or terminal:
Code:
su
killall LoSD
nohup LoSD &
The 'nohup' is there to prevent the command from attaching to your TTY, so you can disconnect without your session hanging. Feel free to omit this if you were just going to close your TTY.
Change Log
Version 1.3.1
Added third Airplane mode check for ICS firmwares.
Third firmware check also works on phones with disabled logcat.
Version 1.3.0
Improved CDMA connection FAILED detection.
Added second Airplane mode check for EL13, EL26, EL29 firmwares.
Version 1.2.0
Added debug log level.
Moved several informative messages to debugging only.
Debugging is now disabled by default.
Tweaked RILJ error detection for RIL_REQUEST_CDMA_GET_SYSTEMPROPERTIES.
Can now ignore false positive ghost LoS caused by phone calls.
Phone call and Airplane mode now checked before anything else.
CONNECTING status no longer skips LoS check.
Added ghost LoS check for CDMA 'Unknown data error' messages.
Version 1.0.0
Log dumping is now disabled by default.
Now uses 'setprop ctl.stop/ctl.start' to try restarting RILD nicely.
Does a quick check to prevent multiple running copies.
Added a radio restart limit to avoid glitchy post-fix systems.
Clear radio log in case of false positive ghost LoS.
Version 0.9.0
Added non-LoS check for transient CONNECTING status.
Now check for ghost LoS *after* standard LoS.
Calling LoSD with 'dump' now dumps and tarballs all debugging logs.
Version 0.8.1
Fixed bug in grabbing bugreport dump.
Now removes -viperboy-'s LoSChecker on install.
Removed LoSD logcat dump in favor of persistent LoSD.log.
Version 0.8.0
Now maintains a separate log for tracking all LoS events.
Added DEBUG configuration setting.
Version 0.7.1
Fixed typo in AirplaneMode check. Should no longer reboot in airplane mode.
Version 0.7.0
Fixed bug in radio log dump.
Now tries multiple times to restart RILD before reboot.
Added DUMPLOG as boolean to disable / enable log dumps
Added RESTARTS as number of RILD restart attempts before reboot.
SLEEP, LOGPATH, DUMPLOG, and RESTARTS are now user configurable.
Now searches for /data/local/LoSD/LoSD.ini for config settings.
Version 0.6.0
Initial public release
Good deal, the more people working on this the better and I know viperboy had a lot of work going. I'll give your version a go today.
Sent from my SPH-D710 using xda premium
Just_s said:
Good deal, the more people working on this the better and I know viperboy had a lot of work going. I'll give your version a go today.
Click to expand...
Click to collapse
Haha. Thanks. The way I see it, Viper has his hands full with way more important projects right now. With his ROM, the EK02 pull, the ICS work... why should he have to worry about this too? He was going to rewrite his script anyway, so I just took the opportunity to do it while he was distracted being useful.
While I was at it, I just... added a few things. That's all.
installing now.. thanks for this, and thanks viper
How about an option that appends to a file a date and time that the los happened instead of the full log? How about a notification after it fixed a los? The viper script made the phone appear like I never have los. Good but I still would like to know how often it happens.
gedster314 said:
How about an option that appends to a file a date and time that the los happened instead of the full log? How about a notification after it fixed a los? The viper script made the phone appear like I never have los. Good but I still would like to know how often it happens.
Click to expand...
Click to collapse
I can do the feature to keep a running tally of LoS, but so far as I can tell, there's no way to send notices from the command line. If there is, I can't find it. Sorry.
Sent from my SPH-D710 using xda premium
Question... Do I need to be uninstalling this script everytime I update, or just flash over the old? -Grand
Sent from my SPH-D710 using XDA App
grandmastem said:
Question... Do I need to be uninstalling this script everytime I update, or just flash over the old? -Grand
Click to expand...
Click to collapse
Just flash it over the old one. I've made the install smart enough to install over previous versions of LoSD. If you're running -viperboy-'s LoSChecker, you should run his uninstall first, though.
Also:
Edited OP to reflect new 0.8.0 version. Added a setting to suppress the Info-level log messages. Now it also keeps a LoSD.log in the LOGPATH directory so you can keep a log of its activity between reboots without having the log dumping enabled.
I also updated the Configuration and Change Log sections.
After u install it wat u do to run it or do it run on its own
Sent from my SPH-D710 using xda premium
pats4life100 said:
After u install it wat u do to run it or do it run on its own
Sent from my SPH-D710 using xda premium
Click to expand...
Click to collapse
It runs on its own.
Is this JarJar Binks?
Sent from my SPH-D710 using xda premium
Just_s said:
It runs on its own.
Is this JarJar Binks?
Sent from my SPH-D710 using xda premium
Click to expand...
Click to collapse
+1 sir.....+1.......
Also thanks for the shoutout trifthen! Nice work
Giving this a go. I'll report in with anything that seems odd. I definitely get LoS on occasion, and the girlfriend doesn't approve haha.
trifthen said:
I can do the feature to keep a running tally of LoS, but so far as I can tell, there's no way to send notices from the command line. If there is, I can't find it. Sorry.
Sent from my SPH-D710 using xda premium
Click to expand...
Click to collapse
Trifthen, I'm glad you took this over cause I had alot of other stuff going on. If I see any enhancments, I will send them your way. Also, you have my permission to include the line in your updater-script to remove my LoSChecker because I don't want it to affect users who use yours and don't uninstall mine. Just add this into your updater-script:
Code:
delete("/system/bin/LoSChecker");
And you can also add a line to remove my logs as well if you want. The files might be taking up a good bit of space...
Code:
delete_recursive("/data/local/LoS");
Those should be right, I'm at work so I'm typing from memory
For counting when LoS happens, you could just write a timestamp or something else into a file (>> adds into a file, > overwrites any data in a file) and then just do a wc on it (-l option reads lines, I think) which would give you the number of times that you had LoS from reading the amount of lines in the file. Just a thought.
Yay no more this ****
Sent from my SPH-D710 using xda premium
-viperboy- said:
Trifthen, I'm glad you took this over cause I had alot of other stuff going on. If I see any enhancments, I will send them your way. Also, you have my permission to include the line in your updater-script to remove my LoSChecker because I don't want it to affect users who use yours and don't uninstall mine. Just add this into your updater-script:
Code:
delete("/system/bin/LoSChecker");
Code:
delete_recursive("/data/local/LoS");
Click to expand...
Click to collapse
Thanks man. I'll do that. I'll be waiting in anticipation for those enhancements. I actually just got a reboot following a ghost LoS where I couldn't send any texts. It couldn't restart the radio, and boom. The best enhancement we could get is to have no need for this utility. Heh.
... and then just do a wc on it (-l option reads lines, I think) which would give you the number of times that you had LoS from reading the amount of lines in the file. Just a thought.
Click to expand...
Click to collapse
Yep. The new /data/local/LoSD/LoSD.log is basically everything it sends to the system log, so it's like a mirror that persists after reboots, unlike the system logs. In addition, you can turn off those pesky "Radio appears normal - no LoS." information messages by setting DEBUG=0 in the config file.
I just found a cut-n-paste bug in the line that dumps the bugreport, so I may just add the lines that remove LoSChecker along with that fix.
Thanks again, Viper!
Is anyone else running a hacked PRL and running into issues like I am?
EDIT: Rebooted manually, held up at splash screen, weird series of beeps and now back up....running Blazer v.12 on EG31.
DizDroid said:
Is anyone else running a hacked PRL and running into issues like I am?
Click to expand...
Click to collapse
Well, if your hacked PRL is the 000000 one that puts you permanently on Verizon, that might be an issue. I noticed the phone killed my radio about 6 times today around the same 20-minute period while I was right on the edge of Sprint service and kept roaming on and off. I was standing in line for lunch in a building that's not nearly as tall or as deep as where I work, yet it was driving my radio nuts. LoSD's ghost LoS checks triggered multiple times, so I have plenty of logs to work with now so I can revise the check to be a little less overzealous.
I can't say for sure, but forcing yourself to roam may have a similar effect. Take it with a grain of salt.
trifthen said:
Well, if your hacked PRL is the 000000 one that puts you permanently on Verizon, that might be an issue. I noticed the phone killed my radio about 6 times today around the same 20-minute period while I was right on the edge of Sprint service and kept roaming on and off. I was standing in line for lunch in a building that's not nearly as tall or as deep as where I work, yet it was driving my radio nuts. LoSD's ghost LoS checks triggered multiple times, so I have plenty of logs to work with now so I can revise the check to be a little less overzealous.
I can't say for sure, but forcing yourself to roam may have a similar effect. Take it with a grain of salt.
Click to expand...
Click to collapse
Thanks for the reply, keep up the great work. If I wasn't trying so hard to get out of my Sprint contract I'd ditch the .000000000000000000000000000 in a heartbeat.
I did a basic search of the GNex section of the forum and didn't find any conspicuous information, thus I wanted to see if anyone had any suggestions for dealing with the "debuggerd" system process.
I have a yakjuux 4.0.4ota with franco-kernel milestone3. I started with 4.0.1 and no mods, upgrading to the 4.0.x otas as they came out. I have had this phone about 4-5 months now. I have been rooted and unlocked since I have had 4.0.1.
Not exclusively to the 4.0.4 nor the franco-kernel I have noticed a process "debuggerd" running on my phone. rcently, twice in a day I found that process consuming 30+% of the cpu, causing a sudden drain in my battery. Prior to 4.0.4 I had not gathered any empirical data as to how much debuggerd was consuming, but did have times when the battery would radically drain, and I did notice debuggerd running.
I was able to launch a shell on my phone and kill the process-id for debuggerd at which point cpu load would drop instantly.
I tried freezing (via Titanium) many of my apps that would use data or were running at the time of the high cpu load (I wasn't sure if that would free up what triggered the process, just thought it was worth a try). I turned off a lot of software (eg. tasker, alarmapps, etc). As I froze/disabled apps en masse it was still using up the cpu. I tried killing apps from within watchdog. Still debuggerd would maintain a high cpu load. A reboot did get rid of it once, but in that session it did come back. Played with the USB debugging mode. I didn't reboot between many of these test.
I'll continue to kill it's pid if it shows, which the signs are really obvious in watchdog app (set my system warning low enough to catch it). I'm just familiar with the problem now.
* Any suggestions on tracing what's triggering debuggerd?
* Thoughts on alternative methods to prevent it from being used?
* I doubt deleting that bit of software is a good idea, right?
* Substitute it with something inert?
* Maybe I should create a button that gets it's pid and kills it?
Thoughts?
I found a shell script on http://en.androidwiki.com/wiki/Android_Shell_tips_and_tricks
It finds the pid by name - which is handy since pid's can be random.
I can run the shell script with SManager (which can provide the shell script any required arguments) from the phone desktop without having to go into the console.
It's a bandaid but it works. I can quickly and easily kill the (or any) errant processes that are not apps.
#!/system/bin/sh
# usage: kill "/full/command/line -with arguments"
for file in /proc/[0-9]* ; do
cmd=$(cat $file/cmdline)
iseq=${cmd%$1}
if ! ( (echo ${cmd:?}) > /dev/null 2>&1) ; then
continue
fi
if ! ( (echo ${iseq:?}) > /dev/null 2>&1 ) ; then
kill -9 ${file#/proc/}
fi
done
I share the same problem. debuggerd is cpu hog.
I dont want to kill it as it is not normal in my case. It has been lasting for more than an hour with high cpu usage.
I am using franco kernel 158 and Samsung GNexus ROM 4.0.4 IMM76K.
any help would be appreciated. Thanks.
mcdull said:
I share the same problem. debuggerd is cpu hog.
I dont want to kill it as it is not normal in my case. It has been lasting for more than an hour with high cpu usage.
I am using franco kernel 158 and Samsung GNexus ROM 4.0.4 IMM76K.
any help would be appreciated. Thanks.
Click to expand...
Click to collapse
McDull,
I'm not sure what you mean by you don't want to kill it. Regardless, you could kill the process (not via any task manager, since dubuggerd isn't an app to force-stop). If you do want to stop it you could manually one of a couple ways.
On the phone by hand:
I'm assuming you have root and su access.
From google-play download:
--- "Top" (by Junichi Uekawa).
--- "Android Terminal Emulator" by Jack Palevich.
Use Top to find out what the process id# for debuggerd is.
Open Terminal Emulator:
--- I can't remember if you need "su" powers, I always enter "su" mode tho.
--- Execute a kill of the pid: kill xxxxxx
Switch to Top, see if the debuggerd resets itself. Kill again if necessary
You can do all of the above via adb shell from your computer too.
Somewhat more automated:
From google-play download "SManager" (script manager) by devwom.
Write a shell kill script like in my first post.
Using smanager you can create a desktop icon that executes the kill command.
(I'm glossing over the details a lot because I'm at work and didn't have time to write in depth smanager instructions to do this. sorry!!)
I know my phone is deepsleeping, but for some reason, when i try to wake it, it would take up to a minute for any response, on top of that I found that android OS is using about 40% of my battery, used Android tuner( the one that requires xposed framework) to see, and it turns out that the battery drain was caused by the android os, "sh" thread.
Any ideas to fix this?
MinChains said:
I know my phone is deepsleeping, but for some reason, when i try to wake it, it would take up to a minute for any response, on top of that I found that android OS is using about 40% of my battery, used Android tuner( the one that requires xposed framework) to see, and it turns out that the battery drain was caused by the android os, "sh" thread.
Any ideas to fix this?
Click to expand...
Click to collapse
"sh" = shell
It seems that something installed on the phone is starting shell (it's a text terminal) in a background and not stopping it. It may be a broken script installed in /etc/init.d or some app that is broken. The worst case scenario is a malicious program that resides in background to do something (not very probable). It will be hard to find the cause as "sh" is a part of the system - please try to correlate the beginning of the problem to installation of some program. Try to use Teminal Emulator and issue the command "su", press enter, write "top -n 3" and enter, to list all tasks running in the system. Scroll up to check column headers, find CPU% and by that locate this rouge "sh" process. Look in column UID to find who has started it (user id). Post your search result.
Found it pid 32444 bu doesnt really help as i can lt find it activitymanager.runningappprocessinfo
Any idea what this is?
32444 2 24% R 1 896K 428K root /system/bin/sh
Rebooted, pid changed to 4790
Update:
After i killed this prpcess, swapoff takes over and causes an i/o storm for abour 2 mins then system ui and surfaceflinger uses about 30% and 20% cpu respectively it doesnt go down even after 5 hours.
Using agni kernel for 4.3 btw patched to fix network error
What cpu governor are You using?
Try to set ondemand.
Sent from galaxy n7105
My setup is a Oneplus 3 with OOs 5.0.1 with TWRP, Magisk and Franco Kernel. Naptime and Servicely are two other installed apps that interferes with the normal system behaviour.
My phone randomly reboots two to four times a day, whenever that happens sometimes the booting completes (with longer than usual times), other times it stay stuck at the boot animation and I have to manually shut it down and power it on repeating the whole process till I get a successful boot.
Some suggested to look at the logcat but from my understanding using a logcat viewer, the log starts from the boot so I can't tell what happened before the reboot.
Before proceeding with a trial and error approach by removing everything (the kernel, apps and magisk) is there a smarter and more efficient way to tackle down what's happening?
I will try to use a terminal emulator app to run in background 'logcat -f myfile.txt' but since I down know when the next reboot will happen the file might get HUGE.