Develop Bugs

[Q] [REQ] Gsiff_Daemon Runaway causing severe battery drain, possible fixes?

This is a formal request for any developer capable of doing so, to take a look at this problem.
There is a growing number of users noticing a severe battery drain and hot phone at times, caused by the runaway process; (gsiff_daemon)
The threads discussing this as of now are scattered and unorganized, and with the number of users experiencing this problem, it would be excellent to have one central thread for everyone to work together on this.
Here's what we know so far:
The problem occurs for most on a hot-boot, and can be triggered by forcing a hot-boot.
It is not carrier specific, At&t, Tmobile, and Verizon users have all confirmed this problem.
The only reliable way to rid of this at this time, is a reboot, although some have had luck ending the gsiff_daemon process, or renaming the file, although this requires further testing.
Here are a few threads that have been started on the issue, with some good reading:
http://forum.xda-developers.com/showthread.php?p=30074303#post30074303
http://forum.xda-developers.com/showthread.php?t=1800812&page=3
Anyone capable of looking into this, and know what they are looking at enough to determine the cause, will be eternally thanked, and i will personally donate a case of beer(or soda) to whoever fixes it.
Thanks!

is this Gsiff_Daemon issue only for rooted users? I just got it too...after rooting...I never had this issue since june 30, since I've had the phone

I just renamed the file.. problem went away. it doesn't run anymore.. and haven't had any negative effects that I can tell....

do any of you guys have the "increase volume in pocket" setting on in phone-->settings?
also do any of you have motion settings enabled and/or autorotation on?
Seems it has to do with the gyro issue
also are you guys rooted or non-rooted?

Crapppp
Jellybean didn’t solve it. Gsiff_daemon just popped up for me. Just renamed it AGAIN.
Hopefully it won't pop up again
Sent from my SPH-L710 using xda app-developers app

tjb433 said:
The problem occurs for most on a hot-boot, and can be triggered by forcing a hot-boot.
Click to expand...
Click to collapse
FULL REPORT
HARDWARE and OS
I747m, Stock LH1 4.0.4, Rooted
SOFTWARE
SetCpu 384-1512mhz OnDemand
System Tuner Pro 2.5.5 (STP)
Rebooter 1.6.0, Author: DAVIDJR621
BetterBatteryStats 1.11.0.0
Battery: /menu/settings/battery/
NORMAL OPERATION
- Reboot normally until system settles in fully loaded and in idle
- check SetCpu. Scaling should hover at 384mhz and with occasional spikes usually up to 1512.
- check BetterBatteryStats, switch top drop down selection to "Process" and secondary selection to "Since Unplugged". "gsiff_daemon" should NOT be listed there
REPRODUCING THE ISSUE
- Open Rebooter app and launch the HOT REBOOT option and wait for the system to reboot and settle.
- Open SetCpu and you should notice that the scaler will be at 1512mhz >90% of the time. IF NOT...repeat the hot reboot step.
- Open BetterBatteryStats as you did above and notice that "gsiff_daemon" is now listed in there.
- Open Battery info and notice that ANDROID SYSTEM is at the top of the list usually around 60%. Now STARE at Android system and click the refresh button...and notice for a brief Milli Second you will see,,,,"gsiff_daemon". Not sure about this but interesting.
- Open STP, launch it's built in Task Manager, make sure you allow viewing of SYSTEM and KERNEL. (at the bottom you can click on their ICONS) Scroll down near the bottom third of the list where it shows KERNEL elements, and you will see /system/bin/gsiff_daemon. Click on /system/bin/gsiff_daemon. Under CPU Consumption....you can watch the % climb.
- at this point, if you KILL /system/bin/gsiff_daemon, the CPU will settle back down to 384mhz and the statistics of cpu usage will not climb/grow.
WORKAROUNDS
- kill /system/bin/gsiff_daemon/ after a hot reboot or reboot your S3
- with a Root File Explorer, rename your /system/bin/gsiff_daemon to /system/bin/gsiff_daemonBAK and reboot normally. This should prevent the issue but it is not known whether it is adversely affecting any system components.
- /system/bin/gsiff_daemon/ should not show up in STP if you have renamed the file.

