Database Users

New Cyanogen ROM, differences for Hero CDMA?

I'm new to Android but not new to Linux and wondering what is necessary to get these ROMs (and others) working on the CDMA Hero. What are the major differences, proprietary drivers? Kernel modules?
New Cyanogen ROM, just released
http://forum.xda-developers.com/showthread.php?t=567610
In other words, what's stopping us from running these ROM's right along with G1/Dream users?

I'm curious also... would love to try his roms...

Since Android 1.6 was supposed to add CDMA support I would think they should work as well as 2.0 unless the developers have taken the cdma support out of the code in their roms to shrink the size to fit on the G1's.
If I had a Hero I would be giving it a try most likely. I might try picking one up this week since Best Buy has them down to $99. I just wish it had a keyboard.

I'll try when I get home from work.
On a side note, even if this rom doesn't work, I should be able to boot into the recovery rom no matter what... riiiiiiight?

herzzreh said:
I'll try when I get home from work.
On a side note, even if this rom doesn't work, I should be able to boot into the recovery rom no matter what... riiiiiiight?
Click to expand...
Click to collapse
Correct! The recovery image isn't touched by normal ROMS typically.

I'm tempted. Can this be applied right over the MoDaCo ROM?

I have tried a couple things with these. I tried flashing it outright. Wouldnt get past the initial htc boot screen. So I replaced the kernel in the boot.img of Cyans rom with ours, that still didnt work. Then I tried replacing the entire boot.img and still no boot working. I think Donut uses the 2.6.29 kernel or whatever it is. Ours is .27 so I think we would need to recompile the .29 kernel and pray our drivers work with it. Please, someone else try it too and see if they can get it working. I would love you forever if you could. If not, we will just have to wait until HTC gets us Eclair.

Thanks
Thanks for trying this, chuckhriczko and others.
I'm mainly coming at this from the pure Linux point of view: shouldn't these ROM's run anywhere (barring proprietary bits)? Shouldn't we be able to "share and share alike" between platforms, Hero/Dream/G1/whatever? If there is a chip architecture difference, fine then we need a recompiled kernel. Obviously there is also the question of firmware, but that's a given on all phones.
Otherwise, shouldn't these ROM's be fairly universal? Or if they are not, I'd like to know what makes ROM building such a unique endeavor for each phone.

5tr4t4 said:
Thanks for trying this, chuckhriczko and others.
I'm mainly coming at this from the pure Linux point of view: shouldn't these ROM's run anywhere (barring proprietary bits)? Shouldn't we be able to "share and share alike" between platforms, Hero/Dream/G1/whatever? If there is a chip architecture difference, fine then we need a recompiled kernel. Obviously there is also the question of firmware, but that's a given on all phones.
Otherwise, shouldn't these ROM's be fairly universal? Or if they are not, I'd like to know what makes ROM building such a unique endeavor for each phone.
Click to expand...
Click to collapse
I believe it's mostly the proprietary drivers for some of the hardware as well as needing a kernel recompile...once HTC releases the CDMA kernel, I'm sure we'll see a lot more (that or some genius will reverse engineer it...either way!)
The other thing to consider is that most of these ROMs are based on something...they take what's existing and tweak the heck out of it (I'm willing to bet that the vast majority of ROMs can trace their roots back to an official vendor image at some point).
I'm actually trying to setup a build environment and poke around but I'm starting from ground zero on the mobile platform side of things so I wouldn't hold out for me (and finding a Java 1.5 runtime is surprisingly hard these days ).
I'm noticing that we're seeing more and more ROM's pop up (primarily gutted ROMs focussed on eeking more speed as opposed to MoDaCo who went for more features).

thecodemonk said:
I believe it's mostly the proprietary drivers for some of the hardware as well as needing a kernel recompile...once HTC releases the CDMA kernel, I'm sure we'll see a lot more (that or some genius will reverse engineer it...either way!)
The other thing to consider is that most of these ROMs are based on something...they take what's existing and tweak the heck out of it (I'm willing to bet that the vast majority of ROMs can trace their roots back to an official vendor image at some point).
I'm actually trying to setup a build environment and poke around but I'm starting from ground zero on the mobile platform side of things so I wouldn't hold out for me (and finding a Java 1.5 runtime is surprisingly hard these days ).
I'm noticing that we're seeing more and more ROM's pop up (primarily gutted ROMs focussed on eeking more speed as opposed to MoDaCo who went for more features).
Click to expand...
Click to collapse
What OS are you using? If your using a Debian based linux then you can get it from the Debian Lenny repositories. One word about this though, it killed my existing Java 1.6 so I had to reinstall it when I needed it. Otherwise that works.
And yeah, we are primarily doing gutted roms because that is all we know up to this point. It is very difficult to find help from those who know all about recompiling a kernel and things like that. Like I said, I couldnt get Cyanogen to even boot on my phone but obviously, it should at the very least do that. But only one dev on these forums ever helped me with my CDMA roms and that was Mlign from the Dream forums. Everyone else (understandably busy) ignored me. Im not saying anything bad about them but it's just harder for people to learn. Patience will give us what we desire though.

