Root [ROM][WIP] CyanogenMod 7 | Android 2.3.5 | Last Version: CM7-Triumph-09182011 (discontinued)

[b_randon14]

Is mmcblk0p5 the partition that contains s the boot.img and recovery.img. the one that gets mounted when you go into download mode?

 

[isaacj87]

I tried rebuilding this morning and what I got built properly but won't boot - it locks on the splash screen and never gets up far enough to be able to connect to it (e.g. the kernel never starts.)

I'll give it another shot.

If it's getting to the boot splash, then it booted the kernel. Check ADB logcat to see what it's failing on. More likely than not, it's the libcameraservice failing to load libcamera. I'll see what I can do about that later.

I'm in talks with the guy that's working on the OV CM7 port. He's throwing some ideas my way, so hopefully we can hammer this thing out.

@b_randon14: No, mmcblk0p1

 

[tickerguy]

No what I had before hung on my custom splash never got the kernel splash. What I get now won't build, blows up in the camera libraries, so at present I can't build at all.

It fails here:

target Non-prelinked: logwrapper (out/target/product/triumph/symbols/system/bin/logwrapper)
target Non-prelinked: lsof (out/target/product/triumph/symbols/system/bin/lsof)
Copy: out/target/product/triumph/obj/lib/libaudio.so
target SharedLib: libcameraservice (out/target/product/triumph/obj/SHARED_LIBRARIES/libcameraservice_intermediates/LINKED/libcameraservice.so)
prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3/../../../../arm-eabi/bin/ld: out/target/product/triumph/obj/SHARED_LIBRARIES/libcameraservice_intermediates/CameraService.o: in function HAL_openCameraHardware:frameworks/base/services/camera/libcameraservice/CameraService.cpp:1530: error: undefined reference to 'openCameraHardware'
collect2: ld returned 1 exit status
make: *** [out/target/product/triumph/obj/SHARED_LIBRARIES/libcameraservice_intermediates/LINKED/libcameraservice.so] Error 1
make: *** Waiting for unfinished jobs....
karl@ubuntu:~/android/system$

 

[tickerguy]

Ratsa fratsa......

karl@ubuntu:~/android/system$ repo sync -j16
Fetching projects:  99% (282/284)  remote: fatal: failed to read object c0f30688df7152202b032f5809b6b52d842ae09f: Invalid argument
remote: aborting due to possible repository corruption on the remote side.
fatal: protocol error: bad pack header
error: Cannot fetch platform/sdk
error: Exited sync due to fetch errors
karl@ubuntu:~/android/system$

 

[tickerguy]

Repository is working again..... back on it.

 

[tickerguy]

I need to know how to decompile one of the java framework components in the base Triumph code. I need to know what the correct return values are for two upcalls and if there's a function that has to be attached to them. This is what's blowing up the phone code and is likely what's blowing up the rest of the stack.

I'm going to block the failures which should prevent the crash, but if there's an outbound call that has to be made on receipt of those (and there may well be) all that will do is stop the crashes - so that is now "critical path" in terms of what I'm looking at.

I understand there's a way to do it, but don't know the process; anyone who can help with that will be GREATLY appreciated.

Isaac, I know you have PMs turned off but mine are on. If you PM me an email address I'll toss you what I found, if you think it will be helpful. More in a bit - recompiling with the black-out on those two calls now.

 

[tickerguy]

Hmmmmm...

D/RILJ ( 1191): [UNSL]< UNSOL_RESPONSE_CDMA_NEW_SMS

Ok, that's definitely coming up quite a bit further with the fails blocked - de-compiling that part of the framework and patching that in now very much appears to be critical, as with the blowup patched it is continually making the upcall request - strongly implying the radio code NEEDS the callback to be properly handled.

apktool blows up on the framework-res.apk file from the base load, incidentally.

What I'm looking for is a way to reverse engineer what's was ORIGINALLY in frameworks/base/telephony/java/com/android/internal/telephony on the Triumph Froyo load - specifically, the file RIL.java.

There's one more crash I need to investigate and see if I can at least patch around - the phone apk blows up even though I got rid of the RIL crashes in the framework. The framework is now stable although not responding to those two upcalls. I don't think phone.apk blowing would prevent the stack from coming up although I could be wrong about that - so I'll chase that one down in the next couple of days with logcat and patch it out too, and then we'll see where we are. I believe, however, due to the rapid repetition of the upcall on the state change that the message HAS TO be ACK'd in some fashion by the upstream code in order to confirm the state change, and that has a high probability of being why the phone is not showing "online" and available.

