The CyanogenMod team broke the spell last night as to how is their Jelly Bean ROM going to be called, given that CM9 is Android ICS-based, and when are we going to see the JB efforts.
The crew apparently thinks that Android 4.1 Jelly Bean is a pretty major update to Android 4.0 Ice Cream Sandwich, so it warrants a CyanogenMod 10 designation, not to mention J is the 10th letter of the English alphabet, as their numbering usually goes. The work on the ROM will start as soon as Google releases the source code, and all 37 something devices that were recently greeted with custom CM9 ROMs
will be first in line to get CM10 as well.
As for requirements, as long as you satisfy those for CyanogenMod 9, like 512MB of RAM and the like, you'll be covered. Pretty siginificant news, and we can start the betting process whether the CyanogenMod team will beat the manufacturers with a streamlined Jelly Bean ROM for all major devices before it hits the handsets officially from their makers. Here's the full scoop from the crew:
CyanogenMod Yesterday 11:25 PM (edited) - Public
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.
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.
When it’s ready