yashsingh1/xdaforums huggingface dataset:
[Samsung Galaxy Nexus] The Gingerbread Man:
Light flow, I don't think does, whatsapp might cause some drain. Apps that have prolonged bull**** services running in the back ground, leaving. GPS on maps and auto report of location, Google now are prime examples.

I believes its been mentioned recently, anyone with battery issues should search up better battery stats, there's a free xda version of you look hard enough. Search up on wake locks you don't understand and learn to control your device

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] jcmm11:
This app is a bit simpler to use then bbs when searching for wake locks.

https://play.google.com/store/apps/details?id=com.uzumapps.wakelockdetector

Charge phone, unplug, allow to sit and sleep for a few hours. Then check to see what wakelocks were running for how long.
[Samsung Galaxy Nexus] osm0sis:
BBS is still better since it has the knowledge base and you can make a dump for others to review.

Facebook you need to disable push notifications. All apps really. Set intervals. Longer the better. If you need to use Exchange ActiveSync mail (Hotmail, Outlook, corporate), disable the calendar sync. Lightflow has been mentioned many times in the BBS thread, not sure if specific settings help that or not. Disable location updates in Maps. Sign out of GTalk when you aren't using it, even if you've never used it. If you don't use it, sign out then disable it. Disable as many system apps you don't use as you can. Any games that have push notifications that you can't disable from within, suppress their notifications in App Info. Those are just the basics. Happy wakelock hunting! ;)

The BBS thread is really the place for this though. Lots to read and search there. Also lots of helpful folks if you post your log appropriately (dropbox/pastebin and link). There and here are where I think I've learned the most since joining xda.
[Samsung Galaxy Nexus] irminsul:
Lag returned a bit after 24 hours setting dalvikvm, restarted systemui all smooth now.

Verstuurd van mijn Galaxy Nexus met Tapatalk
[Samsung Galaxy Nexus] Khrushy:
I known right. I'm sure I'll find out soon enough - someone in my office always has the latest and greatest.
[Samsung Galaxy Nexus] osm0sis:
Maybe it's a bit of a trade off between short and long term performance and that's why they raised it.
[Samsung Galaxy Nexus] whitedragonz83:
I found this (slightly old) report:

http://www.jeffmixon.com/examining-build-prop-tweaks-for-android-ics-a-comprehensive-guide-part-1/

He discusses these 2 variables a little. Just throwing it out there to read.
[Samsung Galaxy Nexus] osm0sis:
I compared all the build props for the Nexus S, Galaxy Nexus, Nexus 7, Nexus 4 and Nexus 10.

The guy was definitely wrong about the second value, it's always been 256 on the GN, not 384 as on the N7. And the first value became 96 only with 4.2 because the dalvik.vm.heap clearly became more complex, and has gradually over time: heapstartsize and heapgrowthlimit were introduced with Android 4.0; and heaptargetutilization, heapminfree and heapmaxfree were introduced with Android 4.2. Probably the dynamic control Google was talking about in the link above.

So what the guy was talking about was only half the story.

It actually went from (takju-imm76i and takju-jzo54k):

dalvik.vm.heapstartsize=8m

dalvik.vm.heapgrowthlimit=64m

dalvik.vm.heapsize=256m

To (takju-jdq39):

dalvik.vm.heapstartsize=8m

dalvik.vm.heapgrowthlimit=96m

dalvik.vm.heapsize=256m

dalvik.vm.heaptargetutilization=0.75

dalvik.vm.heapminfree=512k

dalvik.vm.heapmaxfree=8m

Which makes perfect sense if the actual size is something like a function of the targetutilization and the growthlimit. 0.75 * 96m = 72m. And following from that, the actual size would only be increased by 8m, to 72m from 64m, but now in Android 4.2 it has a further margin to expand if required where it didn't before. Probably a good thing. Programmatically buffers are better than hard limits.