themadproducer said:
FULL REPORT
HARDWARE and OS
I747m, Stock LH1 4.0.4, Rooted
SOFTWARE
SetCpu 384-1512mhz OnDemand
System Tuner Pro 2.5.5 (STP)
Rebooter 1.6.0, Author: DAVIDJR621
BetterBatteryStats 1.11.0.0
Battery: /menu/settings/battery/
NORMAL OPERATION
- Reboot normally until system settles in fully loaded and in idle
- check SetCpu. Scaling should hover at 384mhz and with occasional spikes usually up to 1512.
- check BetterBatteryStats, switch top drop down selection to "Process" and secondary selection to "Since Unplugged". "gsiff_daemon" should NOT be listed there
REPRODUCING THE ISSUE
- Open Rebooter app and launch the HOT REBOOT option and wait for the system to reboot and settle.
- Open SetCpu and you should notice that the scaler will be at 1512mhz >90% of the time. IF NOT...repeat the hot reboot step.
- Open BetterBatteryStats as you did above and notice that "gsiff_daemon" is now listed in there.
- Open Battery info and notice that ANDROID SYSTEM is at the top of the list usually around 60%. Now STARE at Android system and click the refresh button...and notice for a brief Milli Second you will see,,,,"gsiff_daemon". Not sure about this but interesting.
- Open STP, launch it's built in Task Manager, make sure you allow viewing of SYSTEM and KERNEL. (at the bottom you can click on their ICONS) Scroll down near the bottom third of the list where it shows KERNEL elements, and you will see /system/bin/gsiff_daemon. Click on /system/bin/gsiff_daemon. Under CPU Consumption....you can watch the % climb.
- at this point, if you KILL /system/bin/gsiff_daemon, the CPU will settle back down to 384mhz and the statistics of cpu usage will not climb/grow.
WORKAROUNDS
- kill /system/bin/gsiff_daemon/ after a hot reboot or reboot your S3
- with a Root File Explorer, rename your /system/bin/gsiff_daemon to /system/bin/gsiff_daemonBAK and reboot normally. This should prevent the issue but it is not known whether it is adversely affecting any system components.
- /system/bin/gsiff_daemon/ should not show up in STP if you have renamed the file.
Click to expand...
Click to collapse
isn'ttthere a period before bak?

eyecon82 said:
Crapppp
Jellybean didn’t solve it. Gsiff_daemon just popped up for me. Just renamed it AGAIN.
Sent from my SPH-L710 using xda app-developers app
Click to expand...
Click to collapse
What JB ROM are you using? I had the issue when I was running stock, rooted, with the Sammy KT747 kernel, but after flashing CM10, landing the AOKP KT747 Kernel, and running Pimp My ROM on it, I've never seen it crop back up. (knocking on wood here).

78c10 said:
What JB ROM are you using? I had the issue when I was running stock, rooted, with the Sammy KT747 kernel, but after flashing CM10, landing the AOKP KT747 Kernel, and running Pimp My ROM on it, I've never seen it crop back up. (knocking on wood here).
Click to expand...
Click to collapse
I am using rooted stock rom
This is only an issue with touchwiz, so you won't see it on cm10
Sent from my SPH-L710 using xda app-developers app

eyecon82 said:
isn'ttthere a period before bak?
Click to expand...
Click to collapse
NOPE!
Specifically though, I used uppercase BAK....doubt that makes a difference.

themadproducer said:
NOPE!
Specifically though, I used uppercase BAK....doubt that makes a difference.
Click to expand...
Click to collapse
What is the difference of having or not having a period?
Upper casing probably doesn't make a difference though

eyecon82 said:
What is the difference of having or not having a period?
Upper casing probably doesn't make a difference though
Click to expand...
Click to collapse
Eyecon82...really...don't worry about the period. It's irrelevant.
So long is the file is renamed, it wont be triggered/found by whatever normally triggers/finds it.

http://pastebin.com/siAGdxp4
It looks like it's sending gyroscope and accelerometer data to the locapi, (location application interface) and there's some reference to sns there as well.
So, why would a location app need accelerometer data? Or maybe the question is why would someone who's getting my location data need my accelerometer data, too? What's in it for Samsung that they would bother developing it and roll it out? Why wasn't it there in June?
Ok, having a little fun speculating, but perhaps blackboxing for car accidents? Your phone log is the first thing they check and see if you were texting, or whatever, right before impact. Oh, wait, if they have a location-accessing app, they don't need your locally stored log. Nah, probably something technical with the compass....

