Thanks TG! I had ported all of your changes, and ... I seem to have all of these as I double check. Maybe you have an idea why the radio is still not coming up - unfortunately, the closed RIL/baseband is returning an error when I finally get to issuing a "SETUP_DATA_CALL" request. I haven't gone byte-by-byte to examine what I send down, but that's what I was considering next - putting a hexdump in the lowest layer right when it gets sent down to the RIL in both a working CM7 and my CM9 - because the higher level "<" and ">" (in/out RIL request) messages seem to be the same at this point. In other words, I've got it behaving just like your CM7 code, but the RIL returns an error to SETUP_DATA_CALL. I even checked the various libril and rild binaries - the rild in my working gingerbread MIUI was a bit bigger, and I tried that, but same behavior.
Any ideas? Am I going to have to bite the bullet and go byte-by-byte?
I can think of three possibilities since the calls seem to be the same in TG's CM7 and ours:
1. There is some byte-level difference in the the RIL requests we send down before SETUP_DATA_CALL.
2. There is some important property difference that rild / the ril libraries (which are the same prebuilt ones) are picking up. I went through looking for ril/telephony related things that would matter in build.prop and I didn't think so, but something has to be causing rild to behave differently.
3. There is some *hidden* property that changed (i.e. a system property that wasn't set in CM7 or our CM9, but changed default values).
Unfortunately, these are now at the point where they are time consuming and painful to check out. I've got a day job and 4 kids
.. If someone wants to check out #1, they need to capture a "adb logcat -b radio \*:v > logfile.cm7" from a working CM7 and then do it again with our current build with my or programos (assuming he's got the fixes ported as I have) changes. But first, in both, you'd need to go to RIL.java and add something to dump out exactly what we are sending down to the RIL. At the point where it sends it down - s.getOutputStream().write(data) - at around line 340 or so - add a hexdump of the data. Here's a function to convert the "byte[] data" to a string, then just Log.v(LOG_TAG, stringReturnedFromThatFunction);
Code:
public static String byteArrayToHexString(byte[] b) {
StringBuffer sb = new StringBuffer(b.length * 2);
for (int i = 0; i < b.length; i++) {
int v = b[i] & 0xff;
if (v < 16) {
sb.append('0');
}
sb.append(Integer.toHexString(v));
}
return sb.toString().toUpperCase();
}
Then capture logs from both, and go through those hexdumps byte-by-byte, comparing. We'd need to figure out whether any differences are important.
#2, we could make EVERY thing the same, even the things that don't seem to matter, as long as thing still works. #3, somebody needs to google default properties, and figure out what changed from CM7/gingerbread to CM9/ICS.
will that work the same way with the phones if you can get it in a working order? if so this device may put the galaxy nexus in its place lol 