If that is the case then setting it to 64 is not the same as reverting to the 4.0-4.1 values, it would actually be like lowering it to 0.75 * 64 = 48m. He does have a point that they stayed the same on nakasi between 4.0-4.1 and 4.2, but who knows, maybe the N7 is the one that it should have been increased on and the GN is correct. The N4 and N10 both have growth at 192m, and size at 512m, so the N7 is more the odd-one-out now.

Anyway, I'm just guessing there, but I know these values are fairly different on each device, clearly depending on how much memory the specific device has available, so I don't think they're worth the headache to accommodate or our time to tune when Google clearly knows better than the guy who filed the issue. :p
[Samsung Galaxy Nexus] pkgnex:
Got my first reboot in MONTHS! - running BFQ at the time.

I was typing a text and after sending, my keyboard wouldn't lower even though I kept hitting the back button and screens were closing out. Then when I got to the home screen, I got the reboot.

Here's the link to my last_kmsg. I'm no expert, but there does look to be some BFQ stufff shortly before the kernel panic and reboot.

https://dl.dropboxusercontent.com/u/78555859/last_kmsg
[Samsung Galaxy Nexus] osm0sis:
Follow-up: The N7 is definitely the odd one out.

These are the values for the N4 and N10:

dalvik.vm.heapgrowthlimit=192m

dalvik.vm.heapsize=512m

dalvik.vm.heaptargetutilization=0.75

0.75 / 2 = 0.375 * 512 = 192.

GN:

dalvik.vm.heapgrowthlimit=96m

dalvik.vm.heapsize=256m

dalvik.vm.heaptargetutilization=0.75

0.75 / 2 = 0.375 * 256 = 96.

N7:

dalvik.vm.heapgrowthlimit=64m <=

dalvik.vm.heapsize=384m

dalvik.vm.heaptargetutilization=0.75

0.75 / 2 = 0.375 * 384 = 144.

Three devices (N4, N10, GN) makes a pattern. So however the new implementation of dalvik heapsize works, I think GN people can safely relax because the math for our device at least matches; Google likely got it right. The N7 on the other hand.. ;)

Gotta do your homework before taking it to The Man! :D

P.S. I hope Chazz likes my use of colors. :p
[Samsung Galaxy Nexus] Syfer_Fever:
so do we have to change dalvik heapsize and heapgrowthlimit just like N7, N10, or N4?
[Samsung Galaxy Nexus] osm0sis:
Wow... :eek:

Did you even read my posts?
[Samsung Galaxy Nexus] Syfer_Fever:
yes but still don't understand, maybe because my english not so good :confused:

but someone post that he change dalvik healsize and heapgrowthlimit to 64m and 384m (just like N7) and he said that changes fixes the lag on GN :confused:

does it affect performance?

==========================

edit : ok just read again your post and you said no need to change anything with dalvik heapsize and heapgrowthlimit because our device calculation already matches and got it right and we just relax about it. sorry for my mistake
[Samsung Galaxy Nexus] osm0sis:
I'm saying that guy at the link was likely wrong. And even if there is a better number we could tweak it to, it's probably not as simple as changing them back to what they were in 4.1 because dalvik heapsize works differently now.

Here's the take-away. :good:
[Samsung Galaxy Nexus] DoesntPostAThing:
But what if we were to find better numbers? For example,

1/2 = 0.5 * 256 =128

This one seems unlikely, but perhaps it will work.

0.5/2 = 0.25 * 256 = 64

This one, maybe?

What I'm thinking is a way to turn the new method off and revert to the old way, since even though the new way is better, the old way was smoother.
[Samsung Galaxy Nexus] osm0sis:
Well yeah if you think Google's math is terribly wrong, go for it. But you'd probably need to mess with more than just growthlimit to do it right. I'm just saying what they did wasn't a mistake, since the numbers have the same relationship on the GN as on the N4 and N10. Anyway if you feel like playing:

getprop | grep dalvik

to see what's what. Then:

setprop <key> <value>

No need to **** around with your build.prop or rebooting. Have fun! ;)
[Samsung Galaxy Nexus] haxor:
Next version of Android to be 4.3, still called Jelly Bean.