vendor tree for cyanogen heroc
im a noob and dont know how to build it but its here:
http://github.com/darchstar/vendor_cyanogen_heroc

Thread gravedigging much?

yes haha i want cyanogen on my hero lol

[Q] explanation in layman terms of why we can't

1- why can't I run stock Google android on my phone ala Nexus one- and update as a nexus one would . A link as i am not afraid to read.
2- what happened to the guy who's video I saw that was close to running stock android on his vibrant.

chkn said:
1- why can't I run stock Google android on my phone ala Nexus one- and update as a nexus one would . A link as i am not afraid to read.
2- what happened to the guy who's video I saw that was close to running stock android on his vibrant.
Click to expand...
Click to collapse
You need drivers.
The CM6 project is dedicated to getting relatively stock Android running on the Vibrant.

chkn said:
1- why can't I run stock Google android on my phone ala Nexus one- and update as a nexus one would . A link as i am not afraid to read.
2- what happened to the guy who's video I saw that was close to running stock android on his vibrant.
Click to expand...
Click to collapse
1). As reuthermonkey stated, it's down to hardware drivers. Even though AndroidOS itself is open with source code available, this is not always the case with the drivers the OS needs to access functions on a given phone. Most of the drivers for any device (phone or otherwise) are proprietary. Samsung, HTC, Motorola, Huawei, LG, Sony...these companies have to PAY for drivers from chipset/soc manufacturers to integrate them into their devices and as such the code for those drivers isn't necessarily freely available. To gain access to these proprietary drivers is a tedious process of reverse engineering.
2). The process of getting most phones "close to running stock android" is a careful process of ripping apart a given phone's OS and cobbling together 3rd party or AOSP project tools/apps to approach being a "vanilla android" feeling experience. Many of these "custom roms" are great, but it can equally be said that most of them are personal projects made by people who love to tweak things to their liking, and not necessarily made to be great for everyone. And most of these stay in a perpetual state of beta-ness. Cyanogenmod CM6 is really the only well developed project dedicated to truly bringing the vanilla android experience to phones at the moment, and then only to phones that CM devs actually have in hand as it's an entirely volunteer project. Be grateful our phone is soon to be blessed with CM6.1.

