Root So ... , who wants some Jellybeans?

[dsmryder]

For anybody interested, I fixed the liblights, all that was needed was a to remove the const from the module properties. So now we are not using any crutches, no more borrowed hwcomposer and no more prebuilt liblights.

Thanks to tilal6991 for posting here:
"Crash in liblights and can be fixed by removing the const in the declaration of the module properties in lights.c."
Whoa, cm10 builds for our liquid? - Acer Liquid - Liquid.MoDaCo.com - MoDaCo

That doesn't make sense to me. From the book that I have been reading on C++, const is for making a variable unchangeable. It's used as an internal data control method and to allow the compiler help in catching bugs. This presumes that the auther of the file did their work properly.

I wonder if the file's architechture was changed improperly and that's why the values were left marked as 'const'?

 

[BSydz]

That doesn't make sense to me. From the book that I have been reading on C++, const is for making a variable unchangeable. It's used as an internal data control method and to allow the compiler help in catching bugs. This presumes that the auther of the file did their work properly.

I wonder if the file's architechture was changed improperly and that's why the values were left marked as 'const'?

Don't really know, you know the boat I'm in. It worked though.



I found a nice lil logcat command that may help get data working though.

adb logcat -b radio

 

[BSydz]

I have gotten the errors in the radio log down to just this:
[HIGH][CdmaDCT] Data not allowed due to - RUIM not loaded[/HIGH]I am at a loss, I am gonna have to scan all the telephony code to figure out why it thinks it needs the RUIM card.

Also there seems to be an issue with the operator being changed after first reboot and after.

At first it will show this:
[HIGH]D/RILJ ( 971): [0031]< OPERATOR {111038, , 111038}
D/RILJ ( 971): [0032]< VOICE_REGISTRATION_STATE {1, null, null, 8, 757, 614768, -1217638, 0, 04126, 00005, 1, 1, 1, 0}
D/CDMA ( 971): [CdmaSST] Set CDMA Roaming Indicator to: 1. mCdmaRoaming = false, isPrlLoaded = true. namMatch = false , mIsInPrl = true, mRoamingIndicator = 1, mDefaultRoamingIndicator= 1
D/CDMA ( 971): [CdmaSST] pollStateDone: oldSS=[0 home Virgin Mobile 111038 EvDo-rev.0 CSS not supported 5 4126 RoamInd=1 DefRoamInd=1 EmergOnly=false] newSS=[0 home null 111038 EvDo-rev.A CSS not supported 5 4126 RoamInd=1 DefRoamInd=1 EmergOnly=false][/HIGH]After reboot and after it shows this:
[HIGH]D/RILJ ( 514): [0031]< OPERATOR {111038, , 111038}
D/RILJ ( 514): [0032]< VOICE_REGISTRATION_STATE {1, null, null, 8, 757, 614768, -1217638, 0, 04126, 00005, 1, 1, 1, 0}
D/CDMA ( 514): [CdmaSST] Set CDMA Roaming Indicator to: 1. mCdmaRoaming = false, isPrlLoaded = true. namMatch = false , mIsInPrl = true, mRoamingIndicator = 1, mDefaultRoamingIndicator= 1
D/CDMA ( 514): [CdmaSST] pollStateDone: oldSS=[0 home Roaming Indicator Off 111038 EvDo-rev.A CSS not supported 5 4126 RoamInd=1 DefRoamInd=1 EmergOnly=false] newSS=[0 home null 111038 EvDo-rev.A CSS not supported 5 4126 RoamInd=1 DefRoamInd=1 EmergOnly=false]
[/HIGH]Also this changes:

[HIGH]D/CDMA ( 695): [CdmaSST] shouldFixTimeZoneNow: retVal=true iccCard=com.android.internal.telephony.IccCard@2b8b06b8 iccCard.state=READY iccCardExist=true operatorNumeric=111038 mcc=111 prevOperatorNumeric=310053 prevMcc=310 needToFixTimeZone=true ltod=08-07 12:02:55.606
[/HIGH]
If anybody has any ideas feel free to post them.

 

[jr9306]

nvm

 

[Ken2Chill]

still being worked on?

 

[calitrippin]

I don't know if this is necessarily helpful, but I remembered an issue like this happening with every other version of android being put up on this phone so I did a little searching of the forums to find what was done about it and I found this from tickerguy.

Ok, here's the deal.

To get the RIL to come up you need to deal with the following problems:

1. The Qualcomm code likes to CLAIM it has a RUIM in it that is not ready. A RUIM is a SIM for CDMA phones, basically. The problem is that there is no socket for that in the phone at all -- in other words, it doesn't exist. This will cause the phone to be torn down and reset when it comes up the stack. Needless to say that's bad.