Janis;34345281It looks like it's sending gyroscope and accelerometer data to the locapi said:
Yes, I don't have any evidence to support this other than what just happened on my phone. I was out for about a 15 minute walk and I got back. Phone was hot and i noticed a severe drop in battery. I remember reading that Goog Now tabulates how far you walked/jogged monthly or something. Maybe this process is capturing that motion/data for it? Just my speculation. No evidence. I think I'll try renaming the file as I dont really GAF about how far Goog thinks I've walked.
Click to expand...
Click to collapse

I am having this issue. I've just rooted my phone and the file seems to no longer be in /system/bin and running a search for it the file isn't found. Yet it's completely killing my battery. It's quite annoying to have to monitor battery use and kill this off or restart the phone so renaming it would be nice to disable it fully but I can't seem to find the file

harryshepard said:
I am having this issue. I've just rooted my phone and the file seems to no longer be in /system/bin and running a search for it the file isn't found. Yet it's completely killing my battery. It's quite annoying to have to monitor battery use and kill this off or restart the phone so renaming it would be nice to disable it fully but I can't seem to find the file
Click to expand...
Click to collapse
You sure it's gsiff_daemon that's causing the issue? Have you renaming qosmgr in system/bin?
Sent from my SGH-I747 using Tapatalk 2

Sorry, didn't have reply notification. Yes I am sure. I Google'd it after seeing it using 30% of my battery with about 50s use. I will try renaming qosmgr but how do you diagnose which process is actually doing it? This time battery doesn't specifically say gsiff_daemon but not sure if that's where I saw it before.
I have attached my battery use screenshot. Game and screen a the top, fair enough. But 13 hours on battery and 75% drained, 6% of which is 7 seconds of the gpsd process. It's a little odd
Sent from my GT-I9300 using xda app-developers app

fix yet ? mines doing same

gsiff_daemon
Mine has been doing the same ever since the kitkat update.
I am running an unrooted EE note 3 (n9005) in the UK.
Gsiff_daemon is constantly my top battery drainer according to the battery app (35% - 47%).
I have not been able to find any consistent method to either activate this rogue app or to get rid of it.
Is there any solution without rooting it as I understand that renaming it should do the trick?

+1 from me about this problem.
Uprooted, up to date Note 3.
No solution so far, will try turning off WiFi when screen off and auto rotation... Let's see...
Hopefully it'll be fixed soon or in next version. It's a shame, though, my Windows phone pals are teasing me!
Best regards,
Doncho

Still heat exists

Hi everyone. Is the heat persist for everyone. Mine in average 65 degree centigrade and going to Max 73 degree centigrade (through cputemp in status bar xposed module). I'm using telsa rom latest build (based on CM11 R17). I have also tried many custom roms and kernels, mods, underclock but same heating problem. Is there anything I'm missing out. Is there anything really working heat problem solution .

Please help let me know any information to be provided further.

try latest carbon rom... mine doesn't go above 38 deg, 45 deg n 60 deg while idle, while using phone n while playing games resp...

Try Latest Carbon or CM11.
I didn't noticed any heating issues in the latest CM11 builds!

I believe that the price of the phone tells us we should NOT have great expectations.Still,it turned out to be an amazing phone,with a great camera,good performance,no major issues(trust me,i owned an xperia L.that phone has obvious issues and Sony does nothing to fix them.I would sue them if I could for selling that on the market).The heating problem can't be avoided.I'm using latest CM11 and I use mostly balanced profile(1401 mHz top frequncy),and when using the phone to send texts,a little browsing,calls and so on it doesn't get heated up,or it gets a little warmer if you watch youtube videos for example,but when I play games,that's a whole new story.It is obviously that the phone is very hot,way above average.And that's it,we have to deal with it.We can't do anything,that's how the phone was build,the materials they used and so on.On stock the phone has some thermal engine control,if the phone got too hot it dropped the CPU frequency.Now on CM11,there's nothing similar,so we have to be careful to not let it stay hot as hell for too long,it might burn the CPU.I will ask the rom developer about this concern.Hope I helped you.All the best !