chkn said:
1- why can't I run stock Google android on my phone ala Nexus one- and update as a nexus one would . A link as i am not afraid to read.
2- what happened to the guy who's video I saw that was close to running stock android on his vibrant.
Click to expand...
Click to collapse
Basically what would need to happen is someone take the source from Google. With that source you need to find a way to basically make all of your drivers (Samsung's Galaxy S Vibrant drivers) work with the android platform. It's not an easy process of adapting drivers to something else, it sounds like oh yeah include the drivers and you'll be good right? Unfortunately it's not as easy as just plug and play.
On the second note, i'm pretty sure what your thinking of is Eugene's Vanilla Rom he's been putting together.
http://forum.xda-developers.com/showthread.php?t=757000&highlight=Vanilla
It looks like he's got some good progress and there is a download going for it. I don't think it's something he's focusing on either. I think the main reason why is with Froyo coming sooner or later there's really no reason to invest time in a 2.1 vanilla rom with as much work that goes into building it from source.
Hope this answers your questions. BTW, as a reference, there is a Q&A forum which would be a better place to put this Question.

Eugene's AOSP 2.1 Port is dead. And rightly so, no need wasting time getting 2.1 AOSP running on the device.
On a side note however, another developer has jumped in to help CM 6.1 reach Vibrant. And it might take a long long time before G2 has any kind of custom rom support.

Why it is so difficult?

I do not want to upset anybody, just trying to get some understanding of the entire upgrade to a new OS version.
I'm a programmer myself, but on Windows platform and mostly do middle tier business server side apps. Do not know a thing about Linux and android. But had some java experience in the past.
I wonder why we cannot get Froyo so long? Ain't the sources open? Even if we do not have some drivers, these parts cannot change dramatically from version to version. Published API must be stable...
Is this about Dalvik JVM? But, I guess this must be in released ROMs for other phones in the line.
What's the deal? Will appreciate some explanation here.

Android is open source, but that is only the operating system and the kernel, but the drivers and RIL that make the device actually functional are the issue as far as I'm aware. From what I've read here and in IRC, Samsung gave us a hack-job RIL, which is causing many of the issues with getting an AOSP ROM fully compiled and working. I think there may be some driver issues as well to be worked out yet, but I feel those are less important than getting things like phone/data/messaging working. I'm guessing there are more technical reasons why they can't just get 2.1 or 2.2 built from source, but those are probably the big issues.

Honestly, it boils down to Samsung.
Put simply, they're crappy coders (as HTC once was many moons ago), or they're just hella lazy (I strongly believe its the former, given RFS and this RIL mess). Most companies are pretty crappy coders, but most of the time, it doesn't interfere with major things, like OS upgrades.
That, plus the lack of effort or support on Samsung's part, has me never wanting to buy another Samsung phone again, or ever recommending an Android phone from Samsung....
I'm gonna do my best to find in my next phone another quick processor with a nice super AMOLED screen and be done with Samsung, I've had enough, and I'm a very patient person....

What is RIL? Is this Radio Interface Library?
Is it linked into kernel or other module? Not extractable at all?
As I imagine it to myself, if it is some sort of dll or package, it shouldn't matter if we do not have source, because it's interface have to be already strictly defined. It doesn't matter if it is buggy. It should work with any android version.
Please correct me if I'm wrong.
P.S. I have Dell Axim v50x and people already created ROM from scratch! However it doesn't have RIL. ;-)

CNemo7539 said:
What is RIL? Is this Radio Interface Library?
Is it linked into kernel or other module? Not extractable at all?
As I imagine it to myself, if it is some sort of dll or package, it shouldn't matter if we do not have source, because it's interface have to be already strictly defined. It doesn't matter if it is buggy. It should work with any android version.
Please correct me if I'm wrong.
P.S. I have Dell Axim v50x and people already created ROM from scratch! However it doesn't have RIL. ;-)
Click to expand...
Click to collapse
if it could have been done, birdman would have done it already

Well I think it's a valid question. Some might think it tedious or obnoxious, but absolutely valid. This is a development forum after all. The reason we don't have 2.2 isn't a hardware limitation, so it must be a practical one -- or yes it would be here.
But I'll just speak from speculation in the hopes that someone will correct me. For god sakes this is a development forum! We've got releases, we have fixes, we have patches, we have complaints, we have gossip. I'd love to see all the _development_ discussion I can get.
From a wider puzzle-piece perspective, I would like to know what is missing. We have working drivers. We have working hardware. We have full source from Google for the operating system. There are several other android phones on Verizon, a few even have Froyo. Sprint currently offers a CDMA Galaxy S phone (Epic) with android 2.2, and that phone possibly shares some hardware (though the WIMAX radio is totally irrelevant to us).
I'm not up to speed on exactly what the RIL is, or how it gets plugged into the android kernel. The RIL (Radio Interface Layer) is a software layer between android itself and the drivers controlling the phone hardware. Google provides some samples for a carrier to create one to govern communication on their network. I'd expect one issue of randomly hacking something like this, is if you are taking over your radio hardware's communications, then you have the capability of putting unwanted data on the network, which might even be criminal. Am I being extreme? So, perhaps we can't touch the RIL and need to wait for it to be spoonfed to us by those that bought the radio band from the FCC. Perhaps this code is inexorably married to particular hardware, unavailable for reading, or even encrypted. Maybe the primary limitation is the royal pain in the apricots that it is to inspect, decompile, and reverse engineer binary code.
But what if we could do something?
My understanding is the RIL is only a carrier-specific interface to the underlying hardware. Shouldn't it be similar between phones, even with wildly different hardware? Shouldn't its interface also be similar between close versions of android? The Droid 2 is a verizon phone with a RIL that does indeed work with Froyo. What I'd like to know is A) can another phone's RIL be extracted within the same carrier, and B) Being the abstract entity that it is, what prevents it from being married to the Fascinate's hardware base?
To be honest, I ardently believe a frank discussion (sans opinions, complains, problems, just productive discussion w/ a smattering of facts) BELONGS in the Development forum.
I'll stop here, in case this thread dies, as so many of mine do.

Jt1134, adrynalyne, and fallingup(angel12) are all very capable as well. This is solely the fault of none other Samsung.
Edit: to answer your question, i think that.the answer about RIL is no, although i dont have a good qualified answer about why the RIL from D2 cant be ported im sure that if it could have, it would have. Sorry thats not a better answer.
Sent from my ADR6300 using XDA App

I don't know anything about how the RIL works, but I would assume that it could only be easily ported from one device to another if they were using the same chipset in the underlying hardware for the phone. I doubt you'd be able to take the Droid 2/X RIL, and take it to the Droid 2 Global or Droid Pro. Given that, I'm guessing that you can't really take a RIL from one phone and put it on another without extensive work, since most OEMs tend to use different hardware in their devices. From what I've heard, there is a semi-working AOSP build floating around, so the devs are trying, but Samsung's crappy source to work from is not making things easy for them.

There are actually some semi-working builds of aosp floating arpunfld but the last time I checked one out it was missing one thing that I consider to be kind of a biggie. It couldn't quite make calls. I'm sure they have it to make calls now but there is a reason its not out to the forums yet. I agree withstand nuts up there. Thanks you Samsung.
Sent from my ADR6300 using XDA App

ksizzle9 said:
There are actually some semi-working builds of aosp floating arpunfld but the last time I checked one out it was missing one thing that I consider to be kind of a biggie. It couldn't quite make calls. I'm sure they have it to make calls now but there is a reason its not out to the forums yet. I agree withstand nuts up there. Thanks you Samsung.
Sent from my ADR6300 using XDA App
Click to expand...
Click to collapse
i believe there was still no radio at all in aosp, and the hope is that 2.2 can fill in the gaps

