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
Related
When the G1 came out it was the only Android powered device so modding it worked for everybody. And it was just one brand, HTC, so this forum was a one stop destination for modding our phone.
However, things have changed, now there are multiple phone with incompatible hardware from different manufacturers. Now a custom rom made for the G1, won't work on a DROID for example and vise versa. This complicates things quite a bit.
Right now Cyanogen mods are the best thing for our G1 and maybe the best thing for Android as a whole. I'm used to the build in tether capability and apps to SD and compcace and the other perks of a modded rom. But if I wanted to upgrade my phone, I would lose it all.
There are no Cyanogen mod for anything other than G1 and myTouch phones as far as I know and if I were to upgrade to DROID, I would lose root, lose tether, lose apps to SD, lose everything about my phone that makes it my phone.
Everything I wrote may not be facts, I don't really know what goes on at other forums, but I know that we don't have roms build to run on the DROID and we don't have them built to run on the HERO hardware, it's all for G1 and myTouch, and it seems to me that if I don't ha.ve on of those phones, I lose everything.
I do understand that this forum is for HTC devices which DROID and a few other's are not which is why I don't see homebrew for them. Is there a another website similar to this that supports all Android hardware?
These are thoughts that have been running through my head lately. If I am totally wrong here, please let me know.
I would say check out websites such as androidcommunity.com, androidandme.com, phandroid.com. The developers might not be on there but you can probably find links to where there are custom roms for the phones.
And you are right about different phones having different development oppurtunities. I thought about this today and realized that the next android phone I get not only has to be what I want but also be a popular phone that will attract developers such as cyan, maxisma, jac, manup and everyone else. My best guess and hope is that it will be a snapdragon android handset, hopefully for T-Mobile USA.
What we'll end up having to do is pick our phones based on it's community support and what kind of home brew is available for it.
The reason I love the G1 is the fact that it's rooted and has a large community. This phone is the best on the market, all things considered, because the rooted OS allows so much.
If and when the Droid is rooted, when a GSM version is released, and when it has T-Mo's 3G bands, I will move to it. But all those may not happen for another year or more. If you haven't played with a Droid yet, do so. Incredible speed and the best screen I have ever seen on a phone. Till then, G1 all the way.
The man is right, we have a problem on the dev side.
I think though, once 2.0 gets standard, we'll only need root for a few things like tethering and setting the CPU clock. Really cyanogen's only advantage is optimization, but once 2.0 and snapdragon rolls around, who cares? We'll always want to tinker, but it won't eclipse getting the phone you want.
The big problems right now are that the market isn't getting what it needs. Nothing compares to the HTC widgets, yet instead of cloning them on the market, we try and run a ROM that doesn't even work on our phones! We still don't have BT in Hero and it may just never happen.
2.0 will be what we need as a base, but the market needs our help now.
I'd contest the cyanogen are the best rom's.. maybe for someoen who wants to flash an upgrade every 3 days.. but for the majority of users.. Dwang is the way to go. Lengthy discussion about this, is over here..
alec.baldwin said:
I'd contest the cyanogen are the best rom's.. maybe for someoen who wants to flash an upgrade every 3 days.. but for the majority of users.. Dwang is the way to go. Lengthy discussion about this, is over here..
Click to expand...
Click to collapse
Thanks but this thread is not about who has the best rom.
The point is, when you get a new Android phone, your rom of choice won't be available for it. So what do you do?
alec.baldwin said:
I'd contest the cyanogen are the best rom's.. maybe for someoen who wants to flash an upgrade every 3 days.. but for the majority of users.. Dwang is the way to go. Lengthy discussion about this, is over here..
Click to expand...
Click to collapse
I think we all get it already, YOU are dwang's biggest fan
But, to stay on topic. My G1 is the first HTC device I've ever owned and I've only discovered XDA since I've had it, and I think that because of the community involvement here and the custom roms that have come out, I will definitely lean towards another HTC phone when I look for my next upgrade, and it will definately be an android phone.
Also another thing to look at is the availability of the phones that are out to actual dev's. Unless people are donating phones, I doubt everyone can just run out and pick up all the latest devices, and network restrictions/preferences that come along with them.
I think the easiest solution is as follows:
1. Find the dev you like best.
2. Find the phone you like best.
3. Buy phone you like best.
4. Buy/Create a donate link to get said dev the same phone.
Assuming said dev doesnt turn around and craigslist the phone you bought him/her, you have (hopefully) ensured said dev will migrate and develop on your favorite hardware.
Not the best solution but probably the most reliable.
alec.baldwin said:
I'd contest the cyanogen are the best rom's.. maybe for someoen who wants to flash an upgrade every 3 days.. but for the majority of users.. Dwang is the way to go. Lengthy discussion about this, is over here..
Click to expand...
Click to collapse
Seriously dude, are you going to diss me in every thread? What do you even contribute to this community? I've not received any patches or even logs of the "problems" you claim.
cyanogen said:
Seriously dude, are you going to diss me in every thread? What do you even contribute to this community? I've not received any patches or even logs of the "problems" you claim.
Click to expand...
Click to collapse
For real.
Alec, you're like the little annoying brother that no one wants to be around.
Grow up, let your balls drop, and enjoy your phone, your life, and whatever rom you want.
But, you don't have to go around dissing well-respected devs.
The Droid hasn't been out long enough for a community to gather around it. Many of the Android big names are waiting to get GSM versions before tinkering.
Also, remember that the HTC Dream was in circulation well before it launched last year. The Android development phone is identical to the Dream, with the only difference being some swish art on the back cover. The hardware and software were free-flowing long before it landed in our hands. In contrast, the Droid was a much more secretive launch; we've only just got Eclair source code, and the SDK was kept under wraps by a non-disclosure agreement (probably to conceal the nuclear bomb that is Google Maps Navigation).
I find the cracking of the Droid to be inevitable. The poor thing is going to be broken just as much as our Dreams were. Just give it time.
As for ROMs being available over a span of phones, I'm not sure that's even a good idea. Android variants like XROM, cyanogenmod, The Dude's ROM, yadda yadda... they're all about maximising the capabilities of the Dream. Not the Droid, the Dream. Adding in features that the hardware can support, changing CPU frequencies, Apps2SD, all that jazz. Droid ROMs will be built around adding in core features, like Apps2SD, and whatever else the Droid has tucked away. Likewise, speed optimisations may not be portable between phones, as what gives the Dream a boost may hinder the Droid.
For me, features of a ROM are not the best part of homebrew Android builds. The best part is being able to upgrade your phone outside of the carrier's say-so. If T-mobile have no plans to push Eclair to Dreams, I will install it myself. I am not tied down by the say-so of a room full of suits three thousand miles away. If T-mobile don't include an app that I like, such as the IM app or the Amazon MP3 store (which T-mobile UK don't), I can get ROMs with them myself. If a carrier would rather I didn't tether without paying for my bandwidth twice, I can do it anyway, so long as I'm not an idiot.
You may have guessed that I have a very dim view of cell carriers.
With root, we are free to do as we like. This is the real killer feature of homebrew, and the Droid will benefit from it too.
Anyway...
dwang said:
I want to acknowledge cyanogen, daproy, cyrowski, loccy, and alla for their contributions to the android community.
Click to expand...
Click to collapse
It seems dwang himself has a much higher opinion of the man than a certain other someone.
AthlonBoy said:
The Droid hasn't been out long enough for a community to gather around it. Many of the Android big names are waiting to get GSM versions before tinkering.
Also, remember that the HTC Dream was in circulation well before it launched last year. The Android development phone is identical to the Dream, with the only difference being some swish art on the back cover. The hardware and software were free-flowing long before it landed in our hands. In contrast, the Droid was a much more secretive launch; we've only just got Eclair source code, and the SDK was kept under wraps by a non-disclosure agreement (probably to conceal the nuclear bomb that is Google Maps Navigation).
I find the cracking of the Droid to be inevitable. The poor thing is going to be broken just as much as our Dreams were. Just give it time.
As for ROMs being available over a span of phones, I'm not sure that's even a good idea. Android variants like XROM, cyanogenmod, The Dude's ROM, yadda yadda... they're all about maximising the capabilities of the Dream. Not the Droid, the Dream. Adding in features that the hardware can support, changing CPU frequencies, Apps2SD, all that jazz. Droid ROMs will be built around adding in core features, like Apps2SD, and whatever else the Droid has tucked away. Likewise, speed optimisations may not be portable between phones, as what gives the Dream a boost may hinder the Droid.
For me, features of a ROM are not the best part of homebrew Android builds. The best part is being able to upgrade your phone outside of the carrier's say-so. If T-mobile have no plans to push Eclair to Dreams, I will install it myself. I am not tied down by the say-so of a room full of suits three thousand miles away. If T-mobile don't include an app that I like, such as the IM app or the Amazon MP3 store (which T-mobile UK don't), I can get ROMs with them myself. If a carrier would rather I didn't tether without paying for my bandwidth twice, I can do it anyway, so long as I'm not an idiot.
You may have guessed that I have a very dim view of cell carriers.
With root, we are free to do as we like. This is the real killer feature of homebrew, and the Droid will benefit from it too.
Anyway...
It seems dwang himself has a much higher opinion of the man than a certain other someone.
Click to expand...
Click to collapse
You seem to have almost got my point but not quite. Of coarse DOID doesn't need Cyanogen MOD specifically. But would you buy an Android phone if there weren't a mod that lets it do the things that we are used to and have only become available by modding? Apps to SD, tethering, themeing?
Sure DROID might get all these things though a custom rom but we won't see it on this website. The problem is that things will get too spread out and hard to find with all these new hardware options.
What would be nice is a rom that works on nearly every Android device that just adds root access to the phone and some basic universal packages like A2SD and tethering etc. That way you can buy any Android device you want and still have these basic privileges.
Do you think something like that would be possible?
Pinesal said:
You seem to have almost got my point but not quite. Of coarse DOID doesn't need Cyanogen MOD specifically. But would you buy an Android phone if there weren't a mod that lets it do the things that we are used to and have only become available by modding? Apps to SD, tethering, themeing?
Sure DROID might get all these things though a custom rom but we won't see it on this website. The problem is that things will get too spread out and hard to find with all these new hardware options.
What would be nice is a rom that works on nearly every Android device that just adds root access to the phone and some basic universal packages like A2SD and tethering etc. That way you can buy any Android device you want and still have these basic privileges.
Do you think something like that would be possible?
Click to expand...
Click to collapse
Beats me, man. I'm not a developer. But I think it's unlikely.
For the DROID (and other/future android phones) is Apps2SD really necessary? The only reason why we need it on our phones is because of the pathetic amount of internal space the G1 has, the same goes for Swap Partitions etc.
As long as people buy the phone there is always going to be someone who is smart enough to work on rooting it IMO. And even without root what do you really lose? The only things I think I would really miss are Wireless Tether and Bluetooth File Transfer (Which I THINK is in 2.0 anyway).
I'm not buying a new phone until it's rooted and Cyanogen has it too.
My biggest requirement for any android phone..and any cell phone in general is the keyboard. I bought the G1 because of the keyboard and lucked out with the high number of developers available for it. I didn't find this place for several months during the time when the grandfather of the G1 mod program was still active =) JF!. I enjoyed all the modding and updating because I personally feel that the phone is, well mine. And I should be able to do what ever I want with it. I had picked up the V3C Razer because it could play MP3's. I get it home and then discover that the Verizon Nazi's completely locked down that feature so you where forced to use their service at an additional cost. Of course the motorola dev/repair/store software allowed us to get in a enable the various features that Verizon required to be locked. I also love the Aps2sd. No matter what phone you have, the internal memory will never be enough. And with the Cliq supporting 32gig sd cards, a full keyboard, and NOT verizon was enough for me. I'm patient and confident it will be rooted eventually. If not, I still have my G1 and I still do Cyanogen updates and play around with it. And when my contract is up with Tmob(renewed for the Cliq), I'll see who has the next most popular rooted phone with a keyboard and switch over. I just really hate people telling me how to use a device I own. Its like going to McDonalds and having them dictate what condiments to put on my BigMac and Fries, and then telling me I can only eat it a certain way and which hand to use. If Cyanogen was down with the Cliq, or interested in it. I may be willing to ship him my phone to see what he can come up with.
As far as a universal O/S for all phones, isn't that just the core Android software with specific drivers provided by each manufacturer and custom UI? There should be a way to make 1 O/S for all android phones, then have update packs with the drivers and UI enhancements and add-ons for each android phone released? Not sure of the SPL locks though. Thats a bit beyond me. But i wouldn't think it would be to hard to run Cyanogen on the Cliq or droid provided the correct drivers and such where bundled with it. Kind of like slipstreaming a service pack into a bootleg Windows OS . Each phone eventually has to release the source code which contains the drivers for that phone. Thats how we get the Cliq's OS onto the G1, should work the other way around too. Sounds easy, but Cyanogen's Rom should run on my Cliq, provided the drivers are slipstreamed into it for the Cliq...right? Only problem is root.. :/ hehehe
and there he flames again...alec.baldwin, no one has the problems you have with cyanogen's latest. actually, lets delve into this...what exactly are your "problems" with 4.2.5? PLEASE, answer this question so cyanogen can dutifully fix the "problems" you are having.
You might check out some of the Q/A threads to first learn how to properly flash cyanogen's ROM. It is slightly different than Dwang's because Cyanogen uses the legal method. In fact, check out www.cyanogenmod.com and you might find a ton of useful info on getting cm to work on your phone.
Best of Luck,
njuncos
P.S. Cyanogen, mad props on once again reaching over a million thread views on your latest. Now you own 3 of the top 4 most viewed threads of all time in Dream Android Development!
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
I'm hoping somebody will be able to educate me a bit here on some deep technical questions. I've been searching for some information on this topic for a while now but without any luck. In a nutshell what I am curious about is this.. if I were to, lets say, build my own new handset, what would be entailed in getting android to work on it?
I know a kernel must be built with all the drivers and modules to communicate with any specific hardware/radios etc. But once you've got the kernel, is there still more porting that has to be done in the core android code? Are there significant CPU architectural differences or some other major differences between handsets that require more porting within the rest of the OS code? (Side question: if I want to build a kernel from source, what tools do I need)
To ask my question more specifically with the Epic, what is going to be necessary to get Gingerbread on it? If we already have the source for Eclair, or when we get the source for Froyo on the Epic.. what is it that makes it more than just a matter of pulling the drivers from those versions to make things work. Is android not built in a modular enough way to enable that?
I am myself a developer, but as I'm sure is obvious from my questions.. I'm not very experienced at OS level development. And what limited knowledge I do have mainly comes from making correlations to desktop OS, which is probably what is leading me astray.
I'm just really craving to know more about this stuff, so thanks ahead of time to anyone who takes their time to school me and help me understand. If there is any material out there that I should just go RTFM, I'd like to do that but please point me in the right direction.
Thanks!
FYI, your post/s do not pertain to any direct development. They are just generalized questions that can be answered with a simple search.
See Here
Reported as belonging in Q&A/general.
The most difficult part is porting drivers (if they're not already part of the kernel mainline) and device-specific glue code to the new kernel base. This is difficult becuase (i) it's a fair amount of code, (ii) the kernel does not have a stable API, so the necessary changes may be somewhat far reaching, and (iii) bugs that crop up are often more difficult to pin down and fix than in userspace programs. It also doesn't help the matter that Samsung's portion of the kernel code is messy, buggy, and just generally not in a state that would make it easy to port over to a new tree.
The reason why we can't just port Eclair drivers to Froyo, or Froyo drivers to Gingerbread, is that there's a fair number of proprietary modules on the phone (LCD, WiMAX, the entire storage stack, etc.) to which we don't have the source code. These modules are compiled against a specific kernel minor version (e.g., 2.6.29 for Eclair) and won't load in Froyo or Gingerbread. The version number can be faked, but if there's any change in the module API, or in the "API" (which isn't even formally defined) of dependent kernel code, all bets are off.
In theory if there's any Galaxy S device with a Gingerbread release, it might be possible to get a limited-capability kernel up and running, depending on how much the proprietary drivers change across devices (hopefully not much). The Nexus S doesn't count though as Google replaced the entire proprietary flash stoage stack with a GPL-based one. While we might be able to get such running on Galaxy S hardware, it would be incompatible with the existing storage layer and would necessitate a full device flash. Not really something you want to do when an official update with a complete set of drivers is going to be made in the "near" future.
Aside from the kernel, you would have to modify the parts of the Android userland that interface with hardware specific components, for example the "4G" (WiMAX) settings menu and such. I think much of the modem interaction also happens in userland. Then you have to port over whatever custom skin (e.g., TouchWiz) you have.
For some reason this is often believed to be the most difficult and time consuming part of a port, i.e., it's commonly complained that "HTC & Samsung delay releases to port Sense & TouchWiz, if they just dumped them and went AOSP updates would be a lot faster." Honestly it's not. It's an API update like any other Android app, and third party launchers don't seem to have significant problems here.
Mind you, I mention the difficulties of kernel porting without having actually attempted to do it myself, largely becuase it is so daunting. I know there's folks interested in doing this, and perhaps they have some tricks that make it a bit easier in a specific scenario. In general though, these are the difficulties one enounters when trying to port new Linux versions to any embedded platform.
I've often wondered this myself, as well as wondered why Google seemed to get caught with their pants down.
Now granted I don't know the nitty gritty details, but I don't understand why android wasn't written in a manner where as much of it as possible is just apps, and anything that is core is written where the handset makers just need to do the very low level stuff.
On top of that then it could have been made to be more easily themed, even rather dramatically.
Samsung/HTC should only be maintaining the low level "android wants the gps location, I know how to work this specific chip and give it back" and Sense/TouchWiz should just be a theme, and some custom widgets. Android itself should be virtually untouched between those two layers, and updates that don't change how it has to interact with the hardware or the themes should come straight from google.
Thankfully things have at least started to move this way. (you don't need to roll out a ROM update through sprint because Google updated the market like you used to, etc)
If Dell wants to customize Win 7 they add onto it, they don't roll their own copy of it, creating god knows how many fragmentation issues in the meantime. (And yes, I know Windows isn't open source, so they can't, but you get what I'm saying.) Because the second they did that they'd then take on a much larger QA burden, on top of everything else.
If android is untouched for the most part, it works, or it's a bug for everyone. You'd only need to test calls to your low level updates, which could for the most part be automated. The second you start changing a line here and there in the source code, now all of a sudden you have to do the "If I make a calendar item while on a call on a leap year the phone reboots" type QA/Support as well.
Edit: And of course it's very possible that is more or less how it is and the handset makers just flat out take longer to update then anyone imagined they would.
What language/s do you have to know to do all this?
nubsors said:
What language/s do you have to know to do all this?
Click to expand...
Click to collapse
C for kernel and Os. Java for apps(sdk). C and java(ndk/sdk) for apps that require native code implementations of things (eg. The VLC player that is coming. It wasn't possible until the latest edition of the ndk.)
Sent from my SPH-D700 using XDA App
Thank you mkasick for a great detailed answer. I didn't think about the fact there are closed source drivers to worry about as well, and that explains a lot.
@ghostrid3r: I did plenty of simple searches which did not answer my questions before posting, but thank you for the link. Also, not that it matters to me.. but is the development section just for releasing custom roms or something? If questions directly pertaining to development details don't belong there, seems to me the section should be renamed to "Epic 4G Custom Roms" instead.
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
So, let me start off by saying that I have searched, read and spent time trying to understand this... but still don't. Which answers why I'm posting this question.
First, what exactly is the reason that an AOSP rom is being developed and a Vanilla Froyo ROM is being developed?
Is the AOSP rom the important one here? Does the working AOSP rom with working kernel mean that we would have 2.2, 2.3.... and so on supported regardless of Samsung?
I understand that Samsung has not supported tremendously up to this point, I understand 2.2 has not been released for the CDMA version yet, and I understand the code they have released is "crappy." When I hear everyone talk about the great work the devs are doing, are they referring to mainly working on the AOSP? If this rom is built, will we be able to just keep developing it for the new versions of Android?
Sorta like in Back to the future when they break off the real timeline and go into the alternate 1985?
Samsungs Android - 2.1, 2.2.... EOL
Dev's Android - 2.1, AOSP, 2.2, 2.3?
Is this how it works? Basically just trying to understand what needs to happen for the Fascinate to get to at least 2.3... not WHEN or even IF it'll get to 2.3.
Thanks
AOSP means Android Open Source Platform.
It's a version of Android built entirely from sources provided by Google. It's completely Vanilla and comes with zero customer or manufacturer customizations. It's easily root-able, and able to be customized completely by the user if desired.
AOSP ROMs are desirable because they tend to be a bit faster and lighter due to their lack of crapification.
AOSP builds are only distributed in their complete and compiled form by Google for their developer handsets (Currently the Nexus One and Nexus S), and not by any carrier or manufacturer.
Okay, I appreciate that definition... I think I've gotten what AOSP is exactly... but I guess my question is does AOSP have any involvement in a future for this phone if Samsung decides to close its doors. Is a working AOSP, radio, kernel... whatever basically devs developing a future of this phone parallel to whatever Samsung does for it?
Like, I see from other threads that the ROM for Froyo and Gingerbread isn't necessarily the problem, its the radio and the RIL? If that is the case, what needs to happen for everything to figured out and for us to have a bright future for the Fascinate? Samsung has to release code for the RIL and radio? Are we SOL without Samsung helping here or will the devs definitely figure something out to get 2.2, 2.3... and so on for the Fascinate?
Bwangster12 said:
Okay, I appreciate that definition... I think I've gotten what AOSP is exactly... but I guess my question is does AOSP have any involvement in a future for this phone if Samsung decides to close its doors. Is a working AOSP, radio, kernel... whatever basically devs developing a future of this phone parallel to whatever Samsung does for it?
Like, I see from other threads that the ROM for Froyo and Gingerbread isn't necessarily the problem, its the radio and the RIL? If that is the case, what needs to happen for everything to figured out and for us to have a bright future for the Fascinate? Samsung has to release code for the RIL and radio? Are we SOL without Samsung helping here or will the devs definitely figure something out to get 2.2, 2.3... and so on for the Fascinate?
Click to expand...
Click to collapse
It's kinda like building an office park, or strip mall or something. You toss up the basic vanilla buildings, and when it's finally done, companies move in and tweak it how they deem fit.
With a working ASOP build, it'll remove some of the shackles of Samsungs bs code.
So... the AOSP build IS THE KEY here? I understand it isn't working yet, but if the devs get AOSP working, does that mean we will get a 2.2, 2.3 and so on regardless of what is released by Samsung?
I'm just trying to figure out what is happening to keep the G1, Droid, Droid 2... supported by ROMs like Cyanogenmod and others, that hasn't happened yet for the Samsung Fascinate.
I'd like to get the Fascinate, but am sorta waiting because I don't wanna be stuck with a phone for the next 2 years that will max out at MAYBE 2.2 if we are lucky.
I don't know where to start with your confusion.
Samsung has not given 2.2 to us. This means that we do not have froyo...
The RIL is an interface layer between the os and the radio. I'm not too sure about it, but anyways...
The developers are working around the fact that samsung has not given further tools that they need to get froyo ported over. Currently they are working on a 1.6 RIL to get froyo working. On another note, vanilla aosp is a good thing because it gives developers more freedom to customize the roms. It also allows for them to be able to port over other roms.
I really don't understand your confusion. If you want a better explanation , I recommend getting on irc.
If I were you, I'd wait. Next gen phones are coming from vzw in the next few months which will essentially blow the existing tech soon.
Bwangster12 said:
So... the AOSP build IS THE KEY here? I understand it isn't working yet, but if the devs get AOSP working, does that mean we will get a 2.2, 2.3 and so on regardless of what is released by Samsung?
I'm just trying to figure out what is happening to keep the G1, Droid, Droid 2... supported by ROMs like Cyanogenmod and others, that hasn't happened yet for the Samsung Fascinate.
I'd like to get the Fascinate, but am sorta waiting because I don't wanna be stuck with a phone for the next 2 years that will max out at MAYBE 2.2 if we are lucky.
Click to expand...
Click to collapse
Basically, that's the hope at least. If there are changes in say, 2.4 that require something that couldn't be hacked around with ASOP, we'll be stuck waiting for Samsung. But with a working ASOP, the groundwork is laid for updates to be ported over a bit more quickly by the devs.
Regardless of the future of this device, the Fascinate is one of the better Android handsets on the market. The screen is brilliant, it's the perfect size, and it's damn fast. The only thing that drags it down is the factory setup (although I personally think it's idiotic to ding the phone because of the inclusion of Bing like some people/reviewers have.)
I'm trying to understand what is going on instead of being one of the millions to ask about updates for this phone. I see phones like the droid series and read that they basically are being supported forever and then I see the Samsung Fascinate, and while I understand that the code is crappy/not released to community... I'm trying to figure out what needs to happen for it to be a supported device like the droids have been.
Bottom line, nothing at all is going to happen unless Samsung releases more than just a 2.2 update? If I see 2.2 drop like tomorrow, does that mean anything for a future, or is it just 2.2 update and we will just get devs releasing their versions of 2.2 roms?
RacerXFD said:
I really don't understand your confusion. If you want a better explanation , I recommend getting on irc.
Click to expand...
Click to collapse
I read his questions as:
"Will a working ASOP build mean better developer support/faster developer released updates?"
I did skim them though.
RacerXFD said:
If I were you, I'd wait. Next gen phones are coming from vzw in the next few months which will essentially blow the existing tech soon.
Click to expand...
Click to collapse
This is a good point. There's an LTE Samsung handset coming out soon, so it might be worth holding out for a little.
Although the Fascinate is no slouch.
Pretty much what I am asking. Like of everything that could possibly happen, Samsung releasing 2.2, AOSP being finished, blah blah what is the key that a consumer should look for to say...
"Well, now the Fascinate has no negatives to it and I have no fear that in a year, we won't still be stuck on 2.1 or 2.2 because Samsung screwed us."
Doesn't necessarily seem like Samsung needs to do MUCH to future this phones life and turn over the keys to the devs (like HTC seemingly has done), but I'm trying to understand what that thing is they need to do. Release a newer kernel, RIL, 2.2 ROM, some code that magically allows devs to port over future roms eternally...
I don't think I care if the phone has LTE capability. I won't get LTE and a regular 3G phone is beyond enough for me. LTE is zero impact for me.
Bwangster12 said:
Pretty much what I am asking. Like of everything that could possibly happen, Samsung releasing 2.2, AOSP being finished, blah blah what is the key that a consumer should look for to say...
"Well, now the Fascinate has no negatives to it and I have no fear that in a year, we won't still be stuck on 2.1 or 2.2 because Samsung screwed us."
Doesn't necessarily seem like Samsung needs to do MUCH to future this phones life and turn over the keys to the devs, but I'm trying to understand what that thing is they need to do. Release a newer kernel, RIL, 2.2 ROM, some code that magically allows devs to port over future roms eternally...
I don't think I care if the phone has LTE capability. I won't get LTE and a regular 3G phone is beyond enough for me. LTE is zero impact for me.
Click to expand...
Click to collapse
What does SAMSUNG need to do? Release their source code, and not just incomplete parts of it.
Will that happen? I doubt it, but it might. Clearly the companies ears are perking up with all the yelling by the consumers.
What can we do in the meantime? Support the devs and wait for them to crank out a working ASOP build and Froyo.
Yes, would be nice to have a fully working AOSP build, and then Froyo... but they are seperate from each other right?
AOSP build is being done for 2.1? It can't just be magically updated to 2.2 can it? Does Froyo have to be officially released for them to update it to AOSP 2.2?
Basically... AOSP will only be updated to whatever version Samsung has released?
Bwangster12 said:
Yes, would be nice to have a fully working AOSP build, and then Froyo... but they are seperate from each other right?
Click to expand...
Click to collapse
No. Android Open Source Project means "Android" in general. It can be 2.1, 1.6, 2.3, whatever. The devs elected to start with 2.1.
AOSP build is being done for 2.1? It can't just be magically updated to 2.2 can it? Does Froyo have to be officially released for them to update it to AOSP 2.2?
Click to expand...
Click to collapse
If you've followed anything in the dev folders, clearly not. JT's "Vanilla" Froyo looks like an AOSP build.
Basically... AOSP will only be updated to whatever version Samsung has released?
Click to expand...
Click to collapse
No. At least not our version.
Bwangster12 said:
Yes, would be nice to have a fully working AOSP build, and then Froyo... but they are seperate from each other right?
Click to expand...
Click to collapse
It's hard to answer your question because AOSP and Froyo refer to two completely different things, which can be the same or separate.
AOSP is basically Android, built from clean, unmodified source code directly from Google, without any changes by carriers or manufacturer.
Froyo is simply the 2.2 version of Android.
So, you can have Froyo that's modified by a carrier and/or manufacturer. This wouldn't be AOSP. And you can have Froyo, built directly from Google code. This would be AOSP. You can also have Eclair (Android 2.1), or any other version of Android that's AOSP or not AOSP depending on whether it was built directly from Google code, or modified by a carrier or manufacturer.
AOSP doesn't refer to a single, particular version of Android, but the state of the code that was used to compile whatever version you want to talk about.
Bwangster12 said:
AOSP build is being done for 2.1? It can't just be magically updated to 2.2 can it? Does Froyo have to be officially released for them to update it to AOSP 2.2?
Click to expand...
Click to collapse
A lot of the issue surrounds the kernel. When Google releases a new version of Android, it runs on a particular version of the kernel, which supports it's particular features. Manufacturers have to modify the kernel to support their particular hardware. So, since Samsung has only released source code for the kernel for Android 2.1, we're stuck on 2.1.
The versions of 2.2 from Kaos and JT are running on the Android 2.1 kernel that's been hacked to enable 2.2 to boot and run correctly. It works, but it's far, far from ideal. It doubles (if not more) the amount of work necessary to get 2.2 running, which is the reason for the rather slow pace of development.
So for your question, once Samsung releases 2.2 (the system and kernel), it'll be much easier to get an AOSP build of Android running, since the devs will only need to worry about the system instead of hacking together a kernel and RIL (radio interface layer) as well.
At least this is my understanding of the situation. I'm sure people with more knowledge and experience can correct me where I'm wrong, but I think this is the basic gist of it.
ChrisDDD said:
It's hard to answer your question because AOSP and Froyo refer to two completely different things, which can be the same or separate.
AOSP is basically Android, built from clean, unmodified source code directly from Google, without any changes by carriers or manufacturer.
Froyo is simply the 2.2 version of Android.
So, you can have Froyo that's modified by a carrier and/or manufacturer. This wouldn't be AOSP. And you can have Froyo, built directly from Google code. This would be AOSP. You can also have Eclair (Android 2.1), or any other version of Android that's AOSP or not AOSP depending on whether it was built directly from Google code, or modified by a carrier or manufacturer.
AOSP doesn't refer to a single, particular version of Android, but the state of the code that was used to compile whatever version you want to talk about.
A lot of the issue surrounds the kernel. When Google releases a new version of Android, it runs on a particular version of the kernel, which supports it's particular features. Manufacturers have to modify the kernel to support their particular hardware. So, since Samsung has only released source code for the kernel for Android 2.1, we're stuck on 2.1.
The versions of 2.2 from Kaos and JT are running on the Android 2.1 kernel that's been hacked to enable 2.2 to boot and run correctly. It works, but it's far, far from ideal. It doubles (if not more) the amount of work necessary to get 2.2 running, which is the reason for the rather slow pace of development.
So for your question, once Samsung releases 2.2 (the system and kernel), it'll be much easier to get an AOSP build of Android running, since the devs will only need to worry about the system instead of hacking together a kernel and RIL (radio interface layer) as well.
At least this is my understanding of the situation. I'm sure people with more knowledge and experience can correct me where I'm wrong, but I think this is the basic gist of it.
Click to expand...
Click to collapse
Okay, thank you for this answer... this makes sense to me.
So, have HTC and Motorola released newer kernels for the devs of roms like Cyanogemod to update their ROMs, despite HTC and Motorola not actually releasing newer versions? I mean, how is the G1 updated as far as it has. Did HTC release a 2.2 kernel to allow devs to put 2.2 on it?
That's were I'm start confused as well.
I understand that Samsung has some proprietary kernel level code and drivers.
But, I'm curious what is the difference between Linux kernel versions used for different versions of Android. It doesn't sound like major version change and hence should not change anything dramatically. It should be mostly bug fixes. That's why jt was able to get kernel work.
As in relation to ASOP for SF, I see it like attempt to adapt Samsung code to current android interfaces. Once again, these interfaces should not change dramatically between versions, because these are evolutionary. So, I assume when done it is pretty much paved road up to 3.0 at least. That said some new features might not work at all, because we do not have working initial binaries from Samsung.
By the way mrbirdman has GB in progress.
Alright... so this may sound like I'm oversimplifying it, but I don't mean to.
Why can't the dev community just create a "custom" kernel to work with their versions of 2.2, 2.3 and so on? You say that they are working to hack the 2.1 kernel Samsung has released so it allows 2.2 to run on the Fascinate... but why can't they just make a 2.2 kernel? Is that sorta what Cyanogenmod is doing to get a 2.2 Froyo build to work on a G1?
Based on the amazing things I've seen the dev community do, building ROMs from scratch, I guess I don't understand how the kernel can't be built specifically for each new version... forgetting about what Samsung releases.
Bwangster12 said:
Why can't the dev community just create a "custom" kernel to work with their versions of 2.2, 2.3 and so on?
Click to expand...
Click to collapse
Theoretically they could, it would just be a lot of work. Hardware drivers might not be compatible with the kernel version designed for 2.2 or 2.3. I don't think manufacturers are required to release the code for their drivers, so if a driver wouldn't work, one would need to be written from scratch, and without the detailed knowledge of the hardware itself, that is very difficult.
Hardware support is very integral to the kernel, so a kernel for one phone wouldn't run at all on another. So in addition to the difficulty of putting together a totally independent kernel, it would need to be done separately for each and every phone out there, and how many versions of the Galaxy S alone are there? How many HTC phones, how many Motorola and LG and Sony and so on.
It's just not realistic for people doing this, essentially, in their spare time.
So, what the devs generally do is wait until a carrier releases a version of Android (System, kernel, radio, etc.), and with all the hardware support in place and working, they can focus on building custom or AOSP versions of the system.
It's not that they couldn't build their own kernel, it's just a matter of practicality, audience and the shelf live of the particular phone. As it is, a new generation of phones are already either coming out or on the near horizon... and our phone is what, 4 to 5 months old?
Bwangster12 said:
Based on the amazing things I've seen the dev community do, building ROMs from scratch, I guess I don't understand how the kernel can't be built specifically for each new version... forgetting about what Samsung releases.
Click to expand...
Click to collapse
The misunderstanding is in the complexity of compiling a custom system, and developing a custom kernel. They are hugely different in terms of complexity.
Think of a ROM as taking Windows 3.1 and simply tweaking the components that are installed by default - what accessories are installed, what wallpaper is selected, the color scheme of the windows. Not terribly complicated.
Think of the kernel as having to compile DOS, complete with custom drivers for all the hardware - CPU, graphics, memory, storage, multitouch, sound, radio, modem, WiFi, networking, power management, USB support, file system support, etc. all by hand.