I suspect that replicating those upcalls is odds-on for bringing the radio stack to an operational state.

 

[tickerguy]

Ok, some more information..... transplanting the Phone.apk and Phone.odex stops the blowups in the phone code. I can get into the dialer screen but can't do anything (it faults in acore, so there are dependencies as I would expect.)

However - the radio stack doesn't come up - at all - with the transplant.

It appears we need that decompile to put the proper handler in the file as noted above, and then we will probably have to chase down the interconnections with the phone APK, if any, that are necessary too.

I'm digging around for a way to reverse-engineer the source for that JAVA.ril file out of the original Triumph load, as that's the obvious sticking point at present. Anyone who has a handle on decompiling that bad boy would be contributing in a big way to getting this pig going.

 

[rockneo]

Keep going ticker, you'll figure it out.

 

[tickerguy]

Serious progress being made here..... got the decompiled original in smali and there's a bunch of surprises in there; this may take a while, but it's not an impossible job - if I can figure smali out.

 

[morak]

Serious progress being made here..... got the decompiled original in smali and there's a bunch of surprises in there; this may take a while, but it's not an impossible job - if I can figure smali out.

tickerguy - Strangely enough, I was just playing around with decompiling android packages (apk, dex, odex) the otherday. So, I extracted/processed/converted framework(.jar/.odex) into .java files. Among other things, it includes RIL.java, which I think is what you're after. You can find it here: framework.src.zip. Hope this is useful.

 

[Triumphfeen]

I hope we get atleasy a working beta mod with service soon

 

[Android1993]

Don't know if you know this. Was too lazy to read through the entire post. I read something about the Open Source Software being released. Not sure if that has anything to do with the Kernel Source. Mind my little knowledge on this stuff.

 

[tickerguy]

Morak, I'll look at what you have this weekend - it may be pretty much or exactly what I have now too. I have figured out how to decompile the code, but unfortunately it doesn't understand the original class definitions and as such the structure is, shall we say, "interesting" and full of what are effectively register-level assignments and such. This is not going to be a lot of fun to pick through - in fact, at first blush it looks like a severe pain in the butt - but from my first-blush inspection there is definitely a set of parameters being picked up and a callback being made from the network state change opcode that I'm seeing coming up from the stack, so simply returning a void back is insufficient. That's exactly as I suspected given the fact that the radio stack keeps repeating the same upcall with no response going back to it, implying it really wants to see that response. The worse news is that the decompiling evidences a bunch of ADDITIONAL unsolicited upcalls that we've yet to see, and I have no idea how important THEY are to support as of yet. I suspect the answer, however, is "yes, those need to be handled too."

Here's the interesting thing - this should all be Sprint-generic, which means that in THEORY any other Sprint CDMA Android code should contain these definitions and upcalls. One thing I'm going to look for over the weekend is other Sprint CDMA Android source implementations that can be cribbed from, as that's probably going to be a materially faster path to success than reverse-engineering all the smali code back into .JAVA files with their respective class definitions by hand.

The Motorola code release is of no help as NONE of the framework modifications they made are included in it. That was mighty nice of them.

If someone has a Sprint-operational Android version in SOURCE (e.g. a git repository I can pull) that might well provide me with exactly what I need to fix this, and it will be a hell of a lot faster than trying to reverse-engineer register-level stuff back into the Java code that's in the repository now.

 

[Slug]

@Android1993: thanks for the heads-up but unfortunately the device-specific kernel source code is independent of the Android source.

 

[wsimon]

tickerguy - Strangely enough, I was just playing around with decompiling android packages (apk, dex, odex) the otherday. So, I extracted/processed/converted framework(.jar/.odex) into .java files. Among other things, it includes RIL.java, which I think is what you're after. You can find it here: framework.src.zip. Hope this is useful.

That looks helpful Morak- thanks for your contribution.

 

[compulady5]

@ Tickerguy

Perhaps one can be found on the web somewhere that I can pull it from? A stock backup from another dev maybe? Will that work for you?

 