http://www.androidpolice.com/2013/04/26/google-is-working-on-and-testing-android-4-3-its-still-jelly-bean/
[Samsung Galaxy Nexus] The Gingerbread Man:
Do you know why? Fragmentation. Number version increase = better system, give it the same name a higher % of devices land on 'jelly bean' either through update or new devices launched. Now if it were to be 5.0 key lime pie it would increase fragmentation because 0.1% devices on the market would be running it thus making a nice big gap in percentage of devices running latest android version. This kind of reminds me of 2.0/2.1/2.2/2.3
[Samsung Galaxy Nexus] osm0sis:
Might also be the last dot version for the GN to receive..
[Samsung Galaxy Nexus] The Gingerbread Man:
Probably, I'll get on the ROMs when official support is over and a new version comes out
[Samsung Galaxy Nexus] osm0sis:
Exactly my plan too. Things are gonna get a little crazy. :D
[Samsung Galaxy Nexus] Angelakaro:
They can call it eclair, but i hope 4.3 will brings a lot of performance and battery and stability improvements

Inviato dal mio Galaxy Nexus
[Samsung Galaxy Nexus] haxor:
thats 100% correct buddy android give the chance to all OEMS to distribute appropriate version to their flagship :good:
[Samsung Galaxy Nexus] 15israellai:
The GN has still got a long way to go.

Sent from my Nexus Prime
[Samsung Galaxy Nexus] The Gingerbread Man:
Potentially but don't get your hopes up for prolonged official support, I imagine we will get this one. In November time a new nexus will come out and support will finish officially, like what happened to nexus s when n4 came along. The joy of nexus is they are famous for long term non official support.
[Samsung Galaxy Nexus] airjyp:
is there a franco kernel for ics 587 please ? thx :)

