Sometimes locks screen sounds stop working. I don't know why and how they do, but you can fix it it with restarting audioserver, killing the audio server will do, since some daemon? will restart it. You have to be root.
Code:
# pkill -u audioserver
A captured logcat line while the problem is active:
AudioFlinger could not create track, status: -12
Looking for clues about the issue, why does it happen? How to fix it? How to prevent it?
You may dump some logs with this command to investigate, more info: https://source.android.com/devices/audio/debugging
Code:
# dumpsys media.audio_flinger
Related
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!!)
Hi,
I recently gave my KF to my little nephew to play games with, he took a little break and after returning to the tablet found my screen pattern to be a game as well. Anyways, it now tells me "too many wrong pattern" attempts and prompts me to log in with my google id. Unfortunately this does not work as it always gives me "invalid user id or password" very fast. I had wifi turned off so I cant imagine it would be able to log in to google and i doubt my password is stored locally. I read somewhere that this is a known bug.
Im running CM9 on it and am able to access it through adb. I found one solution which I tried and did not work, it goes:
Code:
> adb -d shell
# sqlite3 data/data/com.android.providers.settings/databases/settings.db
sqlite> update system set value=0 where name='lock_pattern_autolock';
sqlite> .exit
# exit
I also found an extended version of this, the exact syntax i dont remember but it was more for my case (something like 'locked_out_permanently'), I set the value to 0 as well, but no desired result. Of course the posts were from 2009 so for quite a few versions of android back. My CM9 is 4.04.
I have also found that there is an app called Screen Lock Bypass, which i imagine I would be able to install through 'adb install', but I have not found the apk.
Any ideas? I'd appreciate all help.
Would reflashing the rom work, you wouldn't lose any data or apps?
Sent from my Galaxy Nexus using XDA Premium HD app
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
Hi there,
upon installation of a new TV and reprogramming the remote it seems that I cant control my Android TV shield anymore via Infrared.
Is there a way to test if the commands arrive?
I don't want to root my device.
In linux there was irw but I have no clue if it will work under Android .
Thanks in advance
Guy
Sounds to me like the problem lies with the Remote. If this were a Harmony Remote, then the answer would be as simple as telling you to redownload, and install the correct Shield TV Profile again.
But, for personal interest sake is this a 2015, 2017 16Gb or the Pro? 'Cause the new '17 Slim & Lite Shield TV does it like S0NY, and removed it to cut it's costs. So by that matric it couldn't work.
But, if I wanted to somehow diagnose this on a Command Line. I think I would do it something like this: (Note you will need a Laptop, or PC. Perhaps a Phablet with Android Terminal might even work)
Code:
$ adb devices
- to see if the Shield turns up. (Note: You will of course need to enable the Developer Settings, and turn ADB on first.)
Code:
$ su
- You may or may not need this but, to be S(uper)U(ser), you have to be root.
Code:
$ adb shell
- With this you now access the Shield (Or, other 'Droid type Boxen) On the command line leve!.
At which point you type this:
Code:
$ cat /proc/kmsg | grep -v -e CTS_ -e 'need set max' -e gpufre
- Which should start a running log. Now this may well be too busy, the first time you run it. 'Causing you to quickly swipe command + c to break it. But, on the second attempt it should be stable enough to show you any 'raw' inputs it receiving over the IR.
Introduction:
Hello smarter people. I've been trying to run an ssh server on my phone. My phone is encrypted with the standard tools provided by Lineage OS. I believe the phone's encryption is causing the ssh daemon to loose access to the file found in /data/data/com.termux/files/home/.ssh/authorized_keys (reasoning in My Possible Solution and Question section). If I could make this file unencrypted somehow, it would likely solve the issue and allow me to ssh into my phone's server from my Ubuntu machine (or at least let me start troubleshooting further arising issues. ).
I know the version of Lineage OS that I am using is unofficial, but if this is possible, it should be the same process.
Specific Technologies:
Unofficial Lineage OS Android 8.0.0 on Moto G5 Plus..
This phone is encrypted using the encryption tool found at Settings --> Security & Location --> Encryption & credentials --> Encrypt phone
Using the latest version of the Termux application installed through the Google Play store.
Using the latest version of the openssh package installed through through Termux's apt package manager.
Specific Problem
I am familiar with setting up ssh servers, so I believe I did the configuration correctly. Since this was on my phone and I wanted manual control, I installed openssh through Termux's apt package manager, appended my public key to the ~.ssh/authorized_hosts file (the only thing in the file), started the daemon with sshd, and finally ssh'ed in from my Ubuntu computer. Here is a link on how to do this from Termux.
On my Ubuntu computer I get this:
Code:
[email protected]:~$ ssh 192.168.0.101 -p 8022
Permission denied (publickey,keyboard-interactive).
When viewing the logs with logcat -s 'syslog:*' I get the following output:
Code:
12-24 16:29:01.209 13972 13972 I syslog : sshd - Server listening on :: port 8022.
12-24 16:29:01.210 13972 13972 I syslog : sshd - Server listening on 0.0.0.0 port 8022.
12-24 16:29:52.029 14131 14131 I syslog : /data/data/com.termux/files/usr/bin/sshd - Connection closed by authenticating user myusername 192.168.0.123 port 59614
My Possible Solution and Question
Based on a few hours of troubleshooting I believe that since my phone is encrypted, the ssh daemon cannot read the authorized_keys file correctly, or some other issue origination from the phone's encryption to the authorized_keys file. I found someone having a similar issue at this link, which is why I believe the encryption is the source of the problem. Unfortunately the encrypted environment that was causing them issues was on a CentOS server with an encrypted home folder and mine is on a Lineage OS phone with pretty much total encryption(?).
If you were wondering if the solution posted to the link above works, here is the log output:
Code:
[12-24 17:00:00.768 17585 17585 I syslog : /data/data/com.termux/files/usr/bin/sshd - Authentication refused: bad ownership or modes for directory /data/data
12-24 17:00:02.146 17585 17585 I syslog : /data/data/com.termux/files/usr/bin/sshd - Connection closed by authenticating user myusername 192.168.0.123 port 59760
I do not believe a change in that /data/data directory's permissions would stop the root error as the full path to each authorized_keys file is /data/data/com.termux/files/home/.ssh/authorized_keys and /data/data/com.termux/files/usr/etc/ssh/mytermuxusername/authorized_keys which are both contained in the /data/data directory.
Does anyone know how to make my authorized_key file unencrypted on Lineage OS (just for Termux) by either moving it to a non encrypted directory or through some other, fancier means? I would love to hear how to do this. Or if you have identified a different source of the issue, that would be equally appreciated!
I know this is old, but it really might be the permissions.
I do not have enabled encryption on the phone I use ssh on, however, but you could try it.
A very similar issue happened to me, so I created a bug report (BUGBASH-2624 on lineageos' jira, I may not post links yet)
tl;dr: Try setting
Code:
StrictModes no
in /etc/ssh/sshd_config (or whatever implementation you use, that's where stock lineage has its config file) and restart sshd. This might not be a permanent solution, but at least it lets you rule out what the actual problem is.