The best solution for "Heating Problem And Faster Battery Draining":
1)Flash latest Carbon Rom RC6 4.4.4 (it has its own kernel which is very much optimized and has some more governers)
2)After flashing Carbon Rom click go to settings>about phone> click build number 5 to 6 times to activate Developer options and Performance menu.
3)In performance menu Set maximum speed to 998 Mhz and minimum to 300 Mhz, Set the Governer to "conservative" and I/O Scheduler to "cfq".(If you play games alot then set max frequency to 1190)
4)Install Xposed framework
5)Install Greenify app, now activate its module in Xposed Framwork.
6)Add all applications to greenify list and greenify them. Set the Working mode to Boost. Also check auto hibernation mode.
7)Also create a hibernate now shortcut to homescreen to greenify apps frequently when you dont use them.
Now your phone will never heat and it will increase your battery by 50%
Enjoy

cm11
try cm 11 with xcelerate kernel for better batt and heat control

Thermanger Update and Myths/Fiction about Custom Roms Overheating vs Stock

Here is updated Thermanager, which could be flashed in recovery. I have made some changes after I played Asphalt game for about one hour. With this update, on performance governor the temperature never went higher than 58. And we are talking 1 hour straight. I doubt you can have that on stock. What was interesting that performance governor produced less heat than interactive, which supports my claim that when cpu jumps frequencies, it creates additional overhead.
Now, regarding myths and fiction about stock rom not overheating. There are some dudes on this forum who complain that their Z1 overheats to 70+ on custom roms when they play their beloved games; on stock, they say, there is no overheating.
Here is a short answer. You, guys, don't know what you are talking about.
Custom roms (and custom kernels) give you tools that are not available in stock. You just have to learn how to read/use them. Here is one example: some roms allow you to have internal cpu temperature on screen. Now that you have it, you watch. When it hits 70, you panic, but if you touch the back door, it will be barely warm. So, when you are on stock and without temperature reading, you think your phone is not overheating, while it can still have 65-70.
I used a modified version of M5 kernel compiled with GCC 5.2.1 Ubertc; CPU at 2457; performance governor, inteliplug balance with touch boost disabled; GPU overclocked to 600 with msm-adreno-tz idle wait 30 and workload 3; swapiness 10; enthropy 1024 read/write. That was on DU rom, but I bet the result would be the same on Jaguar and some other custom roms.

lol, that dude is Me, and I will try this, in the stock rom I can see an process running as overheat manager or something, I think it might have to do something with it. I'm sure that my device got heated very much, I didn't meant to offense but you seems to got it wrong. btw I will try this. I use Jaguar atm.
Thanks

I don't think that my phone won't reach 60 C on stock, but I like watching YouTube, so I can see how fast it warms. (I have xposed module that shows me cpu temp even on stock). And as much as I can say my phone warms faster on custom roms than on stock. No matter what governor I use.
Also all animations (like status bar showing) are kind of laggy on custom roms. I don't know it it got better in past 2 months, but last time I used custom rom my phone reached 50C even only with chrome.
Interesting thing is that this all (including animations) is not present on 3.10 kernel, but there are no usable roms at the moment with 3.10 kernel, so I have to use stock.

SuperLamic said:
I don't think that my phone won't reach 60 C on stock, but I like watching YouTube, so I can see how fast it warms. (I have xposed module that shows me cpu temp even on stock). And as much as I can say my phone warms faster on custom roms than on stock. No matter what governor I use.
Also all animations (like status bar showing) are kind of laggy on custom roms. I don't know it it got better in past 2 months, but last time I used custom rom my phone reached 50C even only with chrome.
Interesting thing is that this all (including animations) is not present on 3.10 kernel, but there are no usable roms at the moment with 3.10 kernel, so I have to use stock.
Click to expand...
Click to collapse
So, what's the temperature your xposed module shows on stock under stress?

optimumpro said:
So, what's the temperature your xposed module shows on stock under stress?
Click to expand...
Click to collapse
Usually after 20-30 minutes of YouTube it's around 53-54°C

SuperLamic said:
Usually after 20-30 minutes of YouTube it's around 53-54°C
Click to expand...
Click to collapse
Which browser or is it a youtube app? I have similar temps on Firefox and about 44-48 when using Chromium (not chrome).