[FONT="Arial ="5"]

• Sony Live with Walkman
[Samsung Galaxy Nexus] The Gingerbread Man:
Is that an ice cream sand which rom? Browse through here http://minooch.com/franciscofranco/Galaxy Nexus/JB/
[Samsung Galaxy Nexus] Bl4ck3urn:
Wrong forum, you have a Sony device.
[Samsung Galaxy Nexus] osm0sis:
:laugh: You guys I think he was joking about them not changing the name from Jelly Bean.

---------- Post added at 12:30 PM ---------- Previous post was at 12:28 PM ----------

Oh no wait you're right, it's a real thing for Xperia devices! :p
[Samsung Galaxy Nexus] DoesntPostAThing:
However, we'll be getting ROMs for a long long time.
[Samsung Galaxy Nexus] osm0sis:
Hell yes. Like The Gingerbread Man said, it's great having a Nexus. :cool:
[Samsung Galaxy Nexus] The Gingerbread Man:
Especially considering when I had my old x10i if you flashed a rom you would end up without a camera, took a lot of time to get fixed, over 1 year for that bastard of a boot loader to get unlocked by a whole bunch of people who tried it. It was locked down tighter than an ants xxx hole!
[Samsung Galaxy Nexus] Puzzlegirl:
So *that's* where I remember you from! No wonder I was puzzled in those days with the x10 :confused:

Just updating a ROM on the GNex, it's so slow without Franco kernel :eek:
[Samsung Galaxy Nexus] alfiemenace:
I know someone from Google, just wait for the big boom hahaha
[Samsung Galaxy Nexus] DoesntPostAThing:
About the dalvik heap stuff again, I checked on my Skyrocket's 4.1.2 TouchWiz ROM (custom, of course). It uses the "4.2.2" way, with the 0.75 thing. It's values were 64/256/0.75, which doesn't match, according to osm0sis's post in previous pages. That said, I changed it to 96 with no difference in performance. I'm guessing TW is too laggy anyways. On my GNex however, it's smooth again on 96/256 and I haven't bothered finding a possibly better combination.
[Samsung Galaxy Nexus] osm0sis:
I've been playing around with it on the N7 since 64/384 is well lower than the 144 that Google's math says it should be. 144 felt okay, also tried it at 96 (which would match the 4.0-4.1 math of having it at a quarter, perhaps felt a bit better? Hard to say.
[Samsung Galaxy Nexus] 15israellai:
exactly.

Sent from my Nexus Prime
[Samsung Galaxy Nexus] DoesntPostAThing:
The only Nexus I own is the GNex, but I tried 64/256/0.5. I believe it's a little bit smoother, but can't really tell the difference. However, according to your first post, it would mean 0.5 * 64 = 32, meaning actually equivalent to 24, which is way lower than 64. Perhaps things will get kicked out of RAM a lot faster. One more thing left to try is 128/256/1, though I doubt that is a good idea.
[Samsung Galaxy Nexus] ChazzMatt:
no Key Lime Pie for you -- yet

Next version of Android to be 4.3, will retain Jelly Bean name:

This is actually good news, as it gives more people the chance to get out of the "Gingerbread" and "ICS" era to "Jelly Bean". And good news for all the GNex kernel developers?

Thanks to haxor for finding this:
[Samsung Galaxy Nexus] osm0sis:
Nah that post was just a guess - I wouldn't use it to try and figure anything out, since I don't know if that's how it actually works. We'd have to look at the code. I was just trying to make the point that with the added variables (like target, etc) in JB4.2, raising it to 96m, in practice, might not actually be that far off of the old dalvik heap's 64m.

I'd go more by what Google's math actually seems to be, which is they want growthlimit at half of targetutil * heapsize.

So you were potentially more correct with 64/256/0.5 since 0.5 / 2 = 0.25 * 256 = 64. :)

To assume Google has that wrong, you could also just go ahead and divide targetutil by 3 and come up with what the guy in the heap issue thread unknowingly did, which is 0.75 / 3 = 0.25 * 256 = 64. That math is (target/3) what I'm trying on my N7 right now.

hs=`getprop dalvik.vm.heapsize | cut -dm -f1`;
htu=`getprop dalvik.vm.heaptargetutilization`;
hgl=`awk -v htu=$htu -v hs=$hs 'BEGIN { print (htu / 2) * hs }'`;
setprop dalvik.vm.heapgrowthlimit $hgl'm';

This init.d script snippet takes the build.prop numbers and calculates/sets the heapgrowthlimit by Google's current formula. As is, it works on the N7 to bring it in line with the other Nexus devices with 144/384/0.75 and will leave the others the same. Or you could change the 2 to a 3 like I said above to see how 64/256/0.75 works on the GN. That gives 96/384/0.75 on the N7. If you want to get crazy with changing the target you could add setprop dalvik.vm.heaptargetutilization 0.5 or something above it.

As always, no build.prop edits required. ;)

Edit: Added correct method for changing target util.
[Samsung Galaxy Nexus] DoesntPostAThing:
Based on actual performance, I don't notice much difference between 64/236/0.5 and 96/256/0.75. Both generally smooth, but I feel that with 64/256/0.5 I get better performance when I briefly exit out of a game like 14px. I don't generally play 3D games like Modern Combat or NFS, and 14px is the most demanding game I have on my phone right now. Previously, it would lag quite a bit when transitioning in and out of it, but not sure if just the occasional smoothness. Will have to monitor more.

As for the 2 and 3 though, if it's a 2 on Google's 4.2 "flagships", then I believe it's meant to be a 2. However, 2 could be meant for 2GB RAM devices with 3 meant for 1GB? I'm not 100% sure, and as you said, we'd need to look into the code. I'm not at all familiar with AOSP code, so I probably won't be much help in that part.

EDIT: If needed, I have a Skyrocket that I can test on. Be it TW ROMs, AOSP ROMs, or even back to Gingerbread, I can check the build.prop for it. It's specs are very similar to the GNex, with a Snapdragon S3 dual-core 1.5GHz and 1GB RAM.
[Samsung Galaxy Nexus] osm0sis:
What we need is another phone with only "okay" specs that's officially on JB4.2 so we know what Google would set.. Any ideas?
[Samsung Galaxy Nexus] The Gingerbread Man:
Samsung galaxy core http://crave.cnet.co.uk/mobiles/sam...t-another-cut-down-jelly-bean-phone-50011052/ Acer Liquid E2 http://crave.cnet.co.uk/mobiles/acer-liquid-e2-is-a-budget-quad-core-jelly-bean-phone-50011034/ Samsung Galaxy S3 mini http://www.pcadvisor.co.uk/reviews/mobile-phone/3424965/samsung-galaxy-s3-mini-review/

