Guest Len Ash Posted May 8, 2011 Report Posted May 8, 2011 (edited) OK, some clarity required regarding what is commonly called "Battery Life". Before getting in to detail, it is worth reminding you that Smartphones are designed with large screens, fast processors and masses of connectivity. Which means they will use more power than an old Nokia flip-phone. This is something you need to get your head around. So, what actually uses power in your Blade? And why should the ROM you use have little effect on battery life? The Processor (aka CPU). In this application, the CPU uses more power when the frequency it is running at increases. The higher the frequency, the faster the CPU processes instructions, in simple terms. In the case of the Qualcomm MSM7227 ARM6 CPU in the Blade, the specified maximum CPU frequency is 600MHz. So, if the CPU is running at 600MHz, it uses the most power. Reducing the operating frequency reduces the power consumption, almost linearly. The CPU in the Blade has a minimum operating speed due to the internal watchdog, but the value is not generally known as the MSM7227 is under NDA. To this end, the known safe minimum speed used is 122.88MHz. So, if we can ensure that when the processor is doing very little, such as just "listening" for SMS or phone calls, it is operating at this (theoretical) minimum speed, we will use the least power. How do we ensure that? The Linux kernel has a number of "scaling governors" coded in that allow the CPU (in any hardware, not just phones) to change operating speed according to the current load, scaling governor type and settings. The Blade ROMs generally default to the "ondemand" governor set to vary the CPU operating frequency from 245MHz to 600MHz, depending on load. The ondemand governor will increase the CPU frequency quickly when the load exceeds 90% (in the Blade ROMs) and reduce it as the load decreases. (I set the minimum CPU frequency to 122MHz for an even lower low-load power consumption). I'm not going in to the behaviour of all the other governors here, nor the settings available, but clearly any ROM or app that prevents the CPU from reducing its operating clock frequency will use more power and the battery will discharge faster. This is partly ROM dependant - particularly if the scaling governor is not set correctly The Display 2 types of display exist on the Blade. TFT (aka LCD) and OLED. Both have their merits and demerits and personal preference will come in to play in terms of appearance, colour rendering and so on. That aside, and back to facts, the Display is a significant power user. In basic terms, irrespective of the technology, the brighter the display, the more power it uses. The power consumption of the TFT display is wholly dependent on the LED backlights, the display itself uses almost nothing. The OLED display is an active display, so it emits light itself without the need for backlights, but still uses more power when brighter. Contrary to popular belief, the TFT display is capable of being brighter, and darker than the OLED, and can also consume less power when fully dimmed. It is also not commonly understood that the OLED display consumes more power when displaying white/light colours then blacks/dark colours. The TFT displayed colour matters not one bit in terms of power consumption. So, the dimmer the display of either type, the lower the battery consumption. OLED displays tend to consume more power than their TFT equivalents, brightness for brightness. This is not ROM dependant as such - only if the ROM uses lousy autobrightness control Poor code Unless the kernel and lib files have been seriously knifed, the code should run without issue. Problems only usually occur when code tends to "poll" devices too frequently rather than rely on interrupts to kick them in to action. This should not occur in mainstream ROMs. This is not (mainstream) ROM dependant. The GPU The Graphics chip consumes power depending on how much work it's doing. 3D work, video and Live Wallpapers take their toll. Heh, just like Windows Aero or Linux Compiz. Turn Hardware acceleration off too. Pointless. This is partly ROM dependant Radios - Telephony The Blade, like most other Smartphones, has a number of Radio functions. Those concerned with telephony include the GSM/GPRS and UMTS (3G/3G+) devices in the phone. So every SMS, Voice Call or Data transfer uses the Telephony Radio devices in the phone. What is worth understanding is that in areas of weak carrier signals, the phone will increase its RF power output in order to eatablish and maintain a link. This really does increase the battery consumption, and goes some way to explain why, as you travel around, the battery consumption appears to vary considerably. It is usually better from a battery life perpective to switch to an alternative signal type if possible, even at the expense of speed. This is not ROM dependant as such. Radios - Bluetooth Bluetooth in the Blade is rather primative. Bluetooth should be turned off when not required as it will increase the drain on the battery by an amount that is not ROM dependant. Radios - WiFi WiFi, like Telephony Radio, will vary its radiated RF power dependent on the signal strength from the AP to which it is connected. WiFi is a significant battery drain when in use, and users are advised to 1) switch Network Notification off and 2) ensure that WiFi is set to switch off with the display. That way, WiFi can be left "On" and will not use any power at all until the phone is running and reconnects. WiFi battery use is not ROM dependant as such. Radios - GPS The GPS receiver in the Blade comsumes power, but is not massive. It is OK to leave it enabled - it is only used when required. This is not ROM dependant. Radios - FM Radio The Blade has an integral FM band radio receiver. This is fine, except it tends to prevent the phone from sleeping, and has a tendency to continue to run when the user believes it is "closed". I have come across several user problems where the FM Radio is the sole cause of battery discharge. This is not ROM dependant. Audio volume/haptic feedback. These have a very minor effect on power use and can be disregarded in the grand scheme. These are not ROM dependant. Drivers/Lib Files/Modules Poorly coded or buggy lib files and/or fudged hardware modules (.ko) can cause incorrect hardware operation and enable devices that should not be enabled, thus consuming your Li-Ion atoms. Shouldn't happen with mainstream ROMs or derivatives. Not ROM dependant as such... So, what we have seen so far is - the ROM you choose is fairly unlikely to have a significant effect on your battery life... unless the ROM is known to have serious bugs (CM7, for instance) ROM dependant The CPU clock frequency has a major effect on battery life, so if the ROM (or your settings if you have CPU governor access) overclocks the CPU or prevents it from reducing to a low frequency, then battery life will suffer. The display needs to be illuminated - no ROM can avoid that, so one ROM to another will not affect battery life in this way. If you use autobrightness, one ROM may have good control and another may not. As anyone who has used my remixes will know, I have modified the autobrightness behaviour every time. The stock behaviour is not good enough on any count. User dependant Turning radios off when not in use will save battery, but that gets away from the point of a phone, or indeed a Smartphone. It is better to limit the amount of syncing or increase the syncing period to retain the Smartphone aspect of the Blade. If you receive dozens of GMails every hour, expect the battery to drop... Summary If you are experiencing what you perceive to be high battery consumption on a new ROM, consider this:Are you using a ROM that is Alpha, Beta, Experimental or in Test or known to misbehave? Expect issues.You must ensure that the ROM install was 101% clean and you wiped the Battery Stats in CWMYou need to use the phone normally and charge/use over a couple of days at least to settle the battery statsYou need to ensure that you have not missed any settings that affect the display brightness or its ability to turn offYou need to ensure that you have not missed any settings that affect the CPU frequency, if accessibleYou need to ensure that you do not use HW acceleration or AHB overclockingYou need to ensure that you have not missed any settings that affect the phone's ability to sleepYou need to ensure that you have not missed any settings that cause WiFi not to turn off with the displayYou need to ensure that you have not added any apps that prevent the phone from sleeping completelyYou understand how and when to use Spare Parts to determine with accuracy what has been using you batteryTry noting the battery level, go to full airplane mode, leave phone for a few hours, check battery. Same? Kernel behaving.Watch the FM Radio app...You should refrain from complaining based on your own subjective view after just a few hours use... please. It helps no-one. You should also avoid ROMs that are in test... unless you are happy to report your findings in a constructive way and have an objective view. I hope that clarifies a few things and gives you something thought-provoking. I can elaborate as required... if anything is unclear. Edited May 8, 2011 by Len Ash
Guest hugobosslives Posted May 8, 2011 Report Posted May 8, 2011 when you say use dark colours for saving battery on a oled screen. I often use 'screen filter' at night to reduce the brightness below the minimum value. more for my eyes than for battery. but are you saying I would better off using a dark colour render on the screen? if so does any colour work the best? I'm guessing red as it has the lowest frequency? cheers. and good guide.
Guest shad0wboss Posted May 8, 2011 Report Posted May 8, 2011 informative indeed. Nice collection of thoughts.
Guest Len Ash Posted May 8, 2011 Report Posted May 8, 2011 (edited) when you say use dark colours for saving battery on a oled screen. I often use 'screen filter' at night to reduce the brightness below the minimum value. more for my eyes than for battery. but are you saying I would better off using a dark colour render on the screen? if so does any colour work the best? I'm guessing red as it has the lowest frequency? cheers. and good guide. Black - the OLED emits light when the OLED elements are switched on (by varying degrees) - so Black, or at least dark, means the elements are off and thus consuming no power. OLED displays tend to use more power than TFTs, brightness for brightness. From an earlier piece of mine: OLED active (lit) pixels require power. Therefore the "lighter" or "brighter" the image, the more power consumed. White requires the most, because you are using 3 OLED pixels (Red/Green/Blue) at once. This is also the reason why the OLED displays whites with varying hues dependant on the brightness, the RGB mix shifts slightly by different amounts as the pixels are dimmed. OLEDs tend to show whites with a pinkish hue as the brightness decreases due to the slight dominance of the red OLED pixel element. TFTs tend to have a slightly bluish tint, which is generally consistent irrespective of the screen brightness. This is probably due to the fact that white LEDs are made from blue LEDs with a yellow phosphor to convert the blue light to white. The blue is still somewhat dominant, particularly with the cheaper "cool white" LEDs used for backlights (they are also more efficient than "neutral" white or "warm" white LEDs). TFT hasn't the same issue in terms of image shade, but the brighter ANY image, dark or light, the more power consumed by the LED backlights. If that makes sense.. I always use a dark wallpaper and auto brightness on my OLED - just auto brightness on the TFT. Some folk just set the brightness to a set level.... Edited May 8, 2011 by Len Ash
Guest ThrashMan Posted May 8, 2011 Report Posted May 8, 2011 Sweet article LanceH. We can only hope users will be better informed and think before posting about the expectations and disappointments of battery life :unsure:
Guest Nick Rhodes Posted May 8, 2011 Report Posted May 8, 2011 If you trust Wikipedia :) ... OLED is twice as efficient with black, but 3 times worse with white compared to LCD. From http://en.wikipedia.org/wiki/Organic_light-emitting_diode Power consumption: While an OLED will consume around 40% of the power of an LCD displaying an image which is primarily black, for the majority of images it will consume 60–80% of the power of an LCD – however it can use over three times as much power to display an image with a white background such as a document or website. This can lead to reduced real-world battery life in mobile devices. Cheers, Nick :unsure:
Guest mELIANTE Posted May 8, 2011 Report Posted May 8, 2011 Same phone, same usage, different roms, different battery life->rom dependant :unsure:
Guest Len Ash Posted May 8, 2011 Report Posted May 8, 2011 (edited) If you trust Wikipedia :) ... OLED is twice as efficient with black, but 3 times worse with white compared to LCD. From http://en.wikipedia.org/wiki/Organic_light-emitting_diode Cheers, Nick :unsure: Couldn't have put it better myself! Having both, I have grown to prefer the TFT display. Apart from the better battery life, the dynamic range of the panel is greater (goes a lot darker and a little brighter) and text is more legible. I did a side-by-side test yesterday with both types; 100% charge, same ROM, same location, same sunlight outside, same carrier, same WiFi connection, same browser, same urls. After 20 mins, the OLED was down to 84%, the TFT 90%. Not scientific by any standards, but entirely expected. Anyone want to buy a lightly used OLED OSF??? Edited May 8, 2011 by Len Ash
Guest JT_daniel Posted May 9, 2011 Report Posted May 9, 2011 +1 to that. Great post, LanceH. Should help dispel the many battery myths out there. I vote it should be turned into a sticky. And guys, does Beautiful Widgets cause a lot of CPU usage in your Blades? I had syncing set to 2 hours, but it consumes an unnatural amount of CPU (as shown in Spare parts) and hence Battery. I had to ditch the widget and immediately, battery levels stopped dropping like a stone. Any other Beautiful Widgets users out there?
Guest Totyasrác Posted May 9, 2011 Report Posted May 9, 2011 Excellent job on the first post, LanceH! Same phone, same usage, different roms, different battery life->rom dependant :unsure: I have to agree on this. Saturday I used N62 (for the second or third day), in 12 hours (in my pocket, so other than mail sync I didn't really use it except for 2 short calls) I've lost 90% of the battery which is ridiculous. Now I switched to FLBr11 (for Gen2) and yesterday - pretty similar usage - I lost only 24% in 14 hours with two reboots for other reasons (and we know that reboot consumes a lot of electrons :)). Exactly same widgets and mail settings; charged overnight in both cases. I never install the radio app, neither Maps, I switch GPS off immediately after (clean!) install... 3G and data is always on, never using wifi. So I'd say it is pretty ROM dependant and on my (originally) Gen1 OLED SanFran is the best with Froyo - so far the only GB ROM is CM that I've tried (many variants) and intensive battery leakage is always on with that; while never with any Froyo ROMs.
Guest Totyasrác Posted May 9, 2011 Report Posted May 9, 2011 And guys, does Beautiful Widgets cause a lot of CPU usage in your Blades? I had syncing set to 2 hours, but it consumes an unnatural amount of CPU (as shown in Spare parts) and hence Battery. I had to ditch the widget and immediately, battery levels stopped dropping like a stone. Any other Beautiful Widgets users out there? One here - nothing suspicious for me (see previous post), I keep on using FW (Pro v1.0.8) with all ROMs and see the difference - it shouldn't be this widget... Or might be that with 2.3 it is not working properly?
Guest Grain Posted May 9, 2011 Report Posted May 9, 2011 So I'd say it is pretty ROM dependant and on my (originally) Gen1 OLED SanFran is the best with Froyo - so far the only GB ROM is CM that I've tried (many variants) and intensive battery leakage is always on with that This is why Lance wrote "Are you using a ROM that is Alpha, Beta, Experimental or in Test or known to misbehave? Expect issues.". CM for the Blade is beta (in practice) at the moment, and there are some known battery drain issues. This has nothing to do with Froyo vs. Gingerbread in general but it's just coding bugs in CM and/or coding bugs in the Blade-specific support libraries in CM. For example, the (probable) battery drain part of issue 3608 is some side-effect of an earlier 'fix' that tried to fix audio problems in SIP calls. Also, you have to keep in mind that when comparing JJ/SS/FLB to CM you compare some software that has been targeted at the Blade and extensively tested on manufacturer side for several months with another firmware that has been in pretty much chaotic testing for a bit more than two months only.
Guest Totyasrác Posted May 9, 2011 Report Posted May 9, 2011 This is why Lance wrote "Are you using a ROM that is Alpha, Beta, Experimental or in Test or known to misbehave? Expect issues.". CM for the Blade is beta (in practice) at the moment, and there are some known battery drain issues. This has nothing to do with Froyo vs. Gingerbread in general but it's just coding bugs in CM and/or coding bugs in the Blade-specific support libraries in CM. For example, the (probable) battery drain part of issue 3608 is some side-effect of an earlier 'fix' that tried to fix audio problems in SIP calls. Also, you have to keep in mind that when comparing JJ/SS/FLB to CM you compare some software that has been targeted at the Blade and extensively tested on manufacturer side for several months with another firmware that has been in pretty much chaotic testing for a bit more than two months only. I am aware of all of it :unsure: I have already posted some notes onto the BugTracker, and testing most of the releases - but since there are "stable" ones of CM I'd expect them to be working at their best... My main concern was battery drainage and it's still present this is why I'm back on FLB. And I've just posted my previous one to make a note on wheter battery issues are HW or SW related :)
Guest Len Ash Posted May 9, 2011 Report Posted May 9, 2011 One here - nothing suspicious for me (see previous post), I keep on using FW (Pro v1.0.8) with all ROMs and see the difference - it shouldn't be this widget... Or might be that with 2.3 it is not working properly? CM7 is experimental, as stated in my post should not be considered.
Guest mELIANTE Posted May 9, 2011 Report Posted May 9, 2011 CM7 is experimental, as stated in my post should not be considered. Is it not a ROM? Does it drain battery? Yes it does. Then, it proves that battery drain can be rom dependent, if it isn't a good rom in that department. I don't get this topic...
Guest Len Ash Posted May 9, 2011 Report Posted May 9, 2011 Is it not a ROM? Does it drain battery? Yes it does. Then, it proves that battery drain can be rom dependent, if it isn't a good rom in that department. I don't get this topic... That's OK.
Guest Spies Posted May 9, 2011 Report Posted May 9, 2011 How does HWAccel increase battery usage? Isn't hardware acceleration supposed to be more efficient than code run on the CPU?
Guest surfatwork Posted May 9, 2011 Report Posted May 9, 2011 (edited) Is it not a ROM? Does it drain battery? Yes it does. Then, it proves that battery drain can be rom dependent, if it isn't a good rom in that department. I don't get this topic... Would you agree that battery life can only be measured with production code? and not with code that is under development? If yes, then CM7 is development code and is inherently buggy, and you cant measure battery life with it. The point of this topic is that, WHEN you are using a production ROM, then the vast majority of battery life influencers are independent of the ROM. What is so difficult to understand? If you dont agree with the first point, then there really is no point.... great article, btw, LanceH. thks. Edited May 9, 2011 by surfatwork
Guest mELIANTE Posted May 9, 2011 Report Posted May 9, 2011 Would you agree that battery life can only be measured with production code? and not with code that is under development? If yes, then CM7 is development code and is inherently buggy, and you cant measure battery life with it. The point of this topic is that, WHEN you are using a production ROM, then the vast majority of battery life influencers are independent of the ROM. What is so difficult to understand? If you dont agree with the first point, then there really is no point.... great article, btw, LanceH. thks. I would agree that different hardware influences the battery life. But this topic seems to discard the very real possibility that different roms have different battery lives. That's wrong, different roms do have different battery lives. The first post is a good article on how different hardware can induce different battery behaviour but to jump to the conclusion that it is indeed the culprit for the battery drains people observe is a fallacy.
Guest dibbles Posted May 9, 2011 Report Posted May 9, 2011 For me there was a very clear relationship with the SS RLS 4 or 5 (and LanceH's remixes) and my B08 San Fran and excessive battery drainage due to the Dialler when looking under partial wakes. The above entirely cleared up when I changed (first using the Windows flash method and then after getting back to GEN 1 the TPT method) to GEN 2 and then used those ROMS. I am successfully using LanceH's "phat" RLS 5 remix and have had over six days of use, light use of phone and texts, with as little as 38mins shown for the dialler under partial wakes, previously it was measured in hours and would not have got anywhere near six days usage. However my wife's B10 San Fran is still GEN 1 and uses the same ROM and has never had the partial wake issue of the Dialler as I did. I could never understand why my B08 was using hours of the Dialler and yet my wife's was using only a few minutes over the same time period. It was an unexpected, and only, bonus for me going to GEN 2 and for that reason alone I have kept the phone there. The thread where others noticed an improvement when experiencing the same problem... http://android.modaco.com/content/zte-blad...-battery-issue/
Guest surfatwork Posted May 9, 2011 Report Posted May 9, 2011 I would agree that different hardware influences the battery life. But this topic seems to discard the very real possibility that different roms have different battery lives. That's wrong, different roms do have different battery lives. The first post is a good article on how different hardware can induce different battery behaviour but to jump to the conclusion that it is indeed the culprit for the battery drains people observe is a fallacy. errr.....afaik, software cant drain battery i.e. a piece of code on it's own cant consume energy. Only hardware can drain battery - the software needs to make some bit of hardware do something to consume energy and drain the battery. Unless you think that the first post has omitted some significant hardware component, I think the precise point that LanceH is making is that a ROM on it's own cant be responsible for battery drain, unless it has a serious bug - in which case it should never have become a production ROM. anyway, to each his own.
Guest mELIANTE Posted May 9, 2011 Report Posted May 9, 2011 Ok, yes, battery drains are only dependant on hardware. I'm out.
Guest Scoopading Posted May 9, 2011 Report Posted May 9, 2011 Having both, I have grown to prefer the TFT display. Apart from the better battery life, the dynamic range of the panel is greater (goes a lot darker and a little brighter) and text is more legible.Err, goes a lot darker? The whole point of OLED is it doesn't require a back light, and so blacks are almost totally black. TFT, on the other hand, always has the light on even when it shows blacks, so blacks can never go very dark. OLED blows away any IPS/TN/VA based variant in this regard, so I'm not sure what you're seeing. I've directly compared it to screens like the Iphone 4 (which is an IPS based panel with an additional polariser filter fitted to reduce IPS glow - which IPS suffers on blacks viewed at an angle). Pixel resolution aside, in normal lighting conditions I much prefer the Blade's screen. I did a side-by-side test yesterday with both types; 100% charge, same ROM, same location, same sunlight outside, same carrier, same WiFi connection, same browser, same urls. After 20 mins, the OLED was down to 84%, the TFT 90%. Not scientific by any standards, but entirely expectedIt'd be wise to have both phones working from an equal footing before you go introducing your expectation bias into things :unsure: There is no such thing as a 100% charge on Android. That'd probably be the first thing I'd mention about battery life. There's what Android thinks is 100%, and there is the reality, which can often be significantly less than 100%. For evidence of this charge the phone to 100% over USB with it switched on. Now switch it off with the cable still connected. The indicator light will always turn red, and it may actually charge for a significant period of time before turning green. So, did the phone just lose a bunch of battery power from shutting down, or is what Android thinks is 100% less than what the phone's hardware thinks? From my real world usage the best charge appears to be obtained with the phone switched off. This might be, at least partly, because Android is coded in a way which attempts to preserve the usable life span of the battery. This means, once it reaches 100% with the charger connected, it may continue to show 100% battery for quite a while after the REAL charge has fallen several percentage points, in order to prevent unnecessary over-charging. So you can have two phones, both showing 100%, but one actually has (at least) several percent more charge in it than the other one. Another easily observable thing is to charge one phone (with it switched off) until the indicator light turns green, and charge one with it switched on, until Android says it's reached 100%. Now boot the fully charged, but switched off, phone. It will usually always show 98% by the time it reaches the Android launcher. So Android reckons booting the phone ate 2% of the battery. If you trust what it says the phone it charged (at 100%) will last longer than the phone you charged using the indicator light to indicate 100% then booting into Android (98%). This is not my experience. So you can have a phone, where Android's showing 98% battery, and it'll last longer than the other which is showing 100% battery. Simple tests like these (which everyone can easily reproduce) tell you not to trust everything Android tells you about the battery. All the testing I did, when CM7 had its initial battery issues, showed me that Android's battery measurements aren't much use for gauging battery usage over shorter periods of usage either (IE what the battery says now compared to 20 mins earlier). Android really doesn't like dropping the battery in nice tidy 1% increments. Leave a phone in standby for a while, check it, and then check it 5 mins later. It may drop by as much as 5% (though more typically 2 or 3%) when you check it 5 minutes later. Does that mean the battery actually dropped 5% in 5 minutes? Nope. It just means Androids measurements aren't entirely reliable. You can only really trust the measurements over several hours or a lot of usage, rather than measuring short bursts. So, if you've picked the phone up after leaving it idle for a while, I wouldn't trust the first 10% drop too much. If you're trying to compare two phones it also means that the margin difference should probably be greater than 10% before you can be really confident there's a real difference. If you want a proper comparison drain the battery on the two phones then charge them without booting Android. When the indicator light turns green on the first phone pull the battery. Wait for the second to reach green. When it does plug the other phones battery back in. Now, in theory, both are working from a fairly equal charge. Some people have said that battery drops a lot faster between 100-50% than 50-0%. Whilst the drop does seem to slow down in the last 20%, the usage is a pretty consistent linear straight line right down to the lower percentages. So, as long as you ignore the first initial drop (whether the phone is starting at 100% or has been on standby for a while) you can start to get a better idea of what's going on.
Guest Scoopading Posted May 9, 2011 Report Posted May 9, 2011 Saturday I used N62 (for the second or third day), in 12 hours (in my pocket, so other than mail sync I didn't really use it except for 2 short calls) I've lost 90% of the battery which is ridiculous. Now I switched to FLBr11 (for Gen2) and yesterday - pretty similar usage - I lost only 24% in 14 hours with two reboots for other reasons (and we know that reboot consumes a lot of electrons :unsure:). So I'd say it is pretty ROM dependant and on my (originally) Gen1 OLED SanFran is the best with Froyo - so far the only GB ROM is CM that I've tried (many variants) and intensive battery leakage is always on with that; while never with any Froyo ROMs. The battery life is excellent on some of the Gen 1 Cyanogen 7 nightlies for the Blade. I'm still using Nightly 25 with no major issues, and have been for about 2 months now. I set the minimum clock down to 122Mhz. I recommend you try some of the older Nightlies if this has been your experience. Stable for daily usage, at least on this OLED Blade, and performance well above Froyo in my experience (in terms of things like browser speed etc). It now seems unlikely there will be significant progress (with CM7 or otherwise) until and unless ZTE release a 2.3 Gingerbread based Blade variant. Of course, in the meantime, I hope I'm proven wrong by someone with the time and talent to make 2.3 work perfectly without the help of ZTE. But, if you like most things working with no strange behaviours, my advice would be to either find an earlier CM7 nightly which works for you, and live with its (very few in my own experience) drawbacks, or stick to your prefered Froyo rom. But there are CM7 Gen 1 nightlies with battery usage as good as (I'd actually say better than) the better Froyo roms.
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now