Android 5.1 (UPDATE: Was Just Pushed To Nexus 5)

I haven't been too impressed with 5 either (battery/memory leak).

quote:

---

Android 5.1
I haven't been too impressed with 5 either (battery/memory leak).

---

and the horrible gps lost issue

waze and maps are both dead to me until they can get the wifi/3g/gps shite working correctly again.

gps crashes every 45 seconds or so in lollipop making it just about useless on my N5.

Should be merged into roms within a few days.

Tried LiquidSmooth, Rastapop, Elix-R, Terminus, and Chroma. I keep going back to Terminus + Franco.

Speaking of Franco, he posted an explanation of why 5.1 feels smoother to stock users:

quote:

---

In case you're wondering why your Nexus 6 feels so darn fast and smooth on Android 5.1, besides all the improvements on ART and possibly a lot of code cleaning and optimizations on the Framework - the device is now running full quad-core mode all the time which helps tremendously because the Kernel task scheduler can distribute the workload through all these cores so you'll get the perception that the device is not hanging anymore.

They also disabled the built-in thread migration boost routines - if you don't know what this is about it's a driver made by Qualcomm that receives a notifier from the task scheduler when one thread migrated from one cpu core to another, and to minimize perceived lag it boosted the destination core to the same, or greated, frequency than the origin core:

1 - thread moves from cpu0 to cpu2
2 - driver is notified
3 - reads the current cpu0 frequency
4 - if cpu2 current frequency is less than cpu0's read frequency it boosts cpu2 to that freq, or, if the origin freq is lower than the threshold (which is 1.7GHz by default AFAIK) it boosts to that threshold value.
5 - the boosted frequency on cpu2 stays there for at least 20ms

These migrations can occur dozens of times per-second. One of the things that I did on FK was disabling all this to conserve battery (and we don't really need all that boosting with this chip).
I'm sure Google did the math and a lot of power measurements and found out that the gains outgain the losses, so they disabled this, and I applaud them.

So these two changes balance themselves out, and I can imagine that 100% stock users will be pleasantly surprised by the improved battery life.

Unfortunately we're still dealing with full 3 second cpu boost on touch events... we don't need long of a boost, specially at 1.5GHz... Comon Google.

I don't know what other improvements they did on the Kernel, the source is not up yet, this is all I know for now.?

---

When's this shite dropping for nexus 5? My phone sucks since the last update so feeling like an entirely new phone would be nice.

quote:

---

I would suggest anyone with the capability to get 5.1 to do it as you won't be disappointed

---

I just got a Nexus 6, couple of questions?

1. How do I manually get it? I downloaded it from a link, but when I click on the download it says "can't open file", so I'm not sure where to go from there.

2. If I don't do it manually, will it eventually automatically be available for my phone? I assume yes, but the next question would be when would that take place?

quote:

---

I tried LiquidSmooth for a little bit, but it was a little too buggy.

---

Do you have much experience with Liquid? That was my go to ROM while on my OG Droid. Haven't used it since switching to my Droid 4.

I flashed it last night, and like everyone has been saying, the phone flies. I used to have a bit of lag when I pressed the recents button, but not anymore.

I did have some trouble flashing it, though, probably because I was doing it on Linux. I tried doing the "manual" update so I wouldn't lose my data, where you flash each partition individually. Everything worked fine except for the system.img, which kept telling me that the data size exceeds download buffer. I also tried to sideload the OTA file, and it kept crapping out at about 50%. I finally resorted to putting Wug's NRT on my wife's laptop, which gave me the same error initially until I checked the force flash option. That broke the system.img down into "sparse" chunks and it was able to flash it.

Turns out all I had to do was use fastboot's -S option on Linux, but everybody who reported the error I had always got the same answer: just use Wug's toolkit. Seems like the damned command line tool should default to sending large images in smaller chunks if it gets that error.

thx for the review

youre currently the GOAT tech board poster imo