Edit

just reread your post, I don't think those have 4.2, similar specs though. Funny to think last years high end is now this years low / mid range already

Edit 2

The Micromax A116 Canvas HD http://spotonlists.com/technology/top-10-android-4-2-jelly-bean-phones-2013/

Edit 3

Could be worth checking out what the sgs2 roms are like as the phones are fairly similar and similar age
[Samsung Galaxy Nexus] xI mEzMeRiZe Ix:
Just for the record, I set the values to what was recommended on the Google bug report page, and it has really made a difference. Been running for a days and haven't had any of the micro-lag that I had been accustomed to on this phone, regardless of the ROM and kernel.

And it's not placebo. I can objectively tell there is waaaaaaaay less stuttering and lag now.

Just my experience though. Also, running CM with the stock kernel (sorry) FWIW.
[Samsung Galaxy Nexus] DoesntPostAThing:
It had been smoother, but I noticed my downloads were getting ended halfway until I start goo again. Might be goo, but who knows. Same thing with play music.

Anyways, we could look at the international S3 too, as it has 1 GB RAM. Once I get home I'll extract multiple build.props for the skyrocket, both tw 4.1.2 ROMs since it uses the new implementation, and 4.2 AOSP.
[Samsung Galaxy Nexus] xI mEzMeRiZe Ix:
Haven't had any issues downloading anything.
[Samsung Galaxy Nexus] DoesntPostAThing:
Might be just that time, perhaps my WiFi connection, but I haven't been able to reproduce it since. I thought it might be things getting kicked out of RAM due to heap size decreased. Anyways, I'm home now, time to download some Skyrocket ROMs. Hope my internet decides to be nice today.
[Samsung Galaxy Nexus] JBNex:
For me my best configuration is CFQ with DynInteractive governor. Max/min 1228/192 all default settings
[Samsung Galaxy Nexus] DoesntPostAThing:
Ok, perhaps we should stop filling the Franco thread with this heap stuff. Is there already a thread talking about this? Also, hers's a spreadsheet to record your discoveries. https://docs.google.com/spreadsheet/ccc?key=0AiQvn3LeUaz9dC15S2RmcVJjWUtXSl9tVWVnb3VaTWc&usp=sharing

EDIT: Eliminated 128/256/1. It bootlooped my device twice. Also, all TW 4.1.2 ROMs for the Skyrocket use 64/256/0.75. It runs surprisingly well. Now I'm wondering if the GNex should use this too?
[Samsung Galaxy Nexus] kersh:
I have updated my phone to 4.2.2 revolution hd and flashed the latest kerneel, but now if I power off the phone and instantly click again the on button, the phone doesn't response immediately, I need to wait about 7 8 seconds then click again and the phone finally wakes up.

any idea?
[Samsung Galaxy Nexus] Garridon:
Hi, I don't think you like taking requests but I am in love with your kernel, but its missing one thing I actually need, not just want. I need vibrator strength control please, if I don't have it set it makes a loud clicking sound (had me in trouble at school once)

So please if you don't mind, add it in there for me?

Unless someone has an app that can reliably do it...

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] DoesntPostAThing:
After a night of testing on the heap stuff, I came to this conclusion:

1. 64/256/0.75 should be the "correct" one for the GNex. Proof: It's like this on ALL of Samsung's phones with 1GB RAM. I'm talking about stock firmware, the one with TouchWiz. Both 4.1.2 for Skyrocket and 4.1.2/4.2.1 for GS3 international come with this combination. Also the fact that Google marked 96/256/0.75 as a defect meaning it really shouldn't be like this. As for the math part, I'm not too sure.

