[G2 and Desire Z Android Development] ianmcquinn:
The "radio" being flashed is the driver/firmware interface for the hardware. By your reasoning, are you saying driver modifications/optimizations should never have any effect on performance since the actual hardware doesn't change? Obviously, this is not the case...

I also believe your thoughts on radio testing are flawed, at least a little. While RF signals do fluctuate, a steady difference in the reported signal level is indicative of something (regardless of the fact that the phone does not provide instant readings---this actually would provide rudimentary filtering of the numbers in the unlikely scenario where HTC wasn't already filtering the numbers). For instance, if there is a 10 dBm improvement in one radio versus another when the signal is monitored over a substantial period of time in the same location, this is statistically significant. Even if this was simply due to HTC deciding to recalibrate how the signal is reported, it may be important (not sure if the OS uses the reported signal level to determine whether or not to drop a call for example). While not an exact testing methodology, I don't think we should rule it all out as meaningless just because we don't fully understand what is going on.

I do agree with you that people shouldn't blindly flash new radios/libraries and expect everything to work (and that when reporting radio-related bugs, there probably should be some baseline standard---though if the ROM designers are using different radios, this is problematic as well), but I also think it's important to do this kind of testing to find out more (which to be fair, I don't think most people are doing). I wouldn't simply say "end of discussion" though and be so adamant that people stop completely. For example, "end of dicussion" would also imply that any phone not based on AOSP already shouldn't use an AOSP-based custom ROM like CM (since those phones will have only non-AOSP vendor-specific RILs). Just because you brought up some good points in your investigation does not mean others are incapable of figuring out more...

EDIT: For example, while not exactly scientific in nature, I just opened the libhtc_ril.so from the T-Mobile OTA ROM in a text editor and did a search for all screen-related text. Opening the libhtc_ril.so from a Sense-based ROM (specifically, the 26.04.02.17, 26.06.02.27, and 26.08.04.16 radios) yielded the same results (whether these be function names, variables, etc.). This would imply that HTC did not remove any of the screen-related functions from Sense-based builds (which makes sense since it is unlikely that HTC would build a different library of functions in their vendor-specific RIL just because they branded the phone for T-Mobile. It seems more likely that the same vendor RIL is used for all phones that contain this particular radio (in this case, meaning no differentiation between AOSP and Sense ROMs). From a development standpoint, this would be more cost-efficient. I actually thought that was the point of the vendor RIL to begin with---the Android SDK defines a common set of functions that are passed to the rild (which in turn talks to the vendor RIL). This means the vendor RIL must at least support that functionality (and AOSP ROMs wouldn't use any additional functions, so it seems like the all vendor RILs should support AOSP ROMs). Whether or not bugs may exist in any particular RIL is another completely separate story...

EDIT 2: I just pulled the libhtc_ril.so from "RUU_Vision_HTC_WWE_1.34.405.5_Radio_12.28b.60.140e_26.03.02.26_M_release_155556_signed" and it is indeed different than the one found in the T-Mobile OTA, so there goes my above theory. Both radio images are exactly the same. The Sense one is larger, so it might be a case of just added functionality, but that's just speculation until more work can be done (which unfortunately I don't really have time for now but maybe others can pick this investigation up).