ScatteredHell said:
lol, that dude is Me, and I will try this, in the stock rom I can see an process running as overheat manager or something, I think it might have to do something with it. I'm sure that my device got heated very much, I didn't meant to offense but you seems to got it wrong. btw I will try this. I use Jaguar atm.
Thanks
Click to expand...
Click to collapse
Overheat manager: whatever it is, all it does is throttling and thermanager does the same on custom roms. So, the trick is to throttle enough without you noticing any lags...

optimumpro said:
Which browser or is it a youtube app? I have similar temps on Firefox and about 44-48 when using Chromium (not chrome).
Click to expand...
Click to collapse
It's a YouTube app. Really? It's weird, maybe I'll try, but I can see the difference on battery time when I come home from school - on stock I have ~70% and on custom roms I have ~50. Anyway I'll try and report after few days.

Okay, I can say that custom roms are now ok for me when it come to battery life. I compared usual usage of mine on stock and custom roms and now it really gives me same battery life. The only change I made this time is that I used DU instead of Jaguar and this thermalmanager settings.
Though there are still two things that bother me on custom roms: laggy UI - I don't know what causes that, I tried changing lot of cpu/gpu thing to sort it out, but nothing helped. And the other one is headset connecting - I have to press and hold (for a little while) all the buttons on headset to get it recognized.
I'm returning back to stock, but I can say that now is overheating on custom roms gone.
Thank you, @optimumpro

SuperLamic said:
Okay, I can say that custom roms are now ok for me when it come to battery life. I compared usual usage of mine on stock and custom roms and now it really gives me same battery life. The only change I made this time is that I used DU instead of Jaguar and this thermalmanager settings.
Though there are still two things that bother me on custom roms: laggy UI - I don't know what causes that, I tried changing lot of cpu/gpu thing to sort it out, but nothing helped. And the other one is headset connecting - I have to press and hold (for a little while) all the buttons on headset to get it recognized.
I'm returning back to stock, but I can say that now is overheating on custom roms gone.
Thank you, @optimumpro
Click to expand...
Click to collapse
OK. Nice to hear that about battery life and overheating. With regard to lagging: it is not cpu, but rather animations. Either disable them completely in developer options or in DU you can go to tweaks and pick and choose whatever animation you want. I just disable all animations and have absolutely no lag.

SuperLamic said:
Okay, I can say that custom roms are now ok for me when it come to battery life. I compared usual usage of mine on stock and custom roms and now it really gives me same battery life. The only change I made this time is that I used DU instead of Jaguar and this thermalmanager settings.
Though there are still two things that bother me on custom roms: laggy UI - I don't know what causes that, I tried changing lot of cpu/gpu thing to sort it out, but nothing helped. And the other one is headset connecting - I have to press and hold (for a little while) all the buttons on headset to get it recognized.
I'm returning back to stock, but I can say that now is overheating on custom roms gone.
Thank you, @optimumpro
Click to expand...
Click to collapse
Oddly enough, I find custom ROMs hae smoother animations than stock, in my phone. But I don't have good battery life when compared to stock..

Stock Oreo - CPU not scaling

This morning my Pixel C felt slow and sluggish.
Rebooted and removed recently installed apps but no difference.
Installed a CPU monitoring app and see that the CPU stays at 204Mhz even under load.
Any ideas before I try a full wipe?

Full reset seems to have fixed though notice cpu maxes at 1326
This right?

I'm not sure most CPU monitors know what to do with the X1, I know CPU-Z doesn't recognize it beyond a general "Nvidia Tegra" chip. What app are you using?

I switched from AOSP for acbit but yesterday had the same issue. Tablet felt slow and sluggish.
CPU monitor app showed CPU not scaling.
Went back to stock Oreo and still "feels" slow.
Geekbench4 says single core 926 and multi 2561
This is wrong?

My Pixel C performance is strange still the OREO update. I know this going to sound weird but when in splitscreen, the app on the left in landscape or on the top in portrait is lagging a lot. Scrolling, page swiping, etc.. takes a distinct longer time than expected. The app in the other half of the screen is acting normally.
Could this be related to the same issue?
With the pixel C now discontinued, Google is unlikely to fix a bug, especially if nobody reports it.. Bit of a worry, what to do?

I'm facing this issue as well. Already wiped cache and did factory reset, with no results.
It's now a very fancy digital picture frame.