To fix this you have to change the base code. In CM7 I patched RIL.java around line 2020 with the radio state (look in ril.h for the defines) for State 2, and if the class is Triumph I change the state to RadioState.NV_READY instead of RadioState.SIM_NOT_READY.

This same code is in the ICS build and must be fixed.

2. In the routine processUnsolicited there are a number of upcalls that have to be there. It appears that ICS picked up all but one. Add that one (VOICE_RADIO_TECH_CHANGED)

3. RILConstants appears to be fixed, so you should be ok there.

4. cdma/CdmaServiceStateTracker.java has a BUNCH of changes that have to be pulled over. You're going to have to go through this code in the ICS tree as it looks materially different. One place I know you have to fix is in EVENT_POLL_STATE_CDMA_SUBSCRIPTION -- you need to add the code from my CM7 build that checks for a Triumph and if so DOES NOT attempt to pull the PRL from the upcall packet -- it's missing on the Triumph and if you reference that 5th element in the array the code will fault and blow up. What I did here temporarily was to stuff a "fake" PRL in the data table.

5. Same file, look at CASE_SIM_LOCKED_OR_ABSENT. This is one of those async upcalls that on the Triumph CANNOT be allowed to fall through to the next state (it does in the base code.) If it does, you're dead as the code then turns the radio off! This is generated from the RUIM message; see what I did in the CM7 build to fix this (basically ignore it if it's a Triumph)

6. The poll for the ACTUAL PRL is in the default case in this same statement. Again, see my CM7 code, same file, and look at the other PRL related changes to that same file (they're not in the ICS version at all.)

That should get the RIL to come up. You NEED all of the radio parameters (including the PRL, MEID and such) to load before Android will allow a data connection to start. Thus, all this has to be fixed for data to work.

Once you have that you get to have fun with MMS, which will also require patching......

There's probably more I'm missing but this should get you either working or damn close.

and this from yumbrad

As to what the issue was - in the end, as it usually is, it was pretty simple. Like the old joke about the guy getting paid for knowing *which* button to press

I began by porting in TG's changes. In the end, not all of these were necessary, and for ease of merging with ongoing CM9 development, I trimmed down to just what was needed: we need to ignore all the ICC (generic term for SIM/RUIM) stuff since this phone has no ICC, and handle the fact that the subscription info returned has only 4 elements, not 5 (and taking the PRL--normally the 5th element--from system properties).

At that point, it got further, and you can trace my previous posts to see how I decided to examine rild. I thought since rild was running and we had the same rild and qualcomm libril libraries, behavior should be the same so I was looking for some way in which they were configured differently. That led me to look at rmnet0, which the RIL was supposed to be bringing up in the step that errored. (Keep in mind that at each of these steps I'm doing lots of googling to get an overview of what people know - googling "SETUP_DATA_CALL," "rmnet0," etc..)

So rmnet0 is a kernel device driver, so that means code. Yay! But our kernels are the same, so I decided to look at the parameters (experience here).. That's when I saw the ETH/RAW_IP difference. That was a symptom, not a cause of the issue. Looking at the kernel source, I could see an ioctl (system call from userspace into the kernel) that would make that change, so (experience) I thought an strace would yield perhaps if the ioctl was failing or whatnot. The strace ended up yielding a lot ... I should have started there. What libraries/sockets/files rild opened up (especially with the -f option, which traces child processes that fork off). Then of course I saw the qmux_socket_connect opening failing that I mentioned.. more googling and looking at qmuxd, which should create that file. qmuxd must have died! It's started the same way in TG's and our init.qcom/triumph.rc ... Well, I tried in vain to get a dump of why qmuxd was dying - eventually, after looking closer at the ps I realized - duh, it's never starting. Then it clicked - the ps showed all the daemons in init.triumph.rc that had "class main" were running, and none that didn't. I went through adding "class main" to all the non-disabled services.

Then, with TG's changes and the class main changes, I got 3G flickering on and off. Traced that to a crazy version number in the log - I had turned off the datacall,signalstrength compatibility line at some point. Re-enabled that, and 3G was good. I just now pared down the changes to just what's needed, pushed them to my github, and sent mantera pull requests.

Hopefully this all will be useful/interesting to some. Like I said, often have to jump through a lot of investigative hoops to fix a silly simple problem One potential bonus - some of our other problems may stem from other daemons which weren't being started. Not sure why only class main now gets started in the vendor rc file.

not sure if it is any help but thought it might be worth looking at

 

[TheDigital_S]

still being worked on?

I'll second this. Inquiring minds would like to know.