Wow, wow, wow!
Why do we need another phone RIL? Current one from SF at hand should do perfectly. Did Google changed something in android API related to a RIL? I don't know for sure, but never heard or read anything making me think they did it. Android should call RIL and that is set in stone. ALL calls signatures must to be known. Something new may be added, but it is not show stopper.
So, I still do not understand - is it not extractable or what?
Even if not and it is somewhere in protected memory, encoded or whatever, Froyo slapped on top must work, IMHO. And sources available. So, why we stuck waiting for Samsung?
I know, one may say - do it yourself if you are so smart... Once again, I just want to understand root of the problem. I probably can do something, because I have degree and experience. But, it will take me forever. From what I've tried and seen learning curve is very steep.
On the other hand, skilled developer might simply need fresh look at the problem... May be guys just hitting wrong wall?

CNemo7539 said:
Wow, wow, wow!
Why do we need another phone RIL? Current one from SF at hand should do perfectly. Did Google changed something in android API related to a RIL? I don't know for sure, but never heard or read anything making me think they did it. Android should call RIL and that is set in stone. ALL calls signatures must to be known. Something new may be added, but it is not show stopper.
So, I still do not understand - is it not extractable or what?
Even if not and it is somewhere in protected memory, encoded or whatever, Froyo slapped on top must work, IMHO. And sources available. So, why we stuck waiting for Samsung?
I know, one may say - do it yourself if you are so smart... Once again, I just want to understand root of the problem. I probably can do something, because I have degree and experience. But, it will take me forever. From what I've tried and seen learning curve is very steep.
On the other hand, skilled developer might simply need fresh look at the problem... May be guys just hitting wrong wall?
Click to expand...
Click to collapse
is it possible? perhaps...but the 5 or so guys who really develop for this phone havent been able to get it to work....nor is aosp working 100% on any galaxy s phone

Response from developers?
Anyone?

Yes, you know so much, we are waiting for you to fix it.
Hurry the hell up.

adrynalyne said:
Yes, you know so much, we are waiting for you to fix it.
Hurry the hell up.
Click to expand...
Click to collapse
Agree get your ass moving so we can have teh honeycombzzzz. Quit being such a lazy stingy jerk and get us our AOSP!

ksizzle9 said:
Jt1134, adrynalyne, and fallingup(angel12) are all very capable as well. This is solely the fault of none other Samsung.
Edit: to answer your question, i think that.the answer about RIL is no, although i dont have a good qualified answer about why the RIL from D2 cant be ported im sure that if it could have, it would have. Sorry thats not a better answer.
Sent from my ADR6300 using XDA App
Click to expand...
Click to collapse
yes i was just pulling one dev name out for the heck of it
but i subscribe to the "if it could have been done, it would have been done"

adrynalyne said:
Yes, you know so much, we are waiting for you to fix it.
Hurry the hell up.
Click to expand...
Click to collapse
I don't care what you did for community! But you behave like f****g jerk.
No real explanation for the rest of us? Stay on irc, we will survive without your comments here.

CNemo7539 said:
I don't care what you did for community! But you behave like f****g jerk.
No real explanation for the rest of us? Stay on irc, we will survive without your comments here.
Click to expand...
Click to collapse
that may be a problem for those who just stay here as virtually everything is irc only these days...or the majority of it anyway

CNemo7539 said:
I don't care what you did for community! But you behave like f****g jerk.
No real explanation for the rest of us? Stay on irc, we will survive without your comments here.
Click to expand...
Click to collapse
How many different ways do people need to say that "it's being worked on"? The devs are doing a lot of work on our device, but also working with other stuff, all in their free time. Follow the stuff they do on Twitter and github, or join in on IRC.
Attitudes such as your's are precisely why the devs have stopped posting stuff here. You act as though it's a simple process to do things, when it isn't, especially when Samsung gives you a crappy base to start from. The devs have to first get Samsung's source fixed and cleaned up, then start on whatever it is they want to work on, all while finding more bugs and issues that need fixed, primarily all stemming from the crappy source. If you want to be angry at someone, make it Samsung, not the few devs that are working on our device.
Sent from my StupidFast Voodoo Fascinate

As I said - I will survive. I'm OK even with not rooted stock.
Was it so difficult to answer what the real problem is? I don't know what is the problem with this generation? Do I need to be on FB, irc or whatever to get the answer? Why do not answer in place? Ain't it this forum purpose?
No, seems like I need to kiss somebody ass to get meaningful response these days... That way he can maintain his "super god" status.
I do believe I've been pretty polite stating my question, even though English is not my native language. What generated so much sarcasm?

Redevelopment of apps now that gingerbread is on the horizon

Hey,
I am NOT a dev, but I would like to know what kind of work work is going to be required now that gingerbread is on the forefront?
For example, VPlayer, doesn't work... it FC... How much work is it going to take to get the program back up and running???
Im just asking because, as much as I hate to admit it, fragmentation (as everyone calls it) is going to start causing issues. I get that google wants to offer the best and the latest and greatest, but if everytime a new API get sent out, and devs' have to rewrite their work, how much time is it going to take to get the proggy back up and running??
Thanks!
Theo