2. 64/256/0.5 works the best for me. It's the longest I've been without lags, and everything is super smooth. Things don't open as fast as the HTC One, but hey, they never did, and that thing is two years ahead of the GNex. It's already amazing that I can still beat it at smoothness, just not speed.

So yea. While the "correct" one isn't Google's numbers, it isn't the best either. I feel that my numbers are better.
[Samsung Galaxy Nexus] Angelakaro:
I changed my build.prop with your suggested values but i feel swiping through pages or menus in slowmotion (do you remember ICS?). Although that effect, i can't see any lag or visual stutter: everything is buttery smooth. I'm sure of what i'm saying, this is not placebo. I'll try this settings for a while cause it's not annoying for me to have some slower animations

EDIT: if someone think i'm right, just set dalvik.vm.heaptargetutilization to 0.75. It was giving the slowmotion effect if set to 0.5

Inviato dal mio Galaxy Nexus
[Samsung Galaxy Nexus] abalam:
Is there a manual how Compile Franco Kernel?
[Samsung Galaxy Nexus] Raijin:
Franco, can you add an option to use the Roboto font in App? And the "old" style.
[Samsung Galaxy Nexus] zoomy942:
I used that setting and still had lag/studder
[Samsung Galaxy Nexus] Sik-1:
The best setting for my phone that I found messing with the VM was this

96/128/0.5 , that's about 48m which used to b the highest VM back in the old g1 era of things lol but def give it a try and share some knowledge on how it feels guys
[Samsung Galaxy Nexus] osm0sis:
Also a different color blue than before which doesn't match Christian's part of the app. Made me switch to the holo light theme. :(
[Samsung Galaxy Nexus] The Gingerbread Man:
I like the new update the only other thing I'd change is an option to change the action bar to a dark one. Like in supersu if you look through theme options in there.

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] chugger93:
So I was kinda *****ing earlier in this thread about battery life. Not really blaming the kernel, but maybe my settings? Yah, then I found Greenify and did a few other things and BAM my battery life is stellar. Signed outta google talk, turned off GPS, turned off all facebook settings for GPS locator, etc, brightness at fairly low. Greenified about 4 of my apps and found out I'm saving over 30% battery life now. Greenifying Maps/facebook and battlefriends was the best thing for my phone.

I normally had 1 hour on screen time at 40-50% battery life left. Now I'm at 80% battery life and have over 1 hour on screen time.

So this is true in testament that if your battery life sux, more than likely its the bullsh*t apps and bullsh*t services you have running on your phone.

Cheers
[Samsung Galaxy Nexus] georgecarstoiu:
Anyone else experiencing random reboots on latest kernel?

I am using interactive with bfq and had 3 reboots in the last 4 days. Logs were disabled so I cannot provide logcat.
[Samsung Galaxy Nexus] DoesntPostAThing:
I tried 0.75, perhaps a little better. 0.5 was giving me terrible results for RAM in AnTuTu, despite being smoother overall. I'll try 0.75 now and see how it does.
[Samsung Galaxy Nexus] timbck2:
Franco has said many times that he's never going to add vibrator control to his kernel. It's just something he doesn't want to fool around with.

Sent from my grouper or toro
[Samsung Galaxy Nexus] DoesntPostAThing:
One more find: In 4.2 and 4.2.1, dalvik.vm.heapminfree is 512k. In 4.2.2, it's 2m. I had significantly better performance in 4.2.1 and 4.2, so perhaps this is the one we should be looking at instead of dalvik.vm.heapgrowthlimit. I also found that you can't directly compare skyrocket 4.1.2 to GNex 4.2, since there are a few differing fields.

Furthermore, 4.2.1 and 4.2.2 have the exact same fields for dalvik.vm.xxxxxxx. All the values are the exact same, except for minfree. I'm guessing 96/256/0.75 is the correct one and 512k and 2m is the difference we should be looking at.
[Samsung Galaxy Nexus] Garridon:
Ugh back to something slower I guess lol

Cheers.

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] DoesntPostAThing:
Give AK Kernel a try, super fast, and vibrator control.