Hi, wondering if anyone can help?
I need a battery monitor program, but I need something with the following features.
1. It must run in the background, so that the device can be used as normal
2. It must record battery usage over time, and must store the data to a text file for later analysis and graphing
3. Ideally, it would also give me matching data for the battery temperature
4. It needs to run on a VGA device
5. It must run under Windows Mobile 6.1 Professional
Anyone know of a program that can do all these? HomeScreenUI is great, but doesn't log the battery levels, and can't get the battery temperature of the device I'm using. abcTaskMan graphs battery use, but doesn't run in the background, and doesn't log the data to a file either (or get the temperature).
Maybe Pocket Battery Analyzer may suit your needs but non free.
(http://www.wizcode.com/products/view/pocket_battery_analyzer)
Regards,
Thomas
I open the thread in DEV because I haven't got convincing answer until now.
I found many junior ROM makers and users delete the system apps as many as possible to think it will bring a longer battery usage. I also listened someone got a faster battery drain after deleting some apps like DrmProvider.apk or others.
Could someone explain the real reason please?
Will the missed apps make the system try to read the 'file' again and again so the battery drain faster or some other reasons?
And as mentioned in the begining, deleting those apps that donot affect the system will really bring a batter battery performance?
Thanks!
defw said:
I open the thread in DEV because I haven't got convincing answer until now.
I found many junior ROM makers and users delete the system apps as many as possible to think it will bring a longer battery usage. I also listened someone got a faster battery drain after deleting some apps like DrmProvider.apk or others.
Could someone explain the real reason please?
Will the missed apps make the system try to read the 'file' again and again so the battery drain faster or some other reasons?
And as mentioned in the begining, deleting those apps that donot affect the system will really bring a batter battery performance?
Thanks!
Click to expand...
Click to collapse
I'm no dev myseld, but you might find interresting reading what I've recently posted here: http://forum.xda-developers.com/showpost.php?p=16662568&postcount=10102
Don't take my words for it, but you can always delete apks one by one and carefully watch the logcat verbose to see if the system posts any strange behavior after doing so.
*** I take no responsibilty for you doing so - and do it at your own risks! ***
For sure deleting an apk that is needed by the Android system could make the battery usage worst; DRMprovider is probably a good example of a mandatory app - unless someone never listens to any audio at all.. I don't know the specifics for every error and what kind of energy the system would put into solving a bug related to a missing app -is this really important anyway?
I've deleted 30 apks myself from the system/app directory from CM7 and I did not see any drawback in doing so. Most of them are apks installed by the gapps.zip so they are not part of my stock rom per say -hence: both the system and myself can live very well without them.
I don't care much about saving battery by deleting them as much as: 1- saving space; 2-preventing the system to ever have to read or generate thumbnail previews (or anyhing else really) for those apks and most importantly 3- seeing apks listed in my "running apks" that I've never wanted to start in the first place.
I'm sure that you've read the comment that states that task killers are not needed with Froyo because the system now manages the ram usage very well..but I still kill aps many times a day. Some might say they're just listed but not using resources; well fine! But how can they prove that? If an apk is loaded in memory, it might do an update (or what not) once an hour or once day; that takes battery - not much- but it does and if it is not needed then...
One other good example would be my xda apk: it is always listed under the running task even though I logged out and exited the program. Checking it out with an apk like Process Explorer clearly shows that it still constantly uses up to 3%of the cpu unless I kill it properly... So all this to say: removing apks might not save you so much battery but it might save you some task killing.
Bottom line is: if you're sure that the apk is not needed why have it on the phone?
Battery saving might very well be negligeable and no one can say it's the case for every specific apks. Again, I removed those apks because they're of no use to me and my system seems to live well without them. But it's your job to make sure that deleting stuff is not detrimental for the system and that is the dev part of it.
Personally I use a Startup Manager kill anything or most anything that's listed that starts by itself including my xda app. Never understood why on the Defy there's 15 to 25 apps up and running when they're not being used. And why they start themselves. I don't need my music apps starting by themselves.Or Documents to Go/Equalizer/GPS Tracker/Maps, etc., etc. I'll manage my own stuff, thank you. I would think all those apps running in the background would affect battery life. I have also deleted some of the crapware. Seems to me battery life has increased and when I run Advanced Task Manager I'm only killing 5-6 apps instead of 15-20.
btw wrong section to post...
MikeChannon
please move this thread.. in here..
http://forum.xda-developers.com/forumdisplay.php?f=853
Hi everyone!
As a desire user myself, some of us are already familiar of what I'm talking about: the famous problem of Desire shutting itself down while it was showing a percentage of 15 (or sometimes even higher) percentages!
This problem is a troublemaker, because it's causing the battery to deplete deeply - which is a bad thing for a Li-Ion battery - and also causing you unguarded: you think that you have enough battery to make it home, but hey; your device is dead!
The reason?
The cause of the problem is battery aging. Even though Li-Ion batteries don't have memory effect problems, they are batteries after all and like every battery they get older and lose their capacity.
Ideally (old or new) the battery shows 3200 mV when empty and 4180 (sometimes 4200) mV when it's full. This never changes unlike NiMH batteries - it's why Li-Ion batteries are told "never to suffer from memory effect". The thing is, cells get older in time and even though they always yield the same voltages, they might not last the same (mAh value gets lower). This is called "aging" in batteries.
In HTC Desire device, there is a Battery Controller chip (it's Maxim DS2784 Chip) that is responsible with the battery capacity, percentage estimation; as well as aging compensation. However, during my examinations (since I did have this 15% shut down problem myself) I've noticed something major in the HTC Desire Sense Kernel sources:
A small code piece in ds2784 battery driver which is written with a false assumption is causing your Desire to think it has full "brand new" capacity, which is not the case if you're owner of an aged one! Due to this, your device thinks it has more capacity, when it's actually empty (which occurs at 15-20% depending on the battery) and shutting down at weird percentages.
Solution?
Well, it's something called "Battery Calibration" which more info can be found on this thread (especially check post #3 for the instructions) : http://forum.xda-developers.com/showthread.php?t=765609
(It's Nexus One dev. forum, but don't mind it - the process is exactly the same for us)
The thing about this calibration is; you have to do it under CM or Oxygen ROM's, because it requires a modified AOSP kernel. During my checks, I've seen that this is actually simply because the Sense kernel lacks some sysfs entries - other than that, Sense driver is also capable of doing this calibration - with the help of Jon Richard's "Battery Calibrator" (available at the Play Store (Market) ).
Also, the calibration data normally (I don't really know why) gets erased when you charge your device while off - the way to fix this is available in here: http://forum.xda-developers.com/showpost.php?p=23317695&postcount=2112
OK.. Is this all?
No. Actually this part is more important.
While I'm including this piece to the Sense Kernel, I've seen the following buggy code piece, which is resetting your battery capacity to 1392 mA - which is wrong (too much) if your battery is aged one:
Code:
if ((htc_batt_info.rep.level != 100) &&
(htc_batt_info.rep.guage_status_reg & 0x80) &&
(htc_batt_info.rep.batt_current <= 80) &&
(htc_batt_info.rep.full_acr == 0)) {
acr[0] = 0x0d;
acr[1] = 0x87;
w1_ds2784_write(di->w1_dev, acr, DS2784_REG_ACCUMULATE_CURR_MSB, 2);
htc_batt_info.rep.full_acr = 1;
pr_info("[HTC_BATT] Current Full ACR = %x %x\n", acr[0], acr[1]);
pr_info("[HTC_BATT] Recharging should set ACR to 100 percent\n");
}
Noticed the "acr" part? That's the part where the driver wrongly assigning 1393 mAh to the DS2784 chip.
If you're to read DS2784 battery specification, under "ACR Housekeeping" part, the following is written ;(ACR - Accumulated Capacity register - the register which shows your current capacity of battery as mAh):
ACR Housekeeping
The ACR value is adjusted occasionally to maintain the coulomb count within the model curve boundaries. When
the battery is charged to full (CHGTF set), the ACR is set equal to the age scaled full lookup value at the present
temperature.
Click to expand...
Click to collapse
It clearly states that the ACR value, by chip itself, is already updated to the Full value available in ROM chip! The driver doesn't need to do that (and doesn't need to do that WRONG AT ALL!).
This is the problem, because we calibrate our batteries, and then simply because of a buggy assignment of the driver, we lose all the calibration we made!
Cut the story.. Can you fix this?
Well, already did. Attached to the end of this post, there is a "ds2784_battery.c" file which all the stuff I mentioned in this post is applied to. In the kernel source, change in the kernel source dir drivers/power/ds2784_battery.c file with the one I provided and recompile the kernel - voila, you can now calibrate your battery and it no longer will screw your calibration.
Diff patch?
Available below.
Do I have to compile kernel myself? I'm not a geek like you, man!
Flashable recovery zip for kernel is added to the post (named ahmet-exp4_*.zip)!
And here is what completes the circle: The Battery Calibrator App, modified to work with our kernel!
Can be downloaded here
------------
EDIT: I've added the patch file, and also changed the source file itself - I mistakenly forgot to uncomment the parts which include the sysfs interface, sorry
-----
ADDENDUM (11.03.12): CFS Version is included to the post. Soon, I shall include the Droidzone's battfix into it for high capacity batteries as well, but I kinda think that Droidzone's fix is "not complete" so I'll rewrite it from scratch and thus it does take some time. I guess I can put it next weekend.
-----
ADDENDUM (13.03.12): An improved (?) version of Droidzone's Extended Battery fix has been enabled into the battery driver. Also, HAVS and SVS versions are added for those who prefer (version string does keep these info too, if you forget in the future ). Diff patch is updated with the changes.
About extended batt-fix: Please note that I couldn't test the driver with an Extended battery, but I changed the register parts, so it should run with any battery now since it reads all the data from the Chip's EEPROM instead of using "hardcoded" values.
I also lowered the RSSI values in iw_wl.h file -> now your wifi should not drop so easily as it was in the past (it was -91; I made it -110 ). Diff and edited file are added.
NOTE: My kernels do include nearly all I/O schedulers inside, so that you can change them as you like. If you think your device doesn't perform well with the read/write operations to sd-card or MTD partitions, you can change your I/O scheduler following way:
first, query the modes. You can google-search them to learn what they mean :
--> cat /sys/block/mmcblk0/queue/scheduler (for mmc card)
--> cat /sys/block/mtdblockX/queue/scheduler (for internal memory. X becomes partition number: you can query it with "cat /proc/mtd")
After this, you can pick one and apply that - for instance, say, you picked BFQ (I like it ):
--> echo "bfq" > /sys/block/mmcblk0/queue/scheduler (for mmc card - same applies to MTD too, if you need)
WHY BFQ? Because since SD-cards are Solid State Disks, so they don't have a mechanical head thus V(R) or such schedulers which are optimised for access times are not so optimised for us I think. Instead, we should aim towards the schedulers which takes "load" into consideration. BFQ is one of such schedulers.
I just checked it with my device, I tell you: the results are really amazing How much a scheduler matters is exemplified really
-----
ADDENDUM (15 March 2012): CFS_SVS Version is updated to EXP5; because of some freeze up problems. This version doesn't add anything else, so the old files still stay at EXP4 version
NOTE: I don't have 2Way Call recording sources, so my kernels don't have that feature (I cannot do everything, can I )
---------------
Thank you very much for the donations of Sally Mack
I really appreciate it You really save my life with your donations
F A Q
1- I open the app, but all the values look empty!
It's because you are not using a compatible kernel. As far as I know, only mine and Droidzone's latest kernels do have the necessary patches, so switch to one of them.
2-I cannot drop to 3201 mV!
Some batteries cannot drop into that level, it's true. If your device turns off at higher voltages - like 3400 mV - you can use this value for your registers instead. Please read the following pages or DS2784 chip spec.to use your own value here (key registers are 62 and 63)
3- I drop to 3201 mV, it says "plug the charger" and I plugged. Still device turns off!
This is due to Sense kernels using a different power supply drivers than AOSP kernels; and due to Sense kernels being "less sensitive" to the changes in battery status, thus not sensing the charger plugged it. In order to overcome this, you must decrease your battery usage to a minimum so that your battery can last a little more - just enough for Power Supply driver to sense it. To achive this:
1- At about 3350 mV values, turn on the Airplane mode; decrease the screen brightness to a very low value.
2- Once the program tells you to plug in, plug in right away and then turn your screen off with the power button.
If your device is not turned off within 2 minutes, your learning phase should have begun.
4- Still the phone turns off at 3201 mV!
It's very much likely those solutions above will work; but in case they don't and you want an "easier" calibration - try calibration at some AOSP ROM like Cyanogen Mode ROM or Oxygen ROM (i.e. you have to change your ROM at least temporarily) . AOSP kernels are more "open" to calibration.
5- Do I need "ahmet" kernels for AOSP?
No. All current AOSP Roms come with a modified kernel that's already supporting the calibration - and they are also free of the Sense kernel bug mentioned above since they're completely written from scratch!
6- Can I change ROMs or Kernels after the calibration?
Changing ROMs are OK as long as you use ahmet or Droidzone's latest kernels (i.e. kernels that support calibration) with your new ROM. You should flash the ROM prior to booting your device for the first time.
NOTE HERE: If you're to flash AOSP ROM, don't use ahmet-exp kernels with them since ahmet-exp kernels are Sense kernels. All AOSP ROMs are calibration friendly anyway.
Changing kernels is a tad more tricky: you can change into the kernels that support calibration only: that is either into ahmet-exp or Droidzone kernels.
Good work, I'm glad that somebody found a solution for this problem.
I'm waiting for the fix, can't wait to test it and see how it goes after that, if it'll help my batt and increases it's life.
What else to say, thumbs up and keep up the good work.
So is needed one battery calibration after change the kernel?
Tapatalking
ironjon said:
So is needed one battery calibration after change the kernel?
Tapatalking
Click to expand...
Click to collapse
After every flash/ROM change it is advised to wipe battery stats and calibrate it if you flashed while your phone was plugged in to USB or charger.
This is logic, new ROM, new stats.a battery stats wipe is advised as I said but calibration...I don't think so, you need to do that just once (as I saw on other threads).
What I do after flashing a new ROM/kernel is just to let the phone discharge untill it shuts down, charge till it's full and wipe battery stats.
nomatterbv said:
After every flash/ROM change it is advised to wipe battery stats and calibrate it if you flashed while your phone was plugged in to USB or charger.
This is logic, new ROM, new stats.a battery stats wipe is advised as I said but calibration...I don't think so, you need to do that just once (as I saw on other threads).
What I do after flashing a new ROM/kernel is just to let the phone discharge untill it shuts down, charge till it's full and wipe battery stats.
Click to expand...
Click to collapse
I' ve done that many times and my phone still shutdown at 15% aprox
Tapatalking
ironjon said:
I' ve done that many times and my phone still shutdown at 15% aprox
Tapatalking
Click to expand...
Click to collapse
I flashed the ROM which is in my signature, optimised it and I don't have that problem any more (it shuts down at 2-3%, when it reaches that % it drops down to 0 instantly).
Try to flash other ROM and change kernel, also use the latest RIL and Radio, it might help you. for me it worked.
Just wait untill theGanymedes posts the fix, flash it and see if it'll help you out, it'll need some tests but anyway, I think it will help.
nomatterbv said:
I flashed the ROM which is in my signature, optimised it and I don't have that problem any more (it shuts down at 2-3%, when it reaches that % it drops down to 0 instantly).
Try to flash other ROM and change kernel, also use the latest RIL and Radio, it might help you. for me it worked.
Just wait untill theGanymedes posts the fix, flash it and see if it'll help you out, it'll need some tests but anyway, I think it will help.
Click to expand...
Click to collapse
Thx
I'm trying to fix it with the latest bananacakes' sources but I got some errors:
[email protected]:~/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d$ make ARCH=arm CROSS_COMPILE=arm-linux-androideabi- -j10
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
mm/built-in.o: In function `frontswap_curr_pages':
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:235: undefined reference to `swap_list'
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:235: undefined reference to `swap_info'
mm/built-in.o: In function `frontswap_shrink':
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:207: undefined reference to `try_to_unuse'
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:214: undefined reference to `swap_info'
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:214: undefined reference to `swap_list'
mm/built-in.o: In function `__frontswap_flush_area':
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:153: undefined reference to `swap_info'
mm/built-in.o: In function `__frontswap_flush_page':
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:139: undefined reference to `swap_info'
mm/built-in.o: In function `__frontswap_get_page':
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:125: undefined reference to `swap_info'
mm/built-in.o: In function `__frontswap_put_page':
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:104: undefined reference to `swap_info'
make: *** [.tmp_vmlinux1] Error 1
Better to wait the patch
great work this is something I'm really glad to see as I get caught out by this bug a lot, the question is now are there any pro compiled kernel flashes available that use this.
Im using Runnymede AIO v6.0.7 SE so would need a sense based kernel that works well with that.
Drefsab said:
great work this is something I'm really glad to see as I get caught out by this bug a lot, the question is now are there any pro compiled kernel flashes available that use this.
Im using Runnymede AIO v6.0.7 SE so would need a sense based kernel that works well with that.
Click to expand...
Click to collapse
You'll find here everything you need, including sense kernels
nice work, thank you for sharing with us.
i will wait for kernal
Sent from my HTC Desire using Tapatalk
wow...nice thing...good work... thx for this...
but i hope we can get a diff patch...as i think if i use your file the batt charge fix is gone or...did you use droidzone patch also..?
with kind regards
Alex-V said:
wow...nice thing...good work... thx for this...
but i hope we can get a diff patch...as i think if i use your file the batt charge fix is gone or...did you use droidzone patch also..?
with kind regards
Click to expand...
Click to collapse
You can use this.
Thanks, theGanymedes. This was on my todo list for a long time.
Droidzone said:
You can use this.
Thanks, theGanymedes. This was on my todo list for a long time.
Click to expand...
Click to collapse
and i thank you...as always...lol
with kind regards
So can it be also implemented to snq kernel ?
pavel54 said:
So can it be also implemented to snq kernel ?
Click to expand...
Click to collapse
No...as snq never released his source
Sent from my HTC Desire using XDA Premium App
dont want to sound noob but is there any chance of implementing this fix in ICS kernels like: Tiamat 2.6.28 ICS?
as my ICS rom also shuts down at above than 15%.
thank you
or implement it in manus kernel
Yeah, SNQ didn't release his sources, alas.
And thank you Droidzone! I don't know what would we do without you However, your patch is faulty - for some reason, it messes all the file. I've included the patch that'll do it correctly to the first post
About the battery fix - I didn't touch that part but know that bananacakes's sources do have them.
Compiled kernel is delaying a little bit - because my toolchain is faulty, for some reason producing unbootable kernels - going to upload it to the first post when it's ready.
Also another thing: since the sysfs interface placement is different than AOSP kernels, the battery calibrator app on the Market doesn't work with our patch - the files necessary for the program to work is in somewhere else in our system. So, I'll try to find a way to "create symbolical links" or if I can't, I'll rewrite the app - apparently Jon Richards didn't publish his sources for the app :/
How Android manages Memory
Android groups all apps into 6 groups, from highest priority to lowest:
Foreground app - you see this app on screen, currently running, but also includes the system itself and "phone"
Visible app - the app is running and visible, but due to multi-tasking or such is not currently "on top"
Secondary server - services that stay in background and apps such as Launcher (or other home replacements). Most services go here, like music player, clock updater, background sync, and so on, that's not built into the OS.
Hidden Application - apps not visible, but still running in the background
Content Provider - process that provides content to the foreground, such as "contacts content provider", "calendar content provider", and so on. May also known as "storage".
Empty App - the app is in standby, not being used, but is still in memory.
How to manipulate this to get the best performance
We can manipulate our OOM values for each of these categories using the app "System Tuner Pro" (not sure if it works with the free version or not) or "Auto Memory Manager", there may be others too. After installing from the market, open it and click on "Memory" - you will then be able to change OOM values. Having a lower OOM value for a category, means android will wait longer until killing apps from that group.
From what I have experienced, the more open apps in the "Empty App" category, the slower and more sluggish the phone. Having these apps open is basically a waste of memory, because they are in standby and not being used. A high OOM value should therefore be set for "Empty App".
Processes that fall into the "Content Provider" category are also a waste of space; they only actually get used when running the application that service belongs to. This means that often the service will be running in the background when it doesn't actually need to be. A high OOM value should therefore be set for "Content Provider".
The other four categories all contain apps actually being used by the user. When multitasking you want these apps to stay open. A low OOM value should therefore be set for "Foreground App" "Visible App" "Secondary Server" and "Hidden Application"
Doing this is similar to what the SuperCharger Script does, but in my opinion this solution is simpler to implement and easier to change depending on the users needs.
I have attached a thumbnail of my setup, but everyone uses their phone differently so you may want to alter some of the values.
Click Thanks if you tried this and it helped!
BUMP
Thanks for the guide, trying this out to see if I notice some improvement in my phone.
how do you get the values to stick? I duplicated what you did and backed out and the original presets came back after a reboot. I did not see a "save" option. thanks.
steve austin said:
how do you get the values to stick? I duplicated what you did and backed out and the original presets came back after a reboot. I did not see a "save" option. thanks.
Click to expand...
Click to collapse
After applying the limits, there's a button at the bottom of the page called boot settings.
On the menu this takes you to, click reapply memory settings and then check on boot completed
Sent from my HTC Sensation using XDA
sorry for the noob question, but are u sure its not the other way around? i mean, setting a higher value would mean the app is going to stay running in the background for a longer time?
alireza_simkesh said:
sorry for the noob question, but are u sure its not the other way around? i mean, setting a higher value would mean the app is going to stay running in the background for a longer time?
Click to expand...
Click to collapse
I had this EXACT same initial thought. However, once I stepped back and looked at it again, I realized that he is correct in what he originally posted.
What the high values in his screenshot are basically saying is "When I get to less than 256mb free memory, I am going to dump all the applications of this type" and the low values are basically saying "When I get to only 3mb of free memory then I am going to dump all the applications of this type."
So if you set it HIGH like the original poster said then it will dump those out of memory faster than if you set them to 100mb because then you'd have to have more things filling up memory before they would be dumped.
Hopefully that clears things up a little for you (and others who I'm sure will have the exact same question).
-- Zeustopher
Zeustopher said:
I had this EXACT same initial thought. However, once I stepped back and looked at it again, I realized that he is correct in what he originally posted.
What the high values in his screenshot are basically saying is "When I get to less than 256mb free memory, I am going to dump all the applications of this type" and the low values are basically saying "When I get to only 3mb of free memory then I am going to dump all the applications of this type."
So if you set it HIGH like the original poster said then it will dump those out of memory faster than if you set them to 100mb because then you'd have to have more things filling up memory before they would be dumped.
Hopefully that clears things up a little for you (and others who I'm sure will have the exact same question).
-- Zeustopher
Click to expand...
Click to collapse
Yes that's exactly right, sorry I should have probably explained that a bit better initially.
Zeustopher said:
I had this EXACT same initial thought. However, once I stepped back and looked at it again, I realized that he is correct in what he originally posted.
What the high values in his screenshot are basically saying is "When I get to less than 256mb free memory, I am going to dump all the applications of this type" and the low values are basically saying "When I get to only 3mb of free memory then I am going to dump all the applications of this type."
So if you set it HIGH like the original poster said then it will dump those out of memory faster than if you set them to 100mb because then you'd have to have more things filling up memory before they would be dumped.
Hopefully that clears things up a little for you (and others who I'm sure will have the exact same question).
-- Zeustopher
Click to expand...
Click to collapse
Yea i get it now.
the program developer must make the interface a bit more clear
thanks. I will apply it today and see what happens.
Notification improvement in smoothness in UI.
But setting too high minfree in empty application cause alot of launcher redraw.
cwk_and said:
Notification improvement in smoothness in UI.
But setting too high minfree in empty application cause alot of launcher redraw.
Click to expand...
Click to collapse
That's odd, the launcher usually sits in visible or secondary server... what launcher are u using?
Sent from my Sensation using XDA
I am using Auto Memory Manager for this, thanks for the write up.
mf2112 said:
I am using Auto Memory Manager for this, thanks for the write up.
Click to expand...
Click to collapse
No worries
Didn't know that app existed, will add it to the guide thanks!
I applied your settings to see what happens.....I hqve a question for you. In cm9 and aokp there is setting for Max background process limit.....would you suggest any modification here as well?
dmeinder said:
I applied your settings to see what happens.....I hqve a question for you. In cm9 and aokp there is setting for Max background process limit.....would you suggest any modification here as well?
Click to expand...
Click to collapse
You could give it a shot and see if it helps but I doubt it will. If anything, it will limit multitasking because apps will get closed before OOM values are reached.
Hope that helped
Sent from my Sensation using XDA
this is nice trick but it realy save battery and perfom cpu.
As far as I have heard oom values are not these memory settings you mention. OOM is a specific value for each app. The lower it is, the less prone the system is to kill it off.
I have System Tuner pro but couldn't find how to change the oom value. Only app that could change it is autokiller and those settings don't stick or even work.
My memory settings are killing off some apps that I would like to keep in memory.
making empty app so high means no multitasking at all it will kill almost every app once you exit it, tried these and as sson as i leave browser it closes itself, for multitaskers use 45 for hidden, 70 for content provider, 85 for empty app, do not set it lower than 85 or you may encounter a lag that you can't get rid without taking the battery off because you won't be able to close an appliation with that lag. By the way other three values are not that important set them 7-15-20 no problem at all.
Tom200 said:
As far as I have heard oom values are not these memory settings you mention. OOM is a specific value for each app. The lower it is, the less prone the system is to kill it off.
I have System Tuner pro but couldn't find how to change the oom value. Only app that could change it is autokiller and those settings don't stick or even work.
My memory settings are killing off some apps that I would like to keep in memory.
Click to expand...
Click to collapse
I don't know what ur on about, the tweaks in system tuner pro are for OOM values.
You need to do some more research mate.
Sent from my Sensation using XDA