The famously large 2100mAh battery within the Galaxy S III has few competitors on the market. Only the Galaxy Note, at 2500mAh, and the Droid RAZR Maxx, at 3300mAh, can claim to contain larger cells inside smartphone-like enclosures. That gets the GS III off to a good start, though you shouldn’t expect it to actually be too far ahead of the competition: its vast 4.8-inch display and superpowered quad-core processor do make full use of the energy available. Under intensive use, the Galaxy S III lasted a solid seven hours before flashing up a low battery alert — that time included capturing 137 GPS-tagged photos and six 1080p video clips at an average length of 40 seconds, running multiple instances of our favorite benchmarks, and the usual poking and prodding that comes with investigating a new device. The following day, I was able to go from 8AM to 11PM before facing a critical battery warning, while again giving the phone regular use and syncing up Gmail, Twitter, and Flipboard.

Predictably, battery drain was at its fastest when the self-illuminating AMOLED display was turned on, with a period of nearly three hours around lunchtime knocking only a few percentage points off my energy reserves. With judicious use, you could probably go a full 24 hours between recharging this phone — not terribly impressive to someone coming from a featurephone, but very reasonable given the size of the display and the amount of power the Galaxy S III offers.

On Jelly Bean

Unless you have been internet deprived lately, you are aware that Android 4.1 aka Jelly Bean (JB) is due out in the coming weeks. Which inevitably leads to the question: How does this affect me CyanogenMod?

Now, to preface this, we do not have our hands on the source code, and things in this post may change dependent on analysis of the code first hand and the impacts. That said, we do have a general understanding of the changes and what we can expect, and this post serves to highlight the key changes.

CyanogenMod Next

Many have asked whether JB will be CM9.1 or CM10. Keeping with the pattern thus far, every newly named AOSP update results in a bump to the CM major version. This has the added benefit of fitting into the pattern of [insert codename position in the english alphabet] = CM version. Examples being: G is the 7th letter thus CM7, I is the 9th letter thus CM9 and J = 10.

I can’t believe its not Butter

The ‘Project Butter’ enhancements to Android are much anticipated and should not be a huge pain to merge. We anticipate some breakage in existing libs but nothing that the reference board devices or some hackery won’t overcome. Essentially, if your device met our criteria for CM9 (512mb RAM, etc) and is already supported, then you should be in line for CM10. There may be some added headaches around hwcomposer, but we’ll cross that bridge when we get source.

Another fresh start?

With CM9 (and ICS) being such a large jump from CM7 (GB) we decided it would be best and most efficient to essentially rewrite CM enhancements from scratch. This added a bit of time to our development cycle, but the initial investment in cleaning our codebase has paid off, and CM9 is better for it. Now that JB is around the corner, we are in a place where most of our code will merge cleanly into JB, with minimal fuss.

What needs rework?

Since we don’t have source, we obviously can’t give a 100% analysis. What we do anticipate refactoring is Trebuchet and the LockScreen enhancements, along with the Theme Engine.

In addition, we expect to have to hand merge (versus a more automated method) the updated Framework code. This isn’t because of massive changes, but from what we’ve heard, the Framework code has been split into multiple projects to better the PDK (Platform Development Kit). Should be doable in a weekend’s amount of time.

CM7, 9, and 10 at the same time?

Our goal is to release a stable CM 9.0.0 (and any needed .1’s). After that, we will work on CM7 and CM10 only. As stated above, CM9 devices are highly likely to get CM10, so maintaining a separate class of devices for CM9 only is inefficient.

ETA?

When it’s ready