There is no such problem. I used the first available monitoring program (cpufloat) and the CPU frequency change is shown adequately.
https://play.google.com/store/apps/details?id=com.waterdaaan.cpufloat

Vartom said:
There is no such problem. I used the first available monitoring program (cpufloat) and the CPU frequency change is shown adequately.
https://play.google.com/store/apps/details?id=com.waterdaaan.cpufloat
Click to expand...
Click to collapse
Thanks - in that case, the issue is less obvious to spot but I have definitely noted a lag in split screen mode refreshing the app on the left (yes, I know how strange it sounds..).
In addition, there have been quite a few report of the new January patch release affecting Pixel (phones) users. I can't help thinking our Pixel C issue with the last update and these new issues are too much of a coincidence..
I am hoping Jan patch might fix my Pixel C issue...
L

laurentbon said:
Thanks - in that case, the issue is less obvious to spot but I have definitely noted a lag in split screen mode refreshing the app on the left (yes, I know how strange it sounds..).
In addition, there have been quite a few report of the new January patch release affecting Pixel (phones) users. I can't help thinking our Pixel C issue with the last update and these new issues are too much of a coincidence..
I am hoping Jan patch might fix my Pixel C issue...
L
Click to expand...
Click to collapse
At the moment I'm using the kernel I've modified, and I have no problem with scrolling on the left side of the screen in split screen mode.
you can try it.

Install Kernel Auditor and deselect CPU Multi-core power saving option in CPU tab, that was on for some reason.

MrPhilo said:
Install Kernel Auditor and deselect CPU Multi-core power saving option in CPU tab, that was on for some reason.
Click to expand...
Click to collapse
For what? if the frequency control and so works normally

Just updated January-ota and nothing has been solved... What can we do to make google solve it. The bug with the navbar continues and the split-screen is impossible to use
I started a thread when I noticed this bugs
https://forum.xda-developers.com/pixel-c/help/bugs-android-8-1-t3718156

AlfreGarcia98 said:
Just updated January-ota and nothing has been solved... What can we do to make google solve it. The bug with the navbar continues and the split-screen is impossible to use
I started a thread when I noticed this bugs
https://forum.xda-developers.com/pixel-c/help/bugs-android-8-1-t3718156
Click to expand...
Click to collapse
https://issuetracker.google.com/issues?q=componentid:190923+ Click "Create Issue" Report the bugs in detail how to replicate etc Someone from the dev team should get back to you

liam_davenport said:
https://issuetracker.google.com/issues?q=componentid:190923+ Click "Create Issue" Report the bugs in detail how to replicate etc Someone from the dev team should get back to you
Click to expand...
Click to collapse
I dont know why, but the blue buttons are unclickable for me, so I cant create the issue.

Bringing back from dead.
So if you use Kernel Auditor to turn off some of the cores when this is occurring, the clock speed goes up for the primary core. It's as if they set a total limit, then divide by total core count. When battery charge is above 67%, you get the full max speed. No reboot or anything, just charge it up and you unlock the speed again. I suspect the Oreo kernels have bad throttling algorithm for this CPU.

