Related
Sup all! I love my Hero. I use it as my primary music player on the go.
As most of us have encountered though, it happens sometimes that music starts stuttering after half a day of usage. The problem arises when the music stutters for about a tenth of a second on wakeup, and could start stuttering really badly and intermittently while the phone is asleep. It's frustrating when I can't listen to a complete song without interruption!
I figured, if the phone is silky smooth soon after boot, but starts degrading after a while, it's certainly a software bug that's causing the hiccups. Looking at logcat didn't yield much else than AudioFlinger warnings, but after connecting through SSH and looking at top, I noticed the process /system/bin/mediaserver was using up to 17% of the CPU all the time. I killed it, and the music stopped, but then the process restarted, and the music started again, though from the beginning of a different track.
But the music was smooth again, and the CPU usage of /system/bin/mediaserver dropped drastically.
That's all I have so far. Anyone have a clue why mediaserver would start eating CPU cycles like that? Could it be fixed in future custom ROM releases?
I'm hoping for the best.
YES!
This has pretty much been my biggest concern since I got the phone, but haven't looked into it at all.
I am glad someone else brought this up, I'd like to see some discussion on it, and once I get some free time AND get the IM.apk working, I would like to help in figuring this out.
Just briefly I took a look at the Android OS source, and mediaserver doesn't seem to be in there, so I'm going to make a guess and say that mediaserver is an HTC-specific service. (It's 2:30 in the morning here, I really won't have time until at least Sunday to put this theory to the test. )
If it IS HTC-specific, well, there are pros and cons. A pro is that this would mean that simply using a different music app could instantly fix the problem. Cons: The HTC apps are not open source, and we'd probably have to rely on HTC fixing the code, hopefully in the 2.1 update... and, I really like the HTC Music app, so I'd rather not switch to something else if I don't have to.
If it's NOT HTC-specific, then we'll probably have the same problem with every Music app... HOWEVER, this also means that the community has a better chance of fixing it without HTC's help.
One potential solution I've been thinking of is to use Linux's nice function to give mediaserver a higher priority. This means that other processes will run slower when music is playing, but the mediaserver process should constantly get all the CPU cycles it needs. If I'm listening to music on my phone, I'm more than willing to accept a bit of slow-down in everything else.
Sidenote: After disabling compcache and applying this (http://forum.xda-developers.com/showthread.php?t=622666) fix, the issue is much less noticeable, but it's still there. If I were to venture a guess, I would say that disabling compcache is where this improvement came from, since compcache uses some CPU power to compress the memory.
mediaserver is part of the AOSP. It's inside platform/frameworks/base.git, in /media/mediaserver/.
I'll try looking into it but I doubt I'll find anything. =\
In some cases a better SD card helped
ROM based
I seem to recall this being a ROM based issue. I think I had it for a couple of the early versions of Paul's MoDaCo, but in the newer versions it was fixed, and its never been an issue on any of the AOSP 2.1 ROMs i've been running.
I would guess its probably something from the original HTC release that was badly implemented, or un-optimised.
[I think it may have been sorted for MoDaCo when teknologist released his custom kernal?]
I have a Transcend Class 6 8GB, which I think is a well respected card around here. Besides, it doesn't explain why the process starts choking up after a few hours.
By the way, I run on MoDaCo 3.2 beta 5, with the OOM killer tweaked. It's definitely a software bug where the mediaserver gets stuck in a a strange processor-intensive mode.
as for me A-Data micro sdhc turbo class 6 run smooth/faster on music playback/transfer or backup/apply file in recovery.
I have BT audio in the car, what I have found is that when a new track starts the begining seems slower than normal but speeds up, but this doesn't happen when I listen through the phones speaker or headphones? I run on MoDaCo 3.1 and my micro sdhc is a Kingston 4gb.
Could it be it takes a while for the "waves" from the new track to be caught by the stereo, so it takes a while to catch up? (lol!)
Hopefully when andriod 2.1 comes out it will be sorted?
Don't know how it happened, sorry
as i know when u on wifi or BT it will consume more power eat up cpu & phone will surely laggy. if u using normal cable earphone it doesnt consume more power then BT & wifi & dont eat much cpu. BT is eat lot of battery & cpu if im not wrong.
i get this same problem. Its been there since the stock firmware, and is still apparent in MoDaCo 3.1. Even with a class 6 8gb SD card, its still there.
Now Im running a 2.1 variant, its gone, so it would suggest its a rom problem for sure
alexperkins said:
i get this same problem. Its been there since the stock firmware, and is still apparent in MoDaCo 3.1. Even with a class 6 8gb SD card, its still there.
Now Im running a 2.1 variant, its gone, so it would suggest its a rom problem for sure
Click to expand...
Click to collapse
are you sure u using bluetooth audio without lag?
The battery may not last that long but it makes up for that with fast charge time. I wonder if it will charge even faster turned off.? Just wanted to throw that out there for ppl thinking of getting an a100 on black Friday.
True enough. Dead to full in about an hour, I find.
I'm hoping a bunch of people (devs especially) pick up this unsung tablet hero, too.
Yeah, it is certainly a great thing. There are 2 reasons why that is the case: the small battery and the 12v 1.5a current. Devices that charge via USB are usually around 6 volts, so it is a blessing and a curse that our device does not charge via USB.
I'm sure that when we get this thing hacked and tweaked, we'll have some setting that allows us to USB charge.
With my a100, I last all day on a single charge. A few things that might help you guys prolong you charge:
Let the tablet die completely before you charge it again, and leave it off while it charges. Get an app killer, I use ATK (the one with the red x on the android). Leave all wireless connections off until you really need them (wifi and Bluetooth). Don't jack the brightness up unless outside in the sunshine, half brightness during the day everything is still clearly visible, and use the lowest brightness setting at night.
I am what's considered a power user (doing stuff on the device ALL the time) and I still get a solid 14 to 16 hours doing what I described above.
Hope this helps.
Sent from my ADR6400L using xda premium
You should stop using ATK. . . . it is actually hurting your performance. With honeycomb, it is no longer necessary for you to manage memory yourself. Android acts differently than a PC; instead of keeping a lot of free memory, the Android OS will use up as much memory as possible to keep apps on standby for faster performance.
As soon as ATK kills your apps, Android OS just loads them right back up into memory, so it is pointless. Try it yourself: kill all apps using ATK, wait a minute, and pull ATK back up . . . you will notice that the list fills up without you opening any of those apps.
[email protected] said:
You should stop using ATK. . . . it is actually hurting your performance. With honeycomb, it is no longer necessary for you to manage memory yourself. Android acts differently than a PC; instead of keeping a lot of free memory, the Android OS will use up as much memory as possible to keep apps on standby for faster performance.
As soon as ATK kills your apps, Android OS just loads them right back up into memory, so it is pointless. Try it yourself: kill all apps using ATK, wait a minute, and pull ATK back up . . . you will notice that the list fills up without you opening any of those apps.
Click to expand...
Click to collapse
Negative, sir. All apps I have killed using ATK have stayed killed til I access the app again.
ummmmm............ could you repeat that?
. . . the only thing I can say is check again later. . .
Android will try to use up the free memory automatically. You should not have an auto kill process running in Honeycomb. Yes, it was 100% necessary in Froyo and your device would come to a crawl if you didn't use it, but it isn't needed in Honeycomb; Android will automatically kill apps for you now.
[email protected] said:
. . . the only thing I can say is check again later. . .
Android will try to use up the free memory automatically. You should not have an auto kill process running in Honeycomb. Yes, it was 100% necessary in Froyo and your device would come to a crawl if you didn't use it, but it isn't needed in Honeycomb; Android will automatically kill apps for you now.
Click to expand...
Click to collapse
Did some more research of my own on that specific subject, and what you told me in this post, and the one before, is all basically part of a memory optimizer built right into honeycomb, so thanks! Never thought to look into that bbefore now, just always so used to using one...............
ummmmm............ could you repeat that?
As I understand it, Android buffers apps in the memory, so it can quickly restore them to where you left off, making everything seem much more responsive and faster, so when you use a Task Killer, you're essentially start from scratch. Honeycomb will then proceed to kill the apps you aren't using to free up system resources if necessary.
It's not like our A100s are choking due to small memory anyway, I never seen even get close to 512MB, let alone the 1GB on board.
littleemp said:
As I understand it, Android buffers apps in the memory, so it can quickly restore them to where you left off, making everything seem much more responsive and faster, so when you use a Task Killer, you're essentially start from scratch. Honeycomb will then proceed to kill the apps you aren't using to free up system resources if necessary.
It's not like our A100s are choking due to small memory anyway, I never seen even get close to 512MB, let alone the 1GB on board.
Click to expand...
Click to collapse
Yea, my first smart phone was a blackberry, so I got used to having to close completely out of all my apps when I was done because of the lag it caused in the blackberry if you didn't. I still do that now, but its cool that android has already worked that into the system. Just one more justification for me being an android addict! :-D
Sent from my ADR6400L using xda premium
From my searching, even on other sites, supposedly this topic has been beaten to death, yet I can't seem to find much about it.
Basically, I would like to keep apps, like Facebook, Email, and Amazon Video, etc., from running until I start them up. Then I would like for them to close, and stay closed, when I'm not using them. In essence, act like a typical app.
All I have been able to find is that you can use a Task Killer to achieve this. But, the average opinion seems to be is that the TKs uses as much, if not more, resources repeatedly killing the constantly restarting apps as just letting the apps "run". Basically, I've yet to find out if it is or isn't possible to keep these apps from constantly restarting on their own.
The reason I want to make these changes is that when my memory gets full, my Fire will lock up, or slow down, for 30 seconds or so... sometimes longer. Supposedly, the O/S is designed to keep as much in memory as possible and it supposedly frees up memory quickly, from apps that you aren't using, when needed. In my experience this is definitely not the case... especially when I click the Task Killer button and my Fire instantly returns back to normal speed... and never did the CPU go above 600Mhz (which is the min I have it set to).... which means it wasn't an issue with the CPU being overloaded.
So does anyone know of a way to keep these persistent apps from being persistent?
BTW, I'm running a pretty standard rooted Fire that I just re-did using the KFU v9.6 and all the "goodies" with it, like the GoLauncher.
TIA
PBFred said:
Supposedly, the O/S is designed to keep as much in memory as possible and it supposedly frees up memory quickly, from apps that you aren't using, when needed. In my experience this is definitely not the case... especially when I click the Task Killer button and my Fire instantly returns back to normal speed...
Click to expand...
Click to collapse
It's true that, under normal circumstances, you shouldn't worry about it. It sounds like your system is simply lacking in memory because it has some high priority tasks eating it all away (Carousel + GO Launcher are probably hogging up a bunch already).
Seeing how you're running rooted Stock with Go Launcher and a bunch of other applications - have you considered switching to Modaco? It's based on Stock...
PBFred said:
So does anyone know of a way to keep these persistent apps from being persistent?
Click to expand...
Click to collapse
To answer this question, other than applying memory scripts, some task killers can be set to autoclose a pre-defined list of apps when you press a widget button - this may interest you. Look into the settings/options of the task killer you're using.
Maybe give this a shot?
https://play.google.com/store/apps/details?id=com.rs.autorun&hl=en
PBFred said:
From my searching, even on other sites, supposedly this topic has been beaten to death, yet I can't seem to find much about it.
Basically, I would like to keep apps, like Facebook, Email, and Amazon Video, etc., from running until I start them up. Then I would like for them to close, and stay closed, when I'm not using them. In essence, act like a typical app.
All I have been able to find is that you can use a Task Killer to achieve this. But, the average opinion seems to be is that the TKs uses as much, if not more, resources repeatedly killing the constantly restarting apps as just letting the apps "run". Basically, I've yet to find out if it is or isn't possible to keep these apps from constantly restarting on their own.
The reason I want to make these changes is that when my memory gets full, my Fire will lock up, or slow down, for 30 seconds or so... sometimes longer. Supposedly, the O/S is designed to keep as much in memory as possible and it supposedly frees up memory quickly, from apps that you aren't using, when needed. In my experience this is definitely not the case... especially when I click the Task Killer button and my Fire instantly returns back to normal speed... and never did the CPU go above 600Mhz (which is the min I have it set to).... which means it wasn't an issue with the CPU being overloaded.
So does anyone know of a way to keep these persistent apps from being persistent?
BTW, I'm running a pretty standard rooted Fire that I just re-did using the KFU v9.6 and all the "goodies" with it, like the GoLauncher.
TIA
Click to expand...
Click to collapse
Just let the OS do what it was designed to do, which is manage the apps and memory automatically. Any interference with that setup will only be a detriment to performance and battery life.
These are not full-featured Operating Systems like what is running on your desktop. Android (and iOS, and even Win8 Metro) automatically manages free memory, running processes, and stopping/starting of apps.
If you try to mess with this, it will cost you battery life and performance as the OS will continue to attempt to maintain it's designed status-quo by restarting apps that you've killed, and reassigning memory that you've freed up.
Task killers are only handy if you have an app that runs away and won't allow itself to be shut down (happens less often with every release/update), and even then, just cycling the device is more than enough to clean that up.
tl;dr Task Killers - Don't.
taskillers worked great in cupcake and donut... Using them In ics is just abusive.
PETA (peeps for ethical treatment of Android)
Sent from my HTC One S using xda premium
AlexDeGruven said:
tl;dr Task Killers - Don't.
Click to expand...
Click to collapse
This may be a dumb question, but I've read that kind of synopsis several times. With the release of ICS however, we have the option of killing previously running apps via the multitasking bar. What's the difference?
BleedsOrangeandBlue said:
This may be a dumb question, but I've read that kind of synopsis several times. With the release of ICS however, we have the option of killing previously running apps via the multitasking bar. What's the difference?
Click to expand...
Click to collapse
It's mostly in the way the OS talks to the task at hand. A Task Killer simply yanks the rug out from under the application in question, whether it's in a safe-to-stop state or not, and disregards any background services an app might be using. In many cases, the OS interprets this as a crash and attempts to get the app back into a 'normal' state.
ICS's task management politely asks (for lack of a better term) the app to stop and take any of its background processes with it. Sometimes, only the very foreground part of the app closes, sometimes the entire application and all services stop. But at the very least, you don't have the constant kill-recycle cycle that occurs with task killers.
ICS's method is much preferred, if not necessarily needed in most cases. I use it as a convenience to keep the list of recent apps clear.
androidcues said:
taskillers worked great in cupcake and donut... Using them In ics is just abusive.
PETA (peeps for ethical treatment of Android)
Sent from my HTC One S using xda premium
Click to expand...
Click to collapse
For memory management, yes. For killing wakelock abusers - they still have a reason for existing there.
Mainly Facebook. Facebook STILL holds excessive wakelocks on a regular basis (although it's not as bad as the perma-wakelock it held a year ago), and is the primary reason I keep Advanced Task Killer around.
Never use an autokiller though.
Only use a task killer for managing identified misbehaving apps that you just have to keep around for some reason (like Facebook). Never use a task killer for memory management reasons - only use it on apps that are using excessive background CPU or wakelocks. (usually, apps that are high on the ****list in Settings->Battery.)
There are programs like 'Gemini Task Manager" that will let you edit/modify the automatic startup settings for any particular app. At the very least it will let you see what apps may be causing problems on your device. As far as I know it only edits the startup to keep them from running in the first place rather than constantly killing them when they do like some task managers.
Thanks for all the info. It appears that just leaving it the way it is is what I should do... especially since 95% of what I use the Fire for is for reading books. But I am a Windows/Cisco Sys Eng, so I like to tinker with all my tech devices whenever I can.
That being said, it seems to me that if these "persistent apps" were on a Windows O/S, they would be running as a Service. And if you know Windows, you would know that Services can be set to restart if they are stopped by any means, except through the Service Manager Console itself (or the command line, if you really know Windows). But I have no clue if Linux/Android has the equivalent of Windows Services. I would have to believe that full-fledged versions of Linux/Unix does, but maybe not Android. Just a thought... and maybe it is something people have overlooked when trying to keep these "persistent apps" from being persistent.
Typically, in Windows, you would never ever think of running Facebook as a Service... but you easily could if you wanted to. And it appears that Amazon really wants Facebook, and several other apps, to be running at all times, for no apparent reason.
Oh well, if I had a 2nd Fire, I would "hack" the hell out of it. But since I don't, and I read a lot, I'll just be happy with what I got. And honestly, even after having the Fire since the first day it came out, I'm still loving it.
PBFred said:
Thanks for all the info. It appears that just leaving it the way it is is what I should do... especially since 95% of what I use the Fire for is for reading books. But I am a Windows/Cisco Sys Eng, so I like to tinker with all my tech devices whenever I can.
That being said, it seems to me that if these "persistent apps" were on a Windows O/S, they would be running as a Service. And if you know Windows, you would know that Services can be set to restart if they are stopped by any means, except through the Service Manager Console itself (or the command line, if you really know Windows). But I have no clue if Linux/Android has the equivalent of Windows Services. I would have to believe that full-fledged versions of Linux/Unix does, but maybe not Android. Just a thought... and maybe it is something people have overlooked when trying to keep these "persistent apps" from being persistent.
Typically, in Windows, you would never ever think of running Facebook as a Service... but you easily could if you wanted to. And it appears that Amazon really wants Facebook, and several other apps, to be running at all times, for no apparent reason.
Oh well, if I had a 2nd Fire, I would "hack" the hell out of it. But since I don't, and I read a lot, I'll just be happy with what I got. And honestly, even after having the Fire since the first day it came out, I'm still loving it.
Click to expand...
Click to collapse
It's still completely different system paradigms. In mobile OSes, background services are typically in a paused state when not actively in use, where in full-featured OSes, they can be in any one of several states.
As to the fb service running, that has nothing to do with Amazon. That's just the fb mobile developers not knowing what they're doing.
Sent from my Amazon Kindle Fire using Tapatalk 2
I've been using this phone for about 3 weeks, and I've noticed it seems to have a very aggressive low memory killer or a rogue task killer. I haven't installed any task killers or battery savers that should be doing this, so it seems to be system behavior.
If I airplane mode my phone, by the time I reconnect it, it has almost always killed DNS66. I can pause Pandora and just leave the phone laying on my desk. When I come back it will have killed Pandora. The last straw was today when it killed Rocket Player while it was actively playing.
The only device I've ever seen kill an active app only has 1 GB RAM. The last phone I used only had 2 GB RAM and it handled background apps way better than my Nokia 6.1 is.
Has anyone else seen this, or better yet, do you know how to stop it?
I have a TA-1045 running Pie on the Dec 2018 security patch. No root, no mods, no task killers - just bone stock behavior. The only non-Play store app I have is DNS66.
Have a look at
https://dontkillmyapp.com/
runekock said:
Have a look at
https://dontkillmyapp.com/
Click to expand...
Click to collapse
Excellent! Just killed that battery protection app. Can't wait to fire up adb and get rid of it entirely. I can't believe Nokia thought end users would desire this kind of behavior.
If this works out, you just saved me a phone. I was not going to put up with this much longer.
runekock said:
Have a look at
https://dontkillmyapp.com/
Click to expand...
Click to collapse
Well that didn't work. Force closing the battery protection app like suggested in that link didn't change aggressively killing off idle apps. The package manager adb command exits with success, but the battery protection app is still on the phone ruining its memory management.
Have you managed to get this phone to work properly with respect to background apps? Did you make any other modifications or do any other debloating?
Otherwise this is a pretty decent phone. Smooth enough and plenty fast for everything I use it for. The camera is a little sub-par, but no complaints for what I paid for it. Gotta skimp somewhere for a price point that low. However, sometimes it feels like this thing has a mind of its own, and its mostly due to how aggressively it kills off tasks. They aren't even always what I'd call idle, like a paused media player or a DNS server not currently in use. It is really disappointing. This isn't what I expected out of an Android One device.
The Nokia 6.1 belongs to my father, and this problem hasn't bother him, so I haven't tried anything myself.
Maybe you need to be rooted to uninstall the task-killer? But then, I don't know a way to root the phone, either.
runekock said:
The Nokia 6.1 belongs to my father, and this problem hasn't bother him, so I haven't tried anything myself.
Maybe you need to be rooted to uninstall the task-killer? But then, I don't know a way to root the phone, either.
Click to expand...
Click to collapse
You're probably right since it is installed as a system app. It is just odd that the package manager command exits with Success. You'd think it would throw a Permission Denied or Only Root can do that error.
Hello everyone, im going to choose a phone for my cousin and i was looking to s20+ exynos. Its a great phone but when i bought it in 2020 summer, it was heating up a lot even when doing normal tasks like using chrome or watching youtube. For comparison, when using zoom s20+ got up to 42-43 Degree battery and was really hot, same conditions s10+ was something like 31battery. After 2 days i returned the phone. Now i suspect this was due to software problems and wanna know if phone still heats up like this during normal use.
My Note 10+ Snapdragon was a hot running battery hog when I first used it. Today it's a fast, stable, cool running platform. Same firmware but I optimized it over time.
If you expect an Android to run perfectly out of the box you're having Apple delusions
blackhawk said:
My Note 10+ Snapdragon was a hot running battery hog when I first used it. Today it's a fast, stable, cool running platform. Same firmware but I optimized it over time.
If you expect an Android to run perfectly out of the box you're having Apple delusions
Click to expand...
Click to collapse
I suppose its okay for it to not be perfect but it shouldnt be that bad either. I wouldnt return it otherwise. That was definitely not a case where it would fix itself with user optimizations and a week of 'phone getting used to your patterns' bs. You clearly had a different problem if you achieved it without updates.
theblitz707 said:
I suppose its okay for it to not be perfect but it shouldnt be that bad either. I wouldnt return it otherwise. That was definitely not a case where it would fix itself with user optimizations and a week of 'phone getting used to your patterns' bs. You clearly had a different problem if you achieved it without updates.
Click to expand...
Click to collapse
Doesn't matter what the problem is most times because with Android there's always a work around even on stock Androids.
Each device and user are different... we're not all the same lame Apple
It's time consuming... until you work it out.
If you're waiting an update solution you're going to wait... and maybe still not get what you want.
That's why Gookill can jam Q and especially 11 up someone else's auxiliary port.
No real improvements and lots of useless cpu cycle robbing big sister bs. 12 will likely be worse... so I'm not throwing my money or time at it. I have that luxury.
Dead cats, dead rats
Can't you see what they were at?
blackhawk said:
Doesn't matter what the problem is most times because with Android there's always a work around even on stock Androids.
Each device and user are different... we're not all the same lame Apple
It's time consuming... until you work it out.
If you're waiting an update solution you're going to wait... and maybe still not get what you want.
That's why Gookill can jam Q and especially 11 up someone else's auxiliary port.
No real improvements and lots of useless cpu cycle robbing big sister bs. 12 will likely be worse... so I'm not throwing my money or time at it. I have that luxury.
Dead cats, dead rats
Can't you see what they were at?
Click to expand...
Click to collapse
just out of curiosity, what did you do to stop your phone from overheating?
theblitz707 said:
just out of curiosity, what did you do to stop your phone from overheating?
Click to expand...
Click to collapse
A whole lot.
First step was to disable all power management.
Then go after each offender on a case by case basis. Rogue 3rd party apps either get firewall blocked or deleted especially if they're are startup apps that don't need that privilege.
I use Package Disabler and Karma Firewall a lot.
I clear the system cache and use as needed the old Device Care powered by 360° (firewall blocked) to clear system caches and logs.
Disable all cloud junk, and other Google trashware.
Simply disabling Google play Services and Playstore when not needed gives you another 1-2%@ hr of battery life. They are hogs that tend to run needlessly.
Disable all feedback... it's data mining at your expense.
Sometimes I turn off battery background usage to certain apks like Android Services.
It all adds up... play with it.
Each device, OS and user are different, so what works well for me might puke on you.
Don't make too many changes at once and be aware of possible dependencies for the apps you alter. It's a learning curve... and sort of fun.
&
It's almost impossible to crash and burn* a stock Android. So get after it!
*always be ready for a crash. Backup all critical data redundantly and be ready to reload at any time. While very rare Android crashes give little or no warning. Slight system instability and lag are many times the only warnings you will get on a fast platform... then bam, boot loop.
blackhawk said:
A whole lot.
First step was to disable all power management.
Then go after each offender on a case by case basis. Rogue 3rd party apps either get firewall blocked or deleted especially if they're are startup apps that don't need that privilege.
I use Package Disabler and Karma Firewall a lot.
I clear the system cache and use as needed the old Device Care powered by 360° (firewall blocked) to clear system caches and logs.
Disable all cloud junk, and other Google trashware.
Simply disabling Google play Services and Playstore when not needed gives you another 1-2%@ hr of battery life. They are hogs that tend to run needlessly.
Disable all feedback... it's data mining at your expense.
Sometimes I turn off battery background usage to certain apks like Android Services.
It all adds up... play with it.
Each device, OS and user are different, so what works well for me might puke on you.
Don't make too many changes at once and be aware of possible dependencies for the apps you alter. It's a learning curve... and sort of fun.
&
It's almost impossible to crash and burn* a stock Android. So get after it!
*always be ready for a crash. Backup all critical data redundantly and be ready to reload at any time. While very rare Android crashes give little or no warning. Slight system instability and lag are many times the only warnings you will get on a fast platform... then bam, boot loop.
Click to expand...
Click to collapse
Im pretty sure your note 10 would be completely fine without any of those. If you updated a few times. But if you have to stay at initial firmware for some specific reason then fair enough. (Btw, I also used to disable google play and google services but at the time my phone had 834MB ram so it was really important, i dont think saving %1 battery is worth it at all)
When i had my S20+, phone didnt heat at all when idling so some bloatware/feedback/google services/rogue app etc. wasnt the issue. I learned from someone else it was fixed after november update. Anyways have a good day
theblitz707 said:
Im pretty sure your note 10 would be completely fine without any of those. If you updated a few times. But if you have to stay at initial firmware for some specific reason then fair enough. (Btw, I also used to disable google play and google services but at the time my phone had 834MB ram so it was really important, i dont think saving %1 battery is worth it at all)
When i had my S20+, phone didnt heat at all when idling so some bloatware/feedback/google services/rogue app etc. wasnt the issue. I learned from someone else it was fixed after november update. Anyways have a good day
Click to expand...
Click to collapse
That's a minimum. When Gookill is misbehaving it's battery usage far exceeds that and extends into when the screen is off.
My battery usage when sleeping with AOD on touch demand is 2-3% for 6 hours.
That 1 or 2% is also after much of the Gookill junkware was disabled.
Google and Samsung apps are the prime suspects... as usual.
My stock 10+ is heavily reconfigured, I have no quick fixes for you because none of mine were quick
As for updates, they ain't got nothing for me. Last thing I want is Q loading on this device.
It would gut Karma Firewall's functionality and destroy trusted overlay apks... for what?
I've already archieved all my favorite apks so I'm not longer dependent on Playstore. Playstore will eventually alter or delete them.