theomajigga said:
I am NOT a dev,
Click to expand...
Click to collapse
You should've stop right there.
You realize that at this point only 1(!) phone is running official 2.3 Gingerbread and it's Samsung Nexus S. It's a drop in a bucket comparing to all of the phones that are running official 2.x firmware.
Furthermore, if an app is properly developed against 1.x or 2.x SDK then it will work with gingerbreadas as all APIs are future-compliant. The only problem would be is if an app is developed using 2.3 APIs and you would try to use it on earlier roms or if it used undocumented/unofficial APIs that were not supposed to be used and were discontinued in future releases.
We don't know what 's causing vPlayer not to work, could be many things (kernel, unfinished rom development, missing libs) or it could be things in vPlayer that were improperly implemented.
Send a log to developer and see if he/she can help you. Given that you're not running official (or at least stable!) release, you may not get far though.
But please, don't jump on that "fragmentation" train, it's not nearly as bad as people make it out to be.

borodin1 said:
You should've stop right there.
Click to expand...
Click to collapse
First off, I didn't ask for you to be a ****, if I would have posted this in the dev forum that would have prompted you to respond as such.
borodin1 said:
You realize that at this point only 1(!) phone is running official 2.3 Gingerbread and it's Samsung Nexus S. It's a drop in a bucket comparing to all of the phones that are running official 2.x firmware.
Furthermore, if an app is properly developed against 1.x or 2.x SDK then it will work with gingerbreadas as all APIs are future-compliant. The only problem would be is if an app is developed using 2.3 APIs and you would try to use it on earlier roms or if it used undocumented/unofficial APIs that were not supposed to be used and were discontinued in future releases.
We don't know what 's causing vPlayer not to work, could be many things (kernel, unfinished rom development, missing libs) or it could be things in vPlayer that were improperly implemented.
Send a log to developer and see if he/she can help you. Given that you're not running official (or at least stable!) release, you may not get far though.
Click to expand...
Click to collapse
Thanks for the answer, i guess.
borodin1 said:
But please, don't jump on that "fragmentation" train, it's not nearly as bad as people make it out to be.
Click to expand...
Click to collapse
Now that that is out of the way, can I ask you HOW you can honestly say that Android isn't fragmented. Seriously ask your self... I LOVE android, I really do, G1-cliq-MT3G-Nexus One-HD2(androided)-MT4G, but I can't even lie about that. There is 9 API levels!! 2.3, 2.2, 2.1, 2.0.1, 2.0, 1.6, 1.5, 1.1, 1.0.
NOW I DO UNDERSTAND THAT ALMOST 45% ARE ON 2.2 and 40% ARE ON 2.1.
Ok, so now most apps are going to be working on that 84% of phones running level 7+.
But this ALSO doesn't account for the manufacture API's that are implemented buy some of them, which I KNOW causes some problems. (skype on the Samsung Galaxy Series) just to name one very big one. Skype works on other devices with 2.1, but it doesn't on the Samsung 2.1? as a consumer, I'd ask wtf, even with their limited knowledge of android.
Fragmentation is defined as is the inability to "write once and run anywhere". Rovio complained about this. Albeit not directly, but they said that they were having issues with people on some phones, with some versions of software, and that it wasn't going to work across the board.
I hate to admit it but there are certain things that need to be done to insure that Android will not only be the "Mobile OS" but it will also be the demanded one (IMHO):
1. Cut the bull**** manufacture stuff out, make only ONE set of API's, with 0 proprietary API's. Make it stuff that you can get if you want through the Android Market (custom UI's and such).
2. Control the god-damn market, find spammers, find shady devs re-uploading their apps multiple times to get ad dollars.
3. Get everybody on board to updates, require that all devices with X specifications be updated Y months after a source is released. That will get again get everyone on the same API level, and will make all apps compatible (maybe slow).
4. For the love of all holy, USE THE BEST COMPONENTS YOU CAN FIND! AND MAKE IT A STANDARD At least for the primary functions of the phone. For example, the Nexus One (my fave so far) did NOT have a competent touch screen, 2 point, and a BAD 2 point at that, and that is considered to be the new dev phone. Well who the HELL would want to dev for a platform that can only recognize two points (barely) that doesn't always even get them right? I sure as hell wouldn't. Finally I get the MT4G, the FIRST thing i did was test the touch screen, and guess what... It still is sub-par. 4 points, where my friends Galaxy S can do 6 or something. Now you are going to ask me, who uses 6 points idiot? Some games, do, and to top **** off, if you can't recognize 2 points properly, close together, how can some of the basic multi-touch functions work? (google maps on the N1)
I'm sorry for the rant, but I'm realistic. A mobile platform can't win like this.
http://www.comp.nus.edu.sg/~damithch/df/device-fragmentation.htm

Why the epic 4g CyanogenMod port is not backed by the CM team my opinion.

Hello,
This was brought up in another thread that is now locked.This post asked the question.
http://forum.xda-developers.com/showpost.php?p=11287492&postcount=40
and this is the blog post by Cyanogen
http://www.cyanogenmod.com/home/a-note-on-unofficial-ports-and-how-to-get-it-right
From what I can make from the blog post that Cyanogen put up on the CM website the Epic 4g as well as the other Galaxy S CM ports are not backed by Cyanogen because they do not go through the normal chain of how they add their code into their source code tree.The Galaxy S CM github has many changes to the stock android code that could possible and probably does break the code from being compiled for other phones. The framework is modified to work with the Samsung RIL that our phones use. The CM team will make additions to the stock android code not modifiy the stock code itself. So from my understanding of thing this is why Cyanogen does not consider what the CMSGS team has done as a part of the mainline CM code base. I believe this goes for all the Galaxy S phones not just the Epic.

Does being backed by the CM team make it get done any quicker? If so....
Sent from my SPH-D700 using XDA App

Being backed by the Cm team would definitely speed up the porting process, Cyanogen had the Evo Release Client up and running in a little over a month without source

So its a matter of pulling the source together and prperly placing it into their source control so their build bot can properly dov what build bots do...build...then CM helps with the port process?
If I think I'm following that right...somone better start uploading code to Cyanogens t&c's(terms and conditions) so we can have some epic awesomesauce.
Sent from my SPH-D700 using XDA App

Most importantly, no major hardware functionality should be broken.
Click to expand...
Click to collapse
What this statement implies is that no Cyanogenmod port is ever gonna be official right away; there's always an in-progress period where major functions are broken. Regardless of other issues, that's where our Epic port is at right now and part of the reason why it's not official.

Poryhack said:
What this statement implies is that no Cyanogenmod port is ever gonna be official right away; there's always an in-progress period where major functions are broken. Regardless of other issues, that's where our Epic port is at right now and part of the reason why it's not official.
Click to expand...
Click to collapse
True but there is code that is changed in the Galaxy S port that doesn't get changed at all in other CM ports as far as I know.

If we had HTC Epic's instead of Samsung Epic's and still identical devices... CM would officially support the Epic.
Period. They can say whatever they want but we all know this to be the case. You can't tell me Samsung changes their code that much more then HTC... last I checked Sense was a much more in depth overall to the underlying OS then Touchwiz is.. but maybe not.

The thing is, HTC uses the same hardware across the board (snapdragon processors, same camera etc.) which makes Rom ports much much easier to pull off, whereas the Hummingbird in the Galaxy S is only in the Galaxy S and only the Unlocked Galaxies and Gsm have froyo source so far.

Thanks for osting this skeeter
Android Creative Syndicate- From spontaneous ingenuity, comes creative brilliance

063_XOBX said:
The thing is, HTC uses the same hardware across the board (snapdragon processors, same camera etc.) which makes Rom ports much much easier to pull off, whereas the Hummingbird in the Galaxy S is only in the Galaxy S and only the Unlocked Galaxies and Gsm have froyo source so far.
Click to expand...
Click to collapse
The changes in the code have nothing at all to do with the cpu its all for the radio which even having froyo source will not help a bit with.Its all in the way the code changes were done. Rather then adding to the base code in CM the code was directly changed which is what Cyanogen has an issue with doing so basically could and probably has broken the radio code for other cdma phones, I don't know what or if any of the code in the frameworks was changed for the gsm Galaxy S phones so I can't say for sure that it the source from the CMSGS github wouldn't work on another GSM phone I only know that changes were made to get it working on the Epic and Fascinate.I don't think what the CMSGS team did was wrong they did what they had to do to get things working and from the time I spent working on it it didn't seem like there was much input from the CM team at all but that was probably happening in another irc channel that I was not invited into if they were involved.I was hoping that the Galaxy S would have had more interest from the CM team as a whole I know a phone or two was collected and donated to at least one dev and i also heard that Koush was supposed to take over the Captivate port of CM I am not sure if that ever happened or not but the Epic and Fascinate were from the beginning the red headed step children of the Galaxy S line it really is too bad that there wasn't for developers around to help work on it and make an offical Cyanogen backed CM port.I blame it all on the Evo personally if the Epic came out first it would be the Epic sporting all the kernel and roms that you can find in the Evo forum instead we are left with a handful or less of devs and a phone that is far from the potential that it has.

This statement brings up one of my biggest questions I have for the epic forums that I have yet to understand. If a lack of devs are the biggest problem for the epic why is it they are not attempting to train anyone else. Here's my point. I have cataloged every bit (and still am) of info I know about themeing android and the samsung epic. I wrote guides breaking down every part of installing the tools necessary and using them so anyone just sitting down with a fresh windows and their first android phone would understand. Where are our dev guides besides "read developer.android.com". I've read it, I've set everything up. I've downloaded source, I've even ran make with success. But it does nothing without proprietary files. How do you plug them in. extract files.sh dont work without cm6 running on my phone. Where do we learn how to edit our build.prop, init.rc, compile drivers and modules. Joey krimm it's a great beginners source but what about updates since the stall between ubuntu 10 64 support, and 64 becoming the default. I feel like not only it's sammy and sprint at fault, but so are devs that arent open with their knowledge. The best gift this community could have gotten in all of this "down time"waiting was time spent learning. Devs stuck waiting on modems and source, start writing and teaching so when you get that source, you'll have a team behind you. That's the spirit of linux and it dont exist on xda's Samsung Epic Development section!
Sent from my SPH-D700 using Tapatalk

dreamsforgotten said:
This statement brings up one of my biggest questions I have for the epic forums that I have yet to understand. If a lack of devs are the biggest problem for the epic why is it they are not attempting to train anyone else. Here's my point. I have cataloged every bit (and still am) of info I know about themeing android and the samsung epic. I wrote guides breaking down every part of installing the tools necessary and using them so anyone just sitting down with a fresh windows and their first android phone would understand. Where are our dev guides besides "read developer.android.com". I've read it, I've set everything up. I've downloaded source, I've even ran make with success. But it does nothing without proprietary files. How do you plug them in. extract files.sh dont work without cm6 running on my phone. Where do we learn how to edit our build.prop, init.rc, compile drivers and modules. Joey krimm it's a great beginners source but what about updates since the stall between ubuntu 10 64 support, and 64 becoming the default. I feel like not only it's sammy and sprint at fault, but so are devs that arent open with their knowledge. The best gift this community could have gotten in all of this "down time"waiting was time spent learning. Devs stuck waiting on modems and source, start writing and teaching so when you get that source, you'll have a team behind you. That's the spirit of linux and it dont exist on xda's Samsung Epic Development section!
Sent from my SPH-D700 using Tapatalk
Click to expand...
Click to collapse
Where's the thank spam? hah.
I've slowly been dipping myself into the Developer 'pool' for the epic if you will..and at first when I started working nobody really ever helped out..they just threw me a link and was like..start reading blah blah blah..
Reading only gets you so far; Imho you learn better when you've got the experience of working first hand with the material you're trying to learn.

dreamsforgotten said:
This statement brings up one of my biggest questions I have for the epic forums that I have yet to understand. If a lack of devs are the biggest problem for the epic why is it they are not attempting to train anyone else. Here's my point. I have cataloged every bit (and still am) of info I know about themeing android and the samsung epic. I wrote guides breaking down every part of installing the tools necessary and using them so anyone just sitting down with a fresh windows and their first android phone would understand. Where are our dev guides besides "read developer.android.com". I've read it, I've set everything up. I've downloaded source, I've even ran make with success. But it does nothing without proprietary files. How do you plug them in. extract files.sh dont work without cm6 running on my phone. Where do we learn how to edit our build.prop, init.rc, compile drivers and modules. Joey krimm it's a great beginners source but what about updates since the stall between ubuntu 10 64 support, and 64 becoming the default. I feel like not only it's sammy and sprint at fault, but so are devs that arent open with their knowledge. The best gift this community could have gotten in all of this "down time"waiting was time spent learning. Devs stuck waiting on modems and source, start writing and teaching so when you get that source, you'll have a team behind you. That's the spirit of linux and it dont exist on xda's Samsung Epic Development section!
Sent from my SPH-D700 using Tapatalk
Click to expand...
Click to collapse
When it comes to working on CM most of the work that needs to be done is all coding which we have very few if anyone java coders. Also you can use extract-files.sh on a phone running straight DK28 to get the propietary files needed to build CM with.When it comes to everything else most of the devs have taught themselves how to do the things they so by trial and error and alot of reading the internet. I know I have little coding skill so its would be hard to teach someone something you don't know how to do yourself and alot of the other things like putting togther device files to build android even on the google site has no real information on how to do it at all the best way I think is to just compare what the other phones use and piece it together from that.

Yet it still makes me wonder; why no epic/galaxy s support? Virtually every other phone, and even some tablets like the gtab, have CM support and even CM7 support. Even the HTC Hero, with obviously no source code for 2.2 or 2.3 and no official 2.2 ever to be released, has a working build of CM7. Is it pure incompetence of Epic developers? Is it a lack of interest? Is it simply cyanogen not wanting to support galaxy s devices? I really don't know, but I'd really like to.

theimpaler747 said:
Yet it still makes me wonder; why no epic/galaxy s support? Virtually every other phone, and even some tablets like the gtab, have CM support and even CM7 support. Even the HTC Hero, with obviously no source code for 2.2 or 2.3 and no official 2.2 ever to be released, has a working build of CM7. Is it pure incompetence of Epic developers? Is it a lack of interest? Is it simply cyanogen not wanting to support galaxy s devices? I really don't know, but I'd really like to.
Click to expand...
Click to collapse
From what I can see its not that Cyanogen doesn't want to support the galaxy s devices its that it seems they don't give any input to the devs that are working on CM for the galaxy s. They have basically split off from the main CM source tree itself and run their own source tree. It seemed like (and this is from the limited amount I saw on irc) that there was no input from the CM team they just let them work on their own. CM has ways to setup the code so the source tree remains workable across the board on all the devices it supports, the cmsgs team has just taken a different route on things and gone their own route thus making it not backed by cyanogen, was it the right way to do it who knows but it has made all the galaxy s devices redheaded step children in the eyes of Cyanogen and the CM team as a whole by the looks of it. I know from the point of view of having an Epic the major hold up to it is having coders with the proper skills to do the coding in general we had one coder working on it I don't know if he is still involved or not at this point. All I know is to make is a backed by Cyanogen CM port the coding that has been done so far would have to be completely redone in the ways that the rest of the CM team adds code to the CM source tree with as little to no modification of the stock CM code as possible.
Also I would like to add that I am not trying to put anyone down that is working on the CMSGS team they have done CM working on these devices and am in no way bad mouthing the work that has been done. This is just my view on things and why Cyanogen doesn't back the galaxy s CM ports.
Sent from my SPH-D700 using Tapatalk

theimpaler747 said:
Yet it still makes me wonder; why no epic/galaxy s support? Virtually every other phone, and even some tablets like the gtab, have CM support and even CM7 support. Even the HTC Hero, with obviously no source code for 2.2 or 2.3 and no official 2.2 ever to be released, has a working build of CM7. Is it pure incompetence of Epic developers? Is it a lack of interest? Is it simply cyanogen not wanting to support galaxy s devices? I really don't know, but I'd really like to.
Click to expand...
Click to collapse
Well, trying to comprehend everything that is going on here, I feel like the CMTeam does not feel the Epic is worth porting to CM7 due to it's delay on a FroYo source, which I am positive would make the Epic's porting much easier.
However, it still makes me wonder why they could not have used 2.1 to port to CM7, as like you said, the Hero has been able to do.
It also confuses me that the Captivate has even been able to run a Gingerbread port (I believe cyanogen) then. I realize that the Captivate has no 4G or a slide or anything, but the fact that they were willing to work off of 2.1 I assume gets me wondering why no one has tried making a CM port for the Epic's 2.1
I am trying to understand this as best as I can, so please forgive me if I seem to be giving false input on this conversation.

Its the time taken to port a phone, combined with the number of phones above yours on their list. The fact is they have a list of other phones they feel like investing their time in over the galaxy s line in general which is even more of a reason all knowledge of development on the Epic should be layed out even in pieces like the rest of the information here. Honestly thinking "leak it to noobnl, then we'll get all the goods" isn't going to cut it. Java coders, ubuntu fanatics who have compiled a few apps, and new people willing to learn should be putting heads together compiling new ****. If we dont start a group effort of making a bone stock aosp froyo altering the existing drivers were not going to be much further with source code. And it should be layed out here irc dont work for everyone.
Sent from my SPH-D700 using Tapatalk

acer1096xxx said:
Well, trying to comprehend everything that is going on here, I feel like the CMTeam does not feel the Epic is worth porting to CM7 due to it's delay on a FroYo source, which I am positive would make the Epic's porting much easier.
However, it still makes me wonder why they could not have used 2.1 to port to CM7, as like you said, the Hero has been able to do.
It also confuses me that the Captivate has even been able to run a Gingerbread port (I believe cyanogen) then. I realize that the Captivate has no 4G or a slide or anything, but the fact that they were willing to work off of 2.1 I assume gets me wondering why no one has tried making a CM port for the Epic's 2.1
I am trying to understand this as best as I can, so please forgive me if I seem to be giving false input on this conversation.
Click to expand...
Click to collapse
But like I said, there's CM7 (Android 2.3 if you don't know) for the HTC hero, with no 2.2 or 2.3 source code. So why not us?