My Pixel C was lagging quite bad when the battery fell below 67% using stock 8.1 (locked bootloader, everything untouched). I tried reflashing the factory images, but the problem stuck around. I rooted (magisk 18.1) and installed Kernel Adiutor. The problem was obvious, the CPU would heavily throttle (under 67% battery) depending on the amount of core active (with 4 cores, they would all run at ~200 mhz, with 2 cores, about 700 mhz and with 1 core about 1100 mhz). It wasn't so terribly laggy with 1 core running at 1100 mhz, but it was still pretty slow.
To try and troubleshoot the problem I then installed LineageOS 15.1 and followmsi's kernel (https://forum.xda-developers.com/pi...p-flashable-monthly-update-zip-pixel-t3375591). To my surprise the problem remained, despite the custom ROM and custom kernel. I think there is something wrong with the 8.1 oreo kernel and the Pixel C (see google forum post here: https://productforums.google.com/forum/#!msg/nexus/x7izNIUIHeI/VO4n9l_DCAAJ ). So I tried a second solution. This time I did the following:
1. Flashed TWRP: twrp-3.2.3-0-dragon.img
2. Flashed in TWRP: Followmsi's unoffical lineageOS 16.0: lineage-16.0-20190206-UNOFFICIAL-dragon.zip
3. Flashed in TWRP: (same session, before booting into LineageOS): OpenGAPPS Arm64 Pico package: open_gapps-arm64-9.0-pico-20190302.zip (m
4. Flashed in TWRP: (same session, before booting into LineageOS): Followmsi's Android 9 custom kernel: tegra-3.18_kernel_pie_dragon_v190205_unicorn-xceed-followmsi.zip
And voila, back to full speed. In fact the tablet seems to run better than ever. After some testing I installed Magisk 18.1 (for root and to pass safetynet), and everything is running great. The CPU's now appear to be managed properly by the 9.0 kernel. I'd recommend anyone experiencing this problem to go ahead with what I outlined above. Alternatively, if you're not comfortable with custom roms, you can install the last Android 7.1 build (ryu-n2g48c-factory-0bc0ee15.zip - guide here: https://mmikowski.github.io/pixelc-revert-nougat/).
Hope this helps.

[QUESTION] Normal Battery Discharge Rate

I am using Resurrection Remix latest version. The Battery Discharge Rate is between 250-750mAh when I measured. Is it normal?

devaponnadsm said:
I am using Resurrection Remix latest version. The Battery Discharge Rate is between 250-750mAh when I measured. Is it normal?
Click to expand...
Click to collapse
what app is that ?

loopypalm said:
what app is that ?
Click to expand...
Click to collapse
Castro
I am attaching more detailed from Ampere app

In ~ 4-5 mins, the battery drains 1%..
EDIT: While in use.

devaponnadsm said:
In ~ 4-5 mins, the battery drains 1%..
EDIT: While in use.
Click to expand...
Click to collapse
If you browse(only browse) with heavy browser (e.g., chrome/brave/facebook etc.) 1% in every 5-8 minutes is normal. While gaming, 1% in every 3-4 minutes is normal. However, if you just flashed the rom then wait for 2-3 cycle discharge to see the actual result.

Pavello said:
If you browse(only browse) with heavy browser (e.g., chrome/brave/facebook etc.) 1% in every 5-8 minutes is normal. While gaming, 1% in every 3-4 minutes is normal. However, if you just flashed the rom then wait for 2-3 cycle discharge to see the actual result.
Click to expand...
Click to collapse
No. While looking apps like WhatsApp and Facebook. I just flashed it 24 hours ago. Mobile Data Off, Bluetooth Off, Wi-Fi - Connected, GPS - Power Saving, CPU (Governer) - Powersave, Automatic Brightness. No many background apps (2GB RAM Free).

devaponnadsm said:
I am using Resurrection Remix latest version. The Battery Discharge Rate is between 250-750mAh when I measured. Is it normal?
Click to expand...
Click to collapse
that is too much, something must be runing in the background
do you use gapps ?

loopypalm said:
that is too much, something must be runing in the background
do you use gapps ?
Click to expand...
Click to collapse
Yes. I use GApps.
But, when I was running CrDroid with GApps it was ok. Then I installed MSMXtended and Ressurection Remix. In both there was high battery usage. I install GApps with every ROMs but never faced such problem. Which is the best ROM in terms of battery performance?

devaponnadsm said:
Yes. I use GApps.
But, when I was running CrDroid with GApps it was ok. Then I installed MSMXtended and Ressurection Remix. In both there was high battery usage. I install GApps with every ROMs but never faced such problem. Which is the best ROM in terms of battery performance?
Click to expand...
Click to collapse
according to my experiance AEX7.3 and MSMXtended 12.5 (not 13)
(i don't use gapps)
can you screen your cpu cores usage in castro ?

loopypalm said:
according to my experiance AEX7.3 and MSMXtended 12.5 (not 13)
(i don't use gapps)
can you screen your cpu cores usage in castro ?
Click to expand...
Click to collapse
Sure.
Because of some network problems, I am unable to attach the file. I can write it here.
It is showing Core Nos.:
0, 1, 2, 3 - 100%
4, 5, 6, 7 - 52%
Governer - powersave
I think its high

devaponnadsm said:
No. While looking apps like WhatsApp and Facebook. I just flashed it 24 hours ago. Mobile Data Off, Bluetooth Off, Wi-Fi - Connected, GPS - Power Saving, CPU (Governer) - Powersave, Automatic Brightness. No many background apps (2GB RAM Free).
Click to expand...
Click to collapse
I'm on latest RR also. It seems latest one has slightly higher battery drain. May be CPU is using higher clocks all the time.

Pavello said:
I'm on latest RR also. It seems latest one has slightly higher battery drain. May be CPU is using higher clocks all the time.
Click to expand...
Click to collapse
Yes. I already worte that in the thread. I think it is better to switch ROM.

devaponnadsm said:
Sure.
Because of some network problems, I am unable to attach the file. I can write it here.
It is showing Core Nos.:
0, 1, 2, 3 - 100%
4, 5, 6, 7 - 52%
Governer - powersave
I think its high
Click to expand...
Click to collapse
that purcentage shows the available purcentage
only your higher frequency cores are used ,which mean a heavy task is runing (or tasks)
are you using a custom kernel ?
(me too i'm using RR now for some tests and my battery drain is between -130/220mah while listening to music and -250/500mah while browsing , but i think my config is little crasy cus i freezed LOT of system apps and uninstall others ...)

loopypalm said:
that purcentage shows the available purcentage
only your higher frequency cores are used ,which mean a heavy task is runing (or tasks)
are you using a custom kernel ?
(me too i'm using RR now for some tests and my battery drain is between -130/220mah while listening to music and -250/500mah while browsing , but i think my config is little crasy cus i freezed LOT of system apps and uninstall others ...)
Click to expand...
Click to collapse
No. Stock kernel came with the ROM (RR).
No heavy tasks I set. How can I check if there are any? I haven't set any? I want to check any app is doing this.

devaponnadsm said:
No. Stock kernel came with the ROM (RR).
No heavy tasks I set. How can I check if there are any? I haven't set any? I want to check any app is doing this.
Click to expand...
Click to collapse
i work with
https://play.google.com/store/apps/details?id=com.kayan.nurav.forcestop
mine looks like
(as i said before,i did some heavy customisation and freezed lot of stuff)

loopypalm said:
i work with
https://play.google.com/store/apps/details?id=com.kayan.nurav.forcestop
mine looks like
(as i said before,i did some heavy customisation and freezed lot of stuff)
Click to expand...
Click to collapse
But the apps given in the image are important and they need to work. However, I think no way without switching ROM or downgrade.

devaponnadsm said:
But the apps given in the image are important and they need to work. However, I think no way without switching ROM or downgrade.
Click to expand...
Click to collapse
i didn't understand what you mean
the app in the image i sent are important for the system to work ,others are not
the app just show you what process is runing
i hope you understand

loopypalm said:
i work with
https://play.google.com/store/apps/details?id=com.kayan.nurav.forcestop
mine looks like
(as i said before,i did some heavy customisation and freezed lot of stuff)
Click to expand...
Click to collapse
did you freeze everything including all services except the one in the list? android still working with that.. thank you sir, ill try i really hate those background apps

nneko904 said:
did you freeze everything including all services except the one in the list? android still working with that.. thank you sir, ill try i really hate those background apps
Click to expand...
Click to collapse
yes ,everything exept :
adv setting
andro sys webview
call managment
camera
cneapp
com.androi.ons
com qti apmserv
com qti parsserv
com qti qualcom datastatunotif
com qualcom qrilmsgtunnel
com qualcom qti telephonyserv
contact
contact storage
files
key chain
media storage
messaging
networkstack
package inst
phone
phone serv
those should not be freezed ,but can be force stopped once the phone boots
i repeat : this is extreme ,and a normal user should not do that
i do that just for experiment,and battery life testing on multiple roms ...

loopypalm said:
yes ,everything exept :
adv setting
andro sys webview
call managment
camera
cneapp
com.androi.ons
com qti apmserv
com qti parsserv
com qti qualcom datastatunotif
com qualcom qrilmsgtunnel
com qualcom qti telephonyserv
contact
contact storage
files
key chain
media storage
messaging
networkstack
package inst
phone
phone serv
those should not be freezed ,but can be force stopped once the phone boots
i repeat : this is extreme ,and a normal user should not do that
i do that just for experiment,and battery life testing on multiple roms ...
Click to expand...
Click to collapse
I have reverted to MSMExtended v12.5, but the problem still persists.