Related
Could some kind soul please tell me what the following processes do?
sensorserver_ya
drexe
rild
events/0
mmcqd
pvr_workqueue
Thank you!
I saw your posts in the battery life thread and dig some digging after looking at my SystemMonitor results. These are pretty much all showing up in my System Processes list as well. Here's what I've found so far:
sensorserver_ya - Tied to the use of the accelerometer. This was showing constant CPU usage while ShootMe was running because it actives by shaking. As soon as I stopped ShootMe, this disappeared.
drexe - This one was showing almost constant 1% CPU usage. According to this thread, drexe and another process are both for some Samsung software called NPS(New PC Studio,) which I have never used and don't plan on using. I took the advice of the post and disabled them using adb. I'll report back results after a day or so.
Let me know if you've found out anything about the rest. Maybe bumping this thread up will get some more eyes on it
Gix0r said:
I saw your posts in the battery life thread and dig some digging after looking at my SystemMonitor results. These are pretty much all showing up in my System Processes list as well. Here's what I've found so far:
sensorserver_ya - Tied to the use of the accelerometer. This was showing constant CPU usage while ShootMe was running because it actives by shaking. As soon as I stopped ShootMe, this disappeared.
drexe - This one was showing almost constant 1% CPU usage. According to this thread, drexe and another process are both for some Samsung software called NPS(New PC Studio,) which I have never used and don't plan on using. I took the advice of the post and disabled them using adb. I'll report back results after a day or so.
Let me know if you've found out anything about the rest. Maybe bumping this thread up will get some more eyes on it
Click to expand...
Click to collapse
Hi Gix0r,
Sorry for the late reply; I have not been spending much time in the forums these days.
Good job with the "digging" to find the purpose of the system tasks. What was your result from disabling drexe?
Thanks,
Bruce
Safely Dis-ablable System Processes
Although it applies to an earlier model phone, here is another link that underscores your last comment and has other ideas:
http://einartysen.se/tweak-your-android/
sensorserver_ya also works with GPS... Had this running while running the gps test thing.
TheManii said:
It's widely known that the s7 has pretty weak battery life.
In general all qisda dell devices do (the s5/s7/venue).
Many of the bugs exist in the phone/ril and some exist in the logging systems.
In a bug free rom these workarounds should be completely meaningless, but stock roms are not at all bug free.
Recommendation one: Enable airplane mode on wifi s7's
The wifi and 3/4g roms are nearly identical, including the fact that wifi roms still have a full RIL. It apparently is also still enabled even in wifi s7's. Turning airplane mode on while leaving wifi/bluetooth on (as desired) does in fact affect the system.
Ways of checking: with airplane mode off on mine, the s7 has major issues going into sleep mode. Even with the screen off if you check the battery graph it's still active most of the time. Airplane mode more or less fixes this.
Potential gains: 20-30% or so more life, I've only been testing this for half a day or so but it seems to be draining signifigantly slower in sleep.
Recommendation two: (this one is more valid for the s5 then the s7) Connect the s7 to a pc with the android SDK installed and run 'adb logcat'
The qisda devices are known to have far too much logging enabled and included in stock roms. Virtually all the custom roms for the s5/7 have it removed, but there is a known bug with logging.
If you run logcat so the output is directed to it, afterwards it takes care of another one of the bugs. I have not actually tested this specifically on the s7, but it likely is equally valid as the differences from AOSP (ie the customizations qisda does to the roms) are pretty similar in the s5 and s7.
Potential gains: nearly triple battery life after logcat and avoiding a yet different ril bug on the s5. The s5 can go from potentially 10%/hour to 0.3%/hour due to all/no bugs being active. The s7 MAY be a valid target too, but I havnt actually tested this one on the s7.
Roms used to compare:
S7: Stock 506-wifi
S5: Custom 406 based rom
Click to expand...
Click to collapse
Crosspost from the S7 forum, both are valid on the s5.
The largest battery bug is in the RIL, way of activing the bug: make a call. If you reboot everytime after making a call the battery life is much better then if you dont restart. Depending on how often you make calls though this is completly unacceptable to reboot after each call.
Are you saying that removing logcat daemon would give more battery life?
If I am not mistaken, that seems a obvious thing, am I wrong?
But if you remove the logcat daemon, then you can't hunt the bugs anymore, so for custom Roms that would be a very high price to pay for so little gain.
Running logcat with the device attached actually affects it. You dont remove it, you merely run it and let it write to your screen for a bit
TheManii said:
Running logcat with the device attached actually affects it. You dont remove it, you merely run it and let it write to your screen for a bit
Click to expand...
Click to collapse
So redirecting output from /dev/null to /dev/tty1 improves battery life ? Seems highly unlikely to me.
Can you explain the methodology used in your tests, bcs we can go somewhere this way, bcs s5 seems to have not a good battery life, and some strange things i have observed too in this device.
It's redirecting it to the adb console, this is why the bugs inherently make no sense as it should be otherwise discarding the log safely when not attached to adb.
But it's really consistant/reproducable on my device. Until it's attached it contributes about +2-3%/hour drain on standby.
TheManii said:
It's redirecting it to the adb console, this is why the bugs inherently make no sense as it should be otherwise discarding the log safely when not attached to adb.
But it's really consistant/reproducable on my device. Until it's attached it contributes about +2-3%/hour drain on standby.
Click to expand...
Click to collapse
2-3 % standby per hour is way too much , i am running the latest DSC 0.64b on top of 407 BB and have around 1-1.5 % , but that seems too much for me , you should check the background processes i think.
I can consistantly get 0.3/hour drain if the bugs taken care of.
If you also encounter the RIL bug you can easily hit 10%/hour possibly in combination with the log bug, it's relatively common too.
TheManii said:
I can consistantly get 0.3/hour drain if the bugs taken care of.
If you also encounter the RIL bug you can easily hit 10%/hour possibly in combination with the log bug, it's relatively common too.
Click to expand...
Click to collapse
So then something wrong with my system then, what Rom you running ?
TheManii said:
Running logcat with the device attached actually affects it. You dont remove it, you merely run it and let it write to your screen for a bit
Click to expand...
Click to collapse
I have the stock Olleh 407 ROM installed on my Streak. If I run the ADB LOGCAT with my Streak attached for a while, then the bug will be gone, even if I disconnect from my PC? Or the bug is only gone when Im connected to the ADB LOGCAT?
It's a heavily modified SD 2.4.4
The RIL bug seems to be more noticible in GB, I dont recall if it existed in 3xx roms. The logcat one is possible in 3xx or newer roms.
lunadomain said:
I have the stock Olleh 407 ROM installed on my Streak. If I run the ADB LOGCAT with my Streak attached for a while, then the bug will be gone, even if I disconnect from my PC? Or the bug is only gone when Im connected to the ADB LOGCAT?
Click to expand...
Click to collapse
It's really voodoo/magic, attaching it for <some unknown amount of time> will fix it for <some random amount of time>
For me it seems I just attach it until the battery is charged (as I would charge it anyway) and it seems to last for a day to a couple days. It's as voodoo as it sounds.
It doesnt stick past a reboot and more importantly the RIL bug is the more noticable one anyway.
It's only really noticible when the ril bug isnt active, as then you're going from 2-3% to 0.3%/hour. Going from <10% to 3% overshadows it if it's even active at all.
I cant really say for certian if it even effects everyone or happens every boot. I've been on the same rom for 2 months and have extremely consistant data with regards to these two bugs.
The logcat one is just as consistant for me on SD 19x roms.
You can also do it without SDK installed, you just need to download terminal emulator from market and enter:
su
logcat
And you are ready
At least when I do it, i use it as an opportunity to charge anyway. I always do it on my pc as I need the SDK for other things so I always have it installed.
On a custom SD244 not OCed with airplane mode and after running logcat previously with wifi turning off when screen is off:
getting 15hours @5% lost.
I'm gonna keep testing till tomorrow then install 407
Surprisingly: the s5 has even better battery life then the s10 (ignoring the differences in battery life).
The s10 has amazing battery life too.
Current results:
S5 : 31 hours = 24%
S7 : 54 hours = 48%
S10:61 hours = 13%
Normalizing their results to the size of the S10's batt:
S5: 5.17 hours each %
S7: 2.63 hours each %
S10: 4.7 hours each %
Roms used:
S5: SD 2.4.4 <2.3.3>
S7: Stock 506-wifi <3.2>
S10: Chimeradroid r2 <3.2>
The S5 can be explained by the RIL bugs as mentioned earlier, and by airplane mode is also turning off the radio too. All 3 devices were left to idle for the entirety, with only battery graph checks and no actual use.
Guys , i have a really vad problems with my battery life. After i go on to Power Rom EVG (before that i was with StreakDroid 2.4.4) my battery is absolutely not good. I do this logcat trick, just a few programs is running, auto-brighness and ... nothing! please, help!
Hi...
So, I've opened up Nook Color Tools and clicked All Settings in order to find out more about my Nook.
Are these findings normal?
Attached scr...
The battery seems to drain quite quickly too, yesterday I've fully charged it, now this? Using wifi all the time, I've sent some emails with gmail and tried browsing web and failing
Stock 1.1.0, FT1.5-beta5'ed.
From my experience that is normal for a nootered nook. I unrooted my nook and did a manual root and did not install any Google apps, or any other un-need junk. Now granted i have ADB install stuff but my battery life is unchanged. What ever get installed with the Gapps and other just runs the battery use threw the roof.
So to answer you question yes that is normal for the automated roots.
Thread being moved to general.
This is not a mod, ROM or kernel.
I disagree; the issue seems related to nootering. but I could've started this in the nooter thread so maybe you could move this into the MinimalTouch1.5-beta5 thread for I believe it's clearly a mistake - how can there be 70% battery usage of cell standby, if the nook doesn't have a cell radio?
How does this application measure it's battery usage, what is "cell radio" - is it an app, like Phone.apk ?
Is it registered?
If found that my nook only lasted a couple of days unregistered, three weeks ago I registered it, haven't charged it since.
from what i learned what ever nootering does or installs makes android look for cell signal or maybe just try to send signal. I tried all the suggestions i delete the phone.apk plus a dozen others. but what i learned was these apk were always there. the issue was that once you nootered something starts to try to use them or keeps them awake. My battery life was about 3 days.
I tried the registration thing as well.
All i know is i unrooted my nook. then did a manual root. turned on adb wireless. Installed superuser, busybox, then manual installed apps by adb installing them, and my battery life is that of an unrooted nook. I have no Google apps installed. or any of that other junk. I'm not sure which app causes the issue but what ever it is it is part of the nooter not because of it being rooted.
betterbatterystats
rm phone and dialer apks
freeze gapps when not in use and anything else if possible
bad apps prevent sleep - analyse with bbs
all this due to Google's dalvik, which isn't handling wakelocks or enabling us to do it manually. only way is to guess and disable things at the moment. effects all android phones and the main reason why iPhone with its crippled single tasking works better
ciao
Since a Cell Radio doesn't actually exist, there is no actual data for Cell Radio, therefore Battery Statistics displays the wrong info, however the reason your nook is dying so fast if I had to reason based on your screen shots, is because you're leaving your Wifi on which is taking up a good portion of your battery.
Nootering doesn't make the device actually try to use the Cell Radio or any such thing, the stuff has always been there, and if you manually rooted by using a hacked APK and installing nook color tools, you would find that "Cell Radio" still contains the most "Battery" usage despite the fact it's not actually using any battery.
Another thing to keep in mind is when you've used Nooter and installed Gapps and stuff (and you leave your Wifi on) you'll have significantly less battery life, because it's doing all the data updates for Gmail, and any other apps you've also installed. This therefore causes it to use your Wifi more, and waste battery life. This isn't just a "Nook" thing, this is true for all android devices, if you have Apps that need to use Data to get updates, and they're getting the updates all the time you'll find you have significantly less battery life.
Normally on a normal android device we'd have access to Accounts & Settings, which would allow us to access options for setting when Data Sync happens, but on the nook you don't have such options. So therefore they happen (probably) every 15 minutes. This causes your battery life to go down.
To remove the "Cell Radio" from the battery statistics bit you can delete/freeze/rename Phone.apk and TelephonyProvider.apk
Note: This has no affect what so ever on your battery life, it only removes Cell Radio from battery statistics so you get a more accurate reading.
Move them using this:
Code:
adb shell mount -o remount,rw /dev/block/mmcblk0p5 /system
adb shell mv /system/app/Phone.apk /system/app/Phone.OLD
adb shell mv /system/app/TelephonyProvider.apk /system/app/TelephonyProvider.OLD
adb reboot
To undo this use:
Code:
adb shell mount -o remount,rw /dev/block/mmcblk0p5 /system
adb shell mv /system/app/Phone.OLD /system/app/Phone.apk
adb shell mv /system/app/TelephonyProvider.OLD /system/app/TelephonyProvider.apk
adb reboot
I figured as much, and wanted to share this info here, but you already beat me to it
Nonetheless, like you wrote above, I do not need Phone.apk and TelephonyProvider.apk - there's com.android.phone running in the background which I do not need.
It could however be waking up the device from deep sleep a lot, and it's not necesarily WiFi - B&N claims 3 weeks of WiFi on usage so with background processes, I think I should be able to pull at least a week.
Bear in mind that WiFi turns itself off with screen off, at least that's how it's configured out of the box.
So far, I kicked Phone and TelephonyProvider, will see if anything improves.
ps shows this:
app_31 1218 1205 636 328 c0246930 afe0c74c S /system/bin/logcat
app_31 1220 1205 636 328 c0246930 afe0c74c S /system/bin/logcat
How can I check what app is app_31 ?
imachine said:
app_31 1218 1205 636 328 c0246930 afe0c74c S /system/bin/logcat
app_31 1220 1205 636 328 c0246930 afe0c74c S /system/bin/logcat
How can I check what app is app_31 ?
Click to expand...
Click to collapse
The parent PID of 1218 and 1220 is 1205 (third column).
When you check that it will undoubtedly show /sbin/adbd, the ADB demon.
I am reposting this because the issue remains and when I first posted in July I received a single response from a user that was also experiencing this.
I can't seem to find an answer anywhere. Basically when listening to a podcast with the Podcast Addict player at ~1.9x or faster the audio stutters and produces a static sound distorting the audio. Waking the screen immediately stops the issue. The issue gets worse if you increase the speed or enable the "skip silence" feature.
I made sure to disable any battery saving options for the app and enabled any workaround options within the app. I even contacted the developer who pretty much just said that the phone is governing the processor too low with the screen off. I have tested other podcast apps and they seem to function fine even at faster playback speeds. For some reason, this only affects Podcast Addict.
Is anyone else experiencing this? Anybody have a suggestion for a fix? I am completely stock OOS version 4.5.14. I have the 8/128GB model if it makes a difference.
It seems to have issues even if the screen is on and the app is not in the foreground. Within ~5 seconds of being put into the background, it begins to stutter.
I have been working with OnePlus' own "bug hunter team" to fix this but I have not heard from them in over a month since I reported it to them. They asked me clear cache and reproduce the effect on my device and send them logs, which I did but I haven't heard anything.
Can anyone test this and tell me if they don't have an issue with screen off?
I also couldn't get rid of the static sound in Podcast Addict when playing back at fast speeds (for me, around 1.7x or faster). This was on a Galaxy S8+. I've been listening to a podcast audiobook Wildbow's "Worm" (which weighs in in at 6,680 pages) and the static sound was killing my ears. Gave up on Podcast Addict today, and switched to Pocket Casts and not having any static problems now when listening at faster speeds.
I think I found the problem with Podcast Addict stuttering... it's the logging.
I've gotten into the habit of pinning my CPU frequency to 299 MHz maximum to save battery, and PA would stutter, so I dug into ADB to figure out what was going on. After getting rid of the hidden adware that the phone's manufacturer kept running in the background, CPU usage dropped enough that I could run PA without much stutter, but if I opened the notifications or ran any other app, it'd start stuttering again. So I dug further.
And it seemed that as I increased maximum CPU speed from 299 MHz to 1.3 GHz, CPU utilization would increase, too, if Podcast Addict was running. That was strange behavior, so I knew something was going on.
Apparently the system is somehow hooking into PA and logging everything PA is logging internally. When I run:
adb logcat -D -v long > c:\test\logcat.log
... the logcat.log file swells up to 80 - 110 MB in a mere minute. Without PA running, it's generally around 113 KB / minute.
So I started killing logging processes.
I killed logcat, and CPU usage dropped dramatically, but logd started hogging the CPU.
So I killed logd. It restarted, but no longer hogged the CPU.
So CPU utilization dropped from ~83% for PA, utilizing 4 to 5 cores, to ~60% for PA, utilizing 3 cores. Even with the CPU pinned to a maximum 299 MHz, playback was smooth.
As for logcat, after killing it, if you run it from your computer:
adb logcat -D -v long > c:\test\logcat.log
it'll begin log-spamming again (its the AudioTrack thread which is spamming the log) and the phone's CPU usage spikes again, but now, after having killed logcat once, when I stop logcat logging via ADB, logcat stops spamming the log and the phone's CPU usage returns to using 3 cores.
Get the CPU usage info:
adb shell dumpsys cpuinfo
inside that info, you'll see the PID of the applications. Look for logcat and logd. There might be more than 1 logcat, kill them all.
Let's say logcat is running two instances, with PID 239 and PID 760, for example (it'll be different each time you boot the phone), and logd with PID 13020.
Then issue the following commands from a command prompt on your computer:
adb shell
su
kill 239
kill 760
kill 13020
exit
exit
On my computer, if I type the commands too fast, ADB can't keep up, and ADB will crash, so give it a few seconds in between each command.
The above-described log-spamming behavior reoccurs upon reboot, so you'd have to do this after each boot.
Now I can listen to podcasts (I usually listen at 2x, sometimes as high as 3x for podcasters who talk slowly) without stutter, with the octa-core CPU pinned to 299 MHz maximum.
After returning and exchanging my bricked **Android 11 model while trying to impossibly downgrade to Android 10 to root, I got my hands on a pre-Android 11** unit and was able to successfully root it. My only gripe with it right now is that running apps in landscape mode seems to cause a soft reboot, especially on launch. A characteristic of this is how it happens when the app has barely even filled the screen entirely by the boarder before the ONN logo reappears. Wanted to create a batch script to give me a somewhat decent live logcat output of what's going on, but didn't have the time. Youtube Vanced playback on both Music and Youtube cause a soft reboot on BOTH display orientations. Media playback is OK, SoundCloud only.
TL;DR: Tablet is trigger happy with soft reboots in apps oriented in landscape, making portrait mode the only viable display orientation on my tablet. Oversized smartphone, anyone?
.
Run the following command "adb logcat -v threadtime >logcat.txt" and reproduce the issue
Kenora_I said:
Run the following command "adb logcat -v threadtime >logcat.txt" and reproduce the issue
Click to expand...
Click to collapse
Ran the command and took a long look at the logcat. LSPosed and EdXposed seemed to be likely candidates for causing the problem when hooking onto apps, but disabling them resulted in the same behavior. After flashing the stock boot image + vbmeta, it appeared that Magisk itself was causing the issue. I'm going to look into it further from here.
Looked into it further. Safetynet appears to have a link to these problems.
Fresh logcat after reproducing bug
https://files.catbox.moe/7emoe6.txt
Logcat 2 [note that for reproducing this bug, I am reorienting the screen to landscape before opening FX File. This may or may not be reflected in both logs, assuming there may be some losses for whatever reason]
https://files.catbox.moe/bala2v.txt
.