Related
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
Hello,
I would like to change the HTC Hero's firmware/ROM to match that of the HTC Magic's firmware/ROM. My phone is CDMA, but I'm hoping that somehow, someway it is possible to do this. My reason for wanting this is so that I can finally do mods, like Cyanogen, since the CDMA Hero isn't really that widely supported, yet.
Thanks in advance for any help,
Tyler
Any new ROM will have to be CDMA, you can't change that since it has to do with phone hardware.
I have been.trying to port over gsm roms forever and.with no luck. Theoretically its possible but I haven't the faintest idea how.
Well, then I guess I have to resort to my last and great question. Since I'm stuck with my Hero, unless I go T-Mobile, how long, do you guys suspect, that it will take for more support to role out, like there is for the Magic? I ask because I'm wanting to know rather, or not there is a lot of development happening for the Hero because I really want great functionality and mod availability. At this point, if the answer is "not a lot", I may just drop the Hero for the Magic.
Thanks again for answering my questions,
Tyler
thejedislayer said:
Well, then I guess I have to resort to my last and great question. Since I'm stuck with my Hero, unless I go T-Mobile, how long, do you guys suspect, that it will take for more support to role out, like there is for the Magic? I ask because I'm wanting to know rather, or not there is a lot of development happening for the Hero because I really want great functionality and mod availability. At this point, if the answer is "not a lot", I may just drop the Hero for the Magic.
Thanks again for answering my questions,
Tyler
Click to expand...
Click to collapse
So you're saying you're "STUCK" with a month and a half old phone, unless "more people start supporting it"? i.e. People spending their free time creating mods for the Hero, so that you can get it for free? And if people aren't going to do mods and features for free in the near future, then you're just going to get rid of your Hero and go to T-Mobile for the Magic because it has people who are dedicated to releasing software they dont get paid to spend time working on? Seems like a lot of complaining about something that is completely voluntary, nobody has to work on any mods and nobody has to support any device. If you want to drop your Hero, just do it already. Nobody wants you to keep using it, nobody is forcing you to keep using it. Just do it already, nobody cares to read threads like this.
Wow, you took what I said and totally blew it out of proportion. The reason I wanted to get Android was because I wanted to be able to do things, like root my Android device. I fully support developers in their endeavor to develop applications, mods, ROMS, etc for all Android devices on their time. I do not, however, sit here and feel that the best idea to do is to whine and cry about support for my Android device not yet being fully supported or embraced. I simply asked rather, or not heavy development was going to happen in the near future, so as to ascertain a good decision on rather I should switch. That way I could get the full and best support and benefit from my personal experience with Android. I am not a developer. I've only gotten into this, so I was simply curious as to how development was coming along for the Hero at this time, and rather it may have been a better idea to just switch. Sorry To Have Offended The Offended.
**EDIT**
And understandably, having reread what I wrote, I can understand how what I said may have come off as a little dickish; however, it was not my intention, nor was it my wanting to cause a conflict.
thejedislayer said:
Wow, you took what I said and totally blew it out of proportion. The reason I wanted to get Android was because I wanted to be able to do things, like root my Android device. I fully support developers in their endeavor to develop applications, mods, ROMS, etc for all Android devices on their time. I do not, however, sit here and feel that the best idea to do is to whine and cry about support for my Android device not yet being fully supported or embraced. I simply asked rather, or not heavy development was going to happen in the near future, so as to ascertain a good decision on rather I should switch. That way I could get the full and best support and benefit from my personal experience with Android. I am not a developer. I've only gotten into this, so I was simply curious as to how development was coming along for the Hero at this time, and rather it may have been a better idea to just switch. Sorry To Have Offended The Offended.
Click to expand...
Click to collapse
There are many threads with people making their own roms, and modifications are being made to the hero by various people. Heavy development like going to 1.6 or 2.0 will most likely not happen by any developer, but by HTC itself. Once they release a new version, people will make a new rooted ROM with all the changes. For a fairly new phone, it got rooted fairly quickly (within a month of being released or so). It hasn't even been rooted all that long yet. All of this information is available in various threads. In the end its your decision on if you can wait or not to receive updates. Bleeding edge isn't always the best choice for everybody. If you prefer bleeding edge, perhaps you did get the wrong phone because there will likely be much more activity with, say, the Droid. But as for apps, there should be tons and tons of more apps coming available for the android platform as time goes on. I just cant see why you would want to switch phones based on a really short time period of it being out, jumping ship because it hasn't been hailed and given 100% attention by tons of developers yet. Honestly, as more android phones are released, I think more people will start developing for them and the android community itself will continue to grow. There are still some 7 year old Casio devices that receive updates, if you can believe that.
In all honesty, I knew I was a little quick to jump the gun when I said rather, or not it was a good decision to move from the Hero to the Magic. Again, this is all really new to me. In my mind, my main concern was that because of the Hero's Sense UI, this would make it a lot harder for developers, like Cyanogen Mod, to keep the Hero up-to-date with the rest of the older Android devices. The Magic, seeing it being a lot more supported in just three short months since its debut, made more sense to me to possibly move to. As it had tons of development happening for it, and I simply wanted to be apart of the action.
wouldn't a 1.6 Rom work since it "supports CDMA" out of the box???
@ azfxstb
I took the liberty of looking around, and I ended up finding some links from HTC for 1.6 support. Link: http://developer.htc.com/google-io-device.html
According to the article, though, the next successive version relies on a previous version in order to update properly. In other words, in order to know I have full functionality and support, I would have to start from the beginning of the Magic's support and simply continue updating till I reach the newest update. I may be wrong, but if I'm not, then it may be something worthwhile considering, even if it's a hassle. Anyone have any thoughts about this method?
I'd say stick it out. The Sprint Hero hasn't even been out for 2 months and it is rooted and there are a couple of custom ROM's posted here. I've had my Hero for 2 weeks and have already tried numerous releases, and all have been very stable for me.
I'd love to see some of the improvements Cyanogen come over, and I'm sure they will eventually, but you have to remember how long of a time frame the Magic had to work with.
azfxstb said:
wouldn't a 1.6 Rom work since it "supports CDMA" out of the box???
Click to expand...
Click to collapse
We don't know that HTC's shoehorned CDMA support into 1.5 is compatible with the built-in CDMA support in 1.6. What that means is that there's a potential that even if we did get a 1.6 build on the phone, HTC's proprietary (i.e., not required to release source code for) software that sits between the Android framework and the linux kernel (which in turn talks to the hardware) might be speaking a different language that Android 1.6 can't understand. That's the problem with their hacked-together 1.5 build. Make note that I do not know this for certain, but it's certainly a possibility, and if that's the case, we'd have a broken phone until those HTC layers could be translated from hacked-1.5 to native-1.6.
That's why, as already stated above, those moves probably won't happen until HTC releases a 2.0 build (which means we might never see 1.6 run on this phone even after the 2.0 release, since we'll never have the HTC software that is written specifically for the 1.6 platform).
To break it down, the phone has 2 processors: ARM9 and ARM11. ARM9 runs the radio hardware, and the radio controls literally *everything* that makes this phone usable. Think of ARM9 like your computer's BIOS chip. Except in a very rare case of someone who really really wants to hack on their phone, the ARM9 will never be modified by us.
The ARM11 is the next layer, and that's what actually runs the OS, recovery images, etc. The ARM11 is able to communicate with the ARM9 using a series of two-way communication channels (shared memory) and hardware interrupts.
The linux kernel contains drivers that on one side talk to the ARM11 and other hardware in the phone, and then expose controls on the other side that allow the rest of the OS to work with those things (e.g., turn the screen on/off, register touches on the screen, play sounds, vibrate, make calls, etc).
For some things, that's enough to let Android take over and actually make use of some of those things (LCD, touchscreen, sound, ...). Still, there are other things that require intermediate controllers between the devices exposed by the kernel and Android. For example, "rild" is in charge of managing the modem as far as things like issuing commands to your carrier, getting online, telling the modem to make a call, finding out signal strength, etc. But HTC wrote their own ril that interacts with the modem -- and they aren't required (in fact, they're not allowed!) to release the source code for that, because a) it was developed using proprietary information given to them (under NDA no doubt) by Qualcomm, and/or b) it contains information that HTC themselves want to keep private, protecting their intellectual property, etc. There are several other userland libraries like that, which are NOT part of the kernel, and therefore are not required to be released as open source. Yet they are required for Android to work, as android will speak directly to those libraries, which translate the messages in order to communicate with the kernel, which communicates with the ARM11, which talks to the ARM9, which makes it happen.
The breakdown happens at the "android speaks to the libraries" step, because Android 1.5 speaks a certain language, and that's (potentially) different from the Android 1.6 language. Yes this phone is CDMA, and yes Android 1.6 has native support for CDMA... So, you say, putting Android 1.6 on the phone should "just work". But the HTC libraries that are on our phones are not designed for 1.6, they're designed for 1.5. And they're not even designed for the "standard" GSM 1.5, but for a "hacked" CDMA 1.5! If we put Android 1.6 on the phones, we could *try* to reuse the existing binary form of the HTC libraries, but if 1.5 and 1.6 talk different languages (most likely they do), the 1.5 version of the binary libraries are going to get confused and reject it. Then we're left with a 1.6 platform that can't talk to the 1.5 libraries, and we get major functionality meltdown. To be fair, it would be possible to write an additional translation layer that would convert the 1.6 messages into something that we "think" the 1.5 libraries will understand, but is it really worth the effort? (hint: it's not a small effort ) Then try doing the same with 2.0, and the potential for translation problems are even worse...
And not to mention, 2.0 also requires the 2.6.29 kernel, which (surprise, surprise), does not exist (for this phone) in the wild. We could theoretically get 1.6 running, since we already have a working 2.6.27 kernel (the phone shipped with it, and if we assume that the shipped kernel is "good enough", we can simply reuse it -- we already do that with the recovery image and even MoDaCo's rom). But as soon as we think about either modifying the kernel as it is, or god forbid, upgrading to 2.6.29, we hit a roadblock because we don't have the source code yet for the 2.6.27 kernel. Once that code is released, we could hypothetically port that support to 2.6.29. Or once HTC releases an Eclair build for this phone, it'll be guaranteed to have a ready-made 2.6.29 kernel buried inside, as well as the binary HTC libraries that are required for our phone. Until one of those two things happens (or, admittedly, someone reverse-engineers what's required... which quite frankly is not worth anyone's time considering we know that HTC *will* release both of those things eventually), Eclair is absolutely out of the question.
The short version (go ahead, admit it, you skipped to here even though I didn't put a "short version at the end" disclaimer at the top): 1.6 will absolutely require reverse-engineering the HTC libraries, just to get an already outdated (albeit still an upgrade) version of the OS on the phone -- not worth the effort. 2.0 will absolutely require reverse-engineering (both the kernel AND the binary libraries), just to get Eclair running on the phone maybe a couple weeks before HTC gives it to us on a silver platter -- And you're still likely to have a partially gimped phone at that point!
And the moral is: this **** is hard. HTC is already doing the work we need. HTC will make everything work "reasonably well". And they'll give it to us when they're done. Thus, no one *wants* to waste the effort doing it themselves. Ergo: we wait.
maejrep said:
We don't know that HTC's shoehorned CDMA support into 1.5 is compatible with the built-in CDMA support in 1.6. What that means is that there's a potential that even if we did get a 1.6 build on the phone, HTC's proprietary (i.e., not required to release source code for) software that sits between the Android framework and the linux kernel (which in turn talks to the hardware) might be speaking a different language that Android 1.6 can't understand. That's the problem with their hacked-together 1.5 build. Make note that I do not know this for certain, but it's certainly a possibility, and if that's the case, we'd have a broken phone until those HTC layers could be translated from hacked-1.5 to native-1.6.
That's why, as already stated above, those moves probably won't happen until HTC releases a 2.0 build (which means we might never see 1.6 run on this phone even after the 2.0 release, since we'll never have the HTC software that is written specifically for the 1.6 platform).
To break it down, the phone has 2 processors: ARM9 and ARM11. ARM9 runs the radio hardware, and the radio controls literally *everything* that makes this phone usable. Think of ARM9 like your computer's BIOS chip. Except in a very rare case of someone who really really wants to hack on their phone, the ARM9 will never be modified by us.
The ARM11 is the next layer, and that's what actually runs the OS, recovery images, etc. The ARM11 is able to communicate with the ARM9 using a series of two-way communication channels (shared memory) and hardware interrupts.
The linux kernel contains drivers that on one side talk to the ARM11 and other hardware in the phone, and then expose controls on the other side that allow the rest of the OS to work with those things (e.g., turn the screen on/off, register touches on the screen, play sounds, vibrate, make calls, etc).
For some things, that's enough to let Android take over and actually make use of some of those things (LCD, touchscreen, sound, ...). Still, there are other things that require intermediate controllers between the devices exposed by the kernel and Android. For example, "rild" is in charge of managing the modem as far as things like issuing commands to your carrier, getting online, telling the modem to make a call, finding out signal strength, etc. But HTC wrote their own ril that interacts with the modem -- and they aren't required (in fact, they're not allowed!) to release the source code for that, because a) it was developed using proprietary information given to them (under NDA no doubt) by Qualcomm, and/or b) it contains information that HTC themselves want to keep private, protecting their intellectual property, etc. There are several other userland libraries like that, which are NOT part of the kernel, and therefore are not required to be released as open source. Yet they are required for Android to work, as android will speak directly to those libraries, which translate the messages in order to communicate with the kernel, which communicates with the ARM11, which talks to the ARM9, which makes it happen.
The breakdown happens at the "android speaks to the libraries" step, because Android 1.5 speaks a certain language, and that's (potentially) different from the Android 1.6 language. Yes this phone is CDMA, and yes Android 1.6 has native support for CDMA... So, you say, putting Android 1.6 on the phone should "just work". But the HTC libraries that are on our phones are not designed for 1.6, they're designed for 1.5. And they're not even designed for the "standard" GSM 1.5, but for a "hacked" CDMA 1.5! If we put Android 1.6 on the phones, we could *try* to reuse the existing binary form of the HTC libraries, but if 1.5 and 1.6 talk different languages (most likely they do), the 1.5 version of the binary libraries are going to get confused and reject it. Then we're left with a 1.6 platform that can't talk to the 1.5 libraries, and we get major functionality meltdown. To be fair, it would be possible to write an additional translation layer that would convert the 1.6 messages into something that we "think" the 1.5 libraries will understand, but is it really worth the effort? (hint: it's not a small effort ) Then try doing the same with 2.0, and the potential for translation problems are even worse...
And not to mention, 2.0 also requires the 2.6.29 kernel, which (surprise, surprise), does not exist (for this phone) in the wild. We could theoretically get 1.6 running, since we already have a working 2.6.27 kernel (the phone shipped with it, and if we assume that the shipped kernel is "good enough", we can simply reuse it -- we already do that with the recovery image and even MoDaCo's rom). But as soon as we think about either modifying the kernel as it is, or god forbid, upgrading to 2.6.29, we hit a roadblock because we don't have the source code yet for the 2.6.27 kernel. Once that code is released, we could hypothetically port that support to 2.6.29. Or once HTC releases an Eclair build for this phone, it'll be guaranteed to have a ready-made 2.6.29 kernel buried inside, as well as the binary HTC libraries that are required for our phone. Until one of those two things happens (or, admittedly, someone reverse-engineers what's required... which quite frankly is not worth anyone's time considering we know that HTC *will* release both of those things eventually), Eclair is absolutely out of the question.
The short version (go ahead, admit it, you skipped to here even though I didn't put a "short version at the end" disclaimer at the top): 1.6 will absolutely require reverse-engineering the HTC libraries, just to get an already outdated (albeit still an upgrade) version of the OS on the phone -- not worth the effort. 2.0 will absolutely require reverse-engineering (both the kernel AND the binary libraries), just to get Eclair running on the phone maybe a couple weeks before HTC gives it to us on a silver platter -- And you're still likely to have a partially gimped phone at that point!
And the moral is: this **** is hard. HTC is already doing the work we need. HTC will make everything work "reasonably well". And they'll give it to us when they're done. Thus, no one *wants* to waste the effort doing it themselves. Ergo: we wait.
Click to expand...
Click to collapse
WOW...did you stay at a Holiday Inn Express last night????....J/K thanks for the in depth explanation
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
I did my homework, and have come up mostly empty. Read what I could find on the CM site; wikipedia; blogs; newsgroups; and a lot more. Probably at least 2 hours trying to get a comparative handle on CM vs. stock release derived ROMs.
After all that, I'm only a tiny bit closer to understanding what I gain, and what I give up, going to CM.
If there if a good, detailed articulation of this somewhere, please help us CM noobs with a pointer; Otherwise, I'd like to start a thread to capture as much detailed information about comparing CM to stock-based ROMs so people can make informed choices.
Sent from my mind using telepathitalk
http://wiki.cyanogenmod.com/index.php?title=What_is_CyanogenMod
Thanks, that's a start, but in truth it's information like that that prompted my starting this thread.
That's generic information. Only moderately helpful in judging specifically for the Epic whether I should go CM, or with another custom ROM.
For example, info like this: CM does not include the accelerated Samsung video player, and doesn't handle many video formats and codings well in comparison. So, if playing h264 coded video in mkv containers is important to you, CM will be a challenge, where Bonsai, ACS, Midnight, etc. will be a much simpler choice to meet your needs.
Sent from my mind using telepathitalk
Think about it like this. If you buy a PC from a big company (HP, Dell, etc) it comes with a fully functional install of software. Windows + drivers + all other crap they decide you should have. That is equivalent to the Samsung ROM that comes stock on Epic.
What if you build your own PC from components? You will install Windows, then you will dig up the drivers you need separately, and then load your own applications.
Android AOSP in this comparison is the "base" install of Windows. Nothing else added in.
The drivers and other changes required to make the base Android work with your hardware is CyanogenMod.
So basically, Samsung based roms will have all the functioning drivers and everything else in them. Dev's tear them apart and remove/change what they don't want, but don't have to worry much about hardware cause the drivers are straight from Samsung.
AOSP based roms (CyanogenMod) will be utterly broken and have no hardware support at first. Developers have to write real lines of code into the software to make it support the Epic or any other phone. The are built from the ground up. That is why it is so amazing what Team CM7 has already got working in so little time!
Again, thanks for the sincere attempts to answer this qualitatively. However, that's not the issue. See my example above.
What you describe above with the custom PC example, while true, isn't informative enough for most people to make an informed decision.
Knowing that CM is free of carrier bloatware doesn't help me understand in any way that the video player with CM had some important limitations when compared to the optimized video player Samsung includes. For some people, this may be a critical issue in making a decision.
It is those sort of specific differences that I thought would be helpful to enumerate and capture. Of course anyone can simply install the ROM and discover for themselves... Judging by my own struggle to find enough information to make an informed choice myself, I thought others might benefit from nailing this stuff down.
So far, it looks like I may have been mistaken?
Sent from my mind using telepathitalk
dwallersv said:
Again, thanks for the sincere attempts to answer this qualitatively. However, that's not the issue. See my example above.
What you describe above with the custom PC example, while true, isn't informative enough for most people to make an informed decision.
Knowing that CM is free of carrier bloatware doesn't help me understand in any way that the video player with CM had some important limitations when compared to the optimized video player Samsung includes. For some people, this may be a critical issue in making a decision.
It is those sort of specific differences that I thought would be helpful to enumerate and capture. Of course anyone can simply install the ROM and discover for themselves... Judging by my own struggle to find enough information to make an informed choice myself, I thought others might benefit from nailing this stuff down.
So far, it looks like I may have been mistaken?
Sent from my mind using telepathitalk
Click to expand...
Click to collapse
So, you're looking for a more hand held description of what CM7 doesn't have?
....
Sent from my SPH-D700 using XDA App
I can give you the best piece of advice....
This is a development site, not a front end rom publishing site..
If there's not already documentation, test the differences yourself, and report the findings for the next gentleman who comes along with your same questions...
Then before too long you're not a "noob" anymore..
But to answer your question, cyanogen is a more bare bones android experience.. it is built off of the AOSP (ANDROID OPEN SOURCE PROJECT).. It is stripped of any carrier or manufacturer additions (like HTC Sense or Touchwiz).. and is usually a cleaner and less buggy experience... Then the cyanogen team customizes and polishes features... (like menu infused theming instead of flashable zips..)
If you're too scared of bricking during experimental build testing, etc, this isn't the place for you...
Sent from my Samsung-SPH-D700 using XDA Premium App
Will Cm7 on the epic have no CIQ?
Sent from my SPH-D700 using XDA Premium App
Sorry for the double post, the xda app submitted when open the physical keyboard. I too have been wondering what the big deal is with cm.. I can't find any concrete info that tells me what is so great about it. I'm on acs now and love it.
Sent from my SPH-D700 using XDA App
Overstew said:
Will Cm7 on the epic have no CIQ?
Sent from my SPH-D700 using XDA Premium App
Click to expand...
Click to collapse
It will not have CIQ. That is from Sprint, and this will have no traces of sprint whatsoever.
CM is completely customizable, it comes with all kinds of tweaks to make the phone a whole lot smoother, it gets updated constantly, and since its based on AOSP you can really do what ever you want with it. Whereas a stock samsung ROM you have to be careful what you do cause so many things rely on frame work and what not. The CM team is absolutely amazing the wrote code completely from scratch for $g and full HDMI mirroring to work on the evo. Also the size of the rom, CM is around 80 mb where most stock roms are 200, so you will have that much more space on the phone.
To set the record straight, I am hardly a "noob" in the sense that some here seem to think. I'm building kernels for my own use, and am working on a rewrite of the keyboard driver to more completely fix the problem so skillfully determined and patched by mkasick.
What I'm "noob" at is understanding in detail what I gain, and give up, by installing CM over the other custom ROMs based on stock releases. I have the broad strokes -- I need more specifics to decide if it's worth the hassle to give it a try.
We now have two new pieces of valuable information not obvious in any of the general info out there: Compromised video support (negative), no CIQ (positive). So, a little progress.
Sent from my mind using telepathitalk
i doubt anyone actually knows what you're asking....
Cyanogenmod is just pure android no bloatware from sprint/sammy
the way android was meant to be.
Pretty simple: If it is software that is added by a carrier or a manufacture (Sprint ID, touchWhiz, Samsungs Video Codecs) It will not be there. What it does have:
CM UI Tweaks, CM Hardware Tweaks, CM Performance enhancement options (adjustable heapsize) Default install location, Screen On Animation, Surface Dithering, Locking the Homescreen App in memory (so it doesn't rebuild it self when you press home), locking the messaging app in memory, DSP Audio Manager for Custom EQ setups over BT, Speaker, and head phones, Lock screen gestures, Lock screen music controls....
This is all of the top of my head.
Kcarpenter said:
Pretty simple: If it is software that is added by a carrier or a manufacture (Sprint ID, touchWhiz, Samsungs Video Codecs) It will not be there. What it does have:
CM UI Tweaks, CM Hardware Tweaks, CM Performance enhancement options (adjustable heapsize) Default install location, Screen On Animation, Surface Dithering, Locking the Homescreen App in memory (so it doesn't rebuild it self when you press home), locking the messaging app in memory, DSP Audio Manager for Custom EQ setups over BT, Speaker, and head phones, Lock screen gestures, Lock screen music controls....
This is all of the top of my head.
Click to expand...
Click to collapse
O O Don't forget the BJ's Feature
i even dumped my GF
There's a lot of misinformed posting going on in here.
First of all, CyanogenMod is NOT AOSP. It is, however, more AOSP than Samsung's or HTC's stock ROMs. It is based on AOSP and built from the ground-up, but AOSP it is not.
AOSP is the bones on which everything you see on Android is built. Some phones have true, pure AOSP builds, but we do not. The CyanogenMod project, once completely, will allow a build of AOSP to run on the Epic since they share all the same drivers, but, once again, that doesn't make CyanogenMod completely AOSP, as people so willingly say.
Now, what IS CyanogenMod?
The goal is quite simple: It aims to achieve a single user-experience across multiple platforms through the use of open-source software and alternatives. One thing you can expect from the base CyanogenMod experience is that if you are running CyanogenMod7-RC2 on your MyTouch 3G Slide, you can talk to you friend who is using CyanogenMod7-RC2 on his HTC Evo 4G and be able to completely understand everything each other's phone can provide (sans hardware differences, such as CPU speeds and front-facing camera).
It is also meant to open new doors for developers to completely customize their user experience. Every last part of the CyanogenMod experience is open source. That's how new features are almost constantly being added.
Another goal is to keep every phone up-to-date with the newest version of Android as it is rolled out. Providing a basic starting ground for every phone means that patching the Android system to the latest version is considerably easier. That's why, several times, I've mentioned that the work done by noobnl on CyanogenMod6 has helped us getting where we are with CyanogenMod7. While we are not using it verbatim, the work points us in the right direction and shows us how to easily fix what is broken.
People are asking questions like "Will program X be left in" or "Does this add X". The answers are a lot more complicated than just yes or no. The fact of the matter is that, for the most part, NOTHING from the stock Samsung software is included. Apps may resemble what was in your stock experience, but that's only because Samsung based their own software after their AOSP counterparts. With that said, none of Sprint's bloatware is on CyanogenMod. I'm not even sure the most of them would even work. Things like Nascar, Sprint TV, and the like just are not there because the system is not built around them, plain and simple.
Because of this lack of bloat, you are gaining much in the way of speed, performance, and usability. Carrier IQ isn't there to bog your phone down. Useless DRM services aren't running in the background, eating your battery. The Sprint Apps aren't taking up valuable space in your phone's memory. It's clean.
Another thing CyanogenMod will provide to the community is a basis to provide some real meaty ROMs. Right now, for the most part, the ROMs are reskins and rehashes of other ROMs, save two or three. Fight as you might, but that's the truth. CyanogenMod is completely different and will allow developers more control over what they are doing. A lot of cool features can be made, such as autoupdaters and random system tweaks, and they can all be built in. For example, if you look at CyanogenMod now, you'll notice that ADW is the default launcher, and its settings are integrated into the phone's settings instead of being a standalone.
And the beauty of it all is that everything can be made to work how you please. For those worried about the video codec problem, it's a problem that can be solved simply by making those codecs work on CyanogenMod, which shouldn't involve too much trickery.
I hope this answers your question.
I concur. You are really thinking too far into things. There are very few limitations that cm7 will bring. For all of these, there are other apps that rectify it.
Sent from my Samsung-SPH-D700 using Tapatalk
Thanks Devin for a great response. Why is it we needed development to come give a nice answer... and the rest of the users just wanted to be know it all jerks?
skywalkr2 said:
Thanks Devin for a great response.
Click to expand...
Click to collapse
agreed, thanks
Why is it we needed development to come give a nice answer... and the rest of the users just wanted to be know it all jerks?
Click to expand...
Click to collapse
aww man, don't do that.. it doesn't really help anything, it just invites people to get all butt hurt about your being butt hurt about whatever the ****.. Just let it go.
My only question about CM is the obvious one.. "Is it done yet? (for my phone obviously)"
I'd like to know where to start on making a CM12 compatible device (VS985/Verizon G3 in this case) work in omnirom, where to start? I already have knowledge in building ROMs but not doing a full port towards another ROM type (not a modified CM12 variant ROM) just to get that out of the way
Bump?
KShion619 said:
Bump?
Click to expand...
Click to collapse
Thing is, every device is different. Things that worked on one device might not work on another.
There are a few things where we can probably provide some "If you have this set in CM, you need to change it to that for Omni" - such as naming conventions for some of our CAF repos. These things are currently being redone for 5.1.
5.0 wasn't our proudest moment - a lot of us were mostly away for a good portion of the cycle, and we're just getting caught up now.
Also, in many cases, there might be patches to core repos needed for your device but none of our currently supported devices that require you to figure out what's missing - this can sometimes quite challenging.
In some ways, other than some basic hints about obvious differences, I don't want to provide TOO much detail, as for a device to be properly maintained it needs the maintainer to be independent and able to track down/solve issues themselves, as opposed to just blindly cherry-picking CM and applying some sort of step-by-step guide. Yes it's much more time consuming in the short term, but it allows a maintainer to truly learn the ins and outs of their device. We had a few devices in the 4.4 cycle where the maintainers blind-tracked CM and were not capable of anything more than basic cherrypicking, and the quality of those devices suffered.