theimpaler747 said:
But like I said, there's CM7 (Android 2.3 if you don't know) for the HTC hero, with no 2.2 or 2.3 source code. So why not us?
Click to expand...
Click to collapse
Alright, this is what I believe.
The Hero does not have 4G, or a QWERTY keyboard, two things the Epic does have that could make a pure AOSP port more difficult without a source. Also, HTC runs Snapdragon throughout the whole system, making tweaks a lot more simpler than SGS's Hummingbird Processor, which uses something else (I can't remember) with their system as well.
The last part I'm not sure if that makes a big deal or not, since I have seen a (what I think) CM7 port for the Samsung Captivate, so it may simply be because of 4G and the QWERTY keyboard.
I see what you're saying though. I guess the CMTeam should have no problem making a CM7 port based off of the Epic's 2.1 source...maybe they're just waiting because 2.2 might make it easier and supposedly 2.2 is coming soon so there'd be no point in starting now...otherwise I have no clue.

acer1096xxx said:
Alright, this is what I believe.
The Hero does not have 4G, or a QWERTY keyboard, two things the Epic does have that could make a pure AOSP port more difficult without a source. Also, HTC runs Snapdragon throughout the whole system, making tweaks a lot more simpler than SGS's Hummingbird Processor, which uses something else (I can't remember) with their system as well.
The last part I'm not sure if that makes a big deal or not, since I have seen a (what I think) CM7 port for the Samsung Captivate, so it may simply be because of 4G and the QWERTY keyboard.
I see what you're saying though. I guess the CMTeam should have no problem making a CM7 port based off of the Epic's 2.1 source...maybe they're just waiting because 2.2 might make it easier and supposedly 2.2 is coming soon so there'd be no point in starting now...otherwise I have no clue.
Click to expand...
Click to collapse
I think we also have 'limited functionality' w/ 2.1 as far as the phone's full capability.
2.2 will unlock some hidden potential IMO. Could be the reason why all the hubbub to 'wait for 2.2'.. again, just speculating.