[tickerguy]

@compulady, no, I can pull loads from XDA and such - that doesn't do me any good. I need access to a git repository for one in source form.

I'm working the other angle in the meantime through two paths. If I come up with something that actually works you'll see it here.

 

[tickerguy]

Argh - the .java files that are produced with the decompiler won't recompile; the problems include syntax errors in the declarations. That's a problem.

Ok, off to path #2.

Oh boy.. that decompiler appears to produce some.... interesting.... and rather invalid - code. Specifically, it appears to be mishandling both the finally and throw statements. This could get ugly trying to figure out what was intended originally...

Update: That's a dead end. On to the next attempt.

This is beginning to look a bit ugly.... there are two special-case sets of RIL code in the framework already - one for Samsungs and one for LGs. I suspect that talking to this pig is going to require either finding a similar piece for this phone and adapting it (not terrible IF we can find the base to work from) or writing one (a 5-alarm horror show without documentation on the internals of the radio stack - which we don't have, and given my rather-sketchy knowledge of Java, probably beyond a reasonable level of my effort working from decompiled object code that is more than a bit obfuscated and doesn't cleanly recompile.) Not giving up by a good long shot however - going to attempt a somewhat-different path and see where it leads.

 

[tickerguy]

DING DING DING DING incoming calls and SMS. No outbound yet, we still have a state problem where the radio "readiness" doesn't get passed up the stack properly so the phone still says "no service", NITZ works but the time zone does not come through correctly (time shows as GMT), and audio is still borked, but here's a WORKING radio that registers and upcalls properly for both inbound phone and text messages, and no more phone APK crashes either.

http://www.youtube.com/watch?v=Wu5maTCil8Y

 

[ziggy46]

sweet man! if i knew how to do that kind of stuff i would help you guys... but mostly im a themer. and i just started looking at how the framework-res is laid out in the triumph. cant wait to see it when its all done!

 

[tickerguy]

There's no "guide" on this one Zig - it's a matter of hacking the hell out of it - tracing things down, figuring out where you're getting blocked and what's blowing up and then working around it. I'm not real happy with the code I had to lay to make this work as it's totally unable to be integrated back into the base CM7 stuff and was a truly ugly hack due to the lack of conditionality and state from the radio upbound, but that's able to be worked around. The big deal right now is getting sound up and the radio state passed back; I haven't looked at the former but it appears Isaac is working on that - the latter looks to be quite a pain in the butt but it has to be figured out one way or another because outbound won't work without the system being aware of the fact that the radio is up. Once those two things are achieved then the basic functionality - phone, Wifi, etc - is all there.

 

[wsimon]

DING DING DING DING incoming calls and SMS. No outbound yet, we still have a state problem where the radio "readiness" doesn't get passed up the stack properly so the phone still says "no service", NITZ works but the time zone does not come through correctly (time shows as GMT), and audio is still borked, but here's a WORKING radio that registers and upcalls properly for both inbound phone and text messages, and no more phone APK crashes either.

Wow! Great Job Tickerguy!
How'd you do it- did you figure out how to recompile those .java files?

 

[tickerguy]

No, I hacked around the resets the code was forcing. It's not a complete solution by any means but it's a very important piece of information - the radio is working and as long as you don't bork it you can communicate with it. The phone code was screwing with it, basically - I traced that down and hacked it out. It's ugly but it gives me a critical piece of information, which is that we don't need to initialize it - it's coming up and running - we just had to stop hosing it!

The problem is that I need to figure out how to retrieve the radio's state from the state-change messages which are being upcalled and pass it correctly up the stack - they're one of those undocumented upcalls coming from the code. I ran into several dead ends trying to both splice in the other RIL code (forget it - there are dependencies all over the place AND the decompiler produces code that won't compile!) and replicate it - so I disabled the things in the framework that were breaking the radio and got it to talk. Now I need to figure out the upcalls and get the state to register in the phone software, and at that point we should have two-way communication and the status should show up properly. Once the audio is working those two things combined give us a working basic feature set. I have no clue if the phone code will run data and won't be able to figure that out until I can get the state passed up properly.

The NITZ problem with the time zone not coming through correctly is bothering me a great deal but that's a relatively minor issue and one I'm quite sure I can fix.

 

[rockneo]

Looks like the notification light is stuck on?