[Hero CDMA General] maejrep:
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.