Cyanogen Mod 7 For Blade

[Guest sebbo90]

This is what I'm a little confused about, so other phones such as the desire can make a AOSP rom and have fullly functional ril even though it is closed source under qualcomm, yet we cannot on the blade :D Why did zte change so much of it to get ril to work? The htc legend is the same phone yet they build an AOSP

[Guest Afrodude]

What about the HTC Legend RIL? Would that not be compatible?

Not a chance.

[Guest MrHicks]

From my limited understanding, we shouldn't need the source code for the vendor specific library; we do need the properties/arguments that are required for the RIL Daemon to communicate with Qualcom's vendor RIL, which are probably in init.rc and possibly the various .prop files. Am I way off the mark?

[Guest fonix232]

From my limited understanding, we shouldn't need the source code for the vendor specific library; we do need the properties/arguments that are required for the RIL Daemon to communicate with Qualcom's vendor RIL, which are probably in init.rc and possibly the various .prop files. Am I way off the mark?

A bit right.

But, somewhy, ZTE changed the telephony framework too, that's why we can't simply change init.rc and the prop files, and let rild communicate with libril. Or at least, they can communicate, but the telephony framework will be unable to.

Looks like instead of changing the libril interface itself to suit AOSP, they varied with telephony framework to have the proper changes, and add the missing bits to control every aspect.

[Guest MrHicks]

Yikes.

I just had a quick peek in the ril shared library files with readelf and I can't see RIL_RequestFunc, RIL_RadioStateRequest, RIL_Supports, RIL_Cancel and RIL_GetVersion implemented anywhere, is this the issue?

Edited January 12, 2011 by MrHicks

[Guest fonix232]

Yikes.

I just had a quick peek in the ril shared library files with readelf and I can't see RIL_RequestFunc, RIL_RadioStateRequest, RIL_Supports, RIL_Cancel and RIL_GetVersion implemented anywhere, is this the issue?

I guess it is, at least I hope, because if it is, then a simple search of it in the decompiled telephony framework will tell us what we need. Hopefully.

[Guest rjm2k]

Managed to get apktool working the problem I had was caused by the wrong version of java. Managed to decompile both the zte and aosp framework and run some diffs there were 1000 but mostly line number changes so I might see if they can be removed by apktool.

[Guest cobhc]

Ooh, sounds like we may have a bit of progress here. Why o why did ZTE do things the arse about face way? Deary me! :D

[Guest fonix232]

Managed to get apktool working the problem I had was caused by the wrong version of java. Managed to decompile both the zte and aosp framework and run some diffs there were 1000 but mostly line number changes so I might see if they can be removed by apktool.

Are you using windows? If yes, best app to diff is WinDiff, it looks for similar code blocks too (also there are a few Java source differs too, AFAIK). I hope you can get some part of it working, at least 2G connection, that would be a start :D

[Guest rjm2k]

Are you using windows? If yes, best app to diff is WinDiff, it looks for similar code blocks too (also there are a few Java source differs too, AFAIK). I hope you can get some part of it working, at least 2G connection, that would be a start :D

I'm using Linux and windows, I decompiled on linux and copied to windows (I'm more used to working on windows) WinMerge is what I've used, though windiff is ok too. Can't promise anything really. will have a look if I get time but lots of other things on too, if I spot anything I'll probably post it so someone else can pick it up if needed.

[Guest rjm2k]

Ok for anyone interested here are 2 examples of the changes they made, to ril and itelephony. I got this by decompiling the framework.jat file using apktool then using winmerge (with a filter to ignore ".line" in order to reduce the changes). Once winmerge identified the files that were different by comparing the smali code I used dex2jar to decompile the frameworks to java, then I used jd-gui to open the output from that which shows "proper" java. Since jd-gui crashes when saving all files I manually copied the code from the aosp and zte files to text files and then finally used winmerge to compare the java. There are quite a few changes and I'm not sure what the best way to progress is. Note that this is 2 out of 420 files which have changed, but most of those wont be what prevents ril from working for us.

Note I only used apktool because jd-gui errors when saving all files, if that worked ok it would be a lot easier.

I think that realistically the best way of moving forward would be to debug the framework from aosp and zte in order to compare where the different behaviour occurs that causes the problems we have, then identify what may be causing that but it's a lot of work.

framecompare.zip

Edited January 12, 2011 by rjm2k

[Guest StevenHarperUK]

Interesting that the ZTE one uses non blocking IO in processUnsolicited(Parcel paramParcel)

I can read most of this stuff - what are you trying to achieve?

What do you need us to do ? Get the Method sigs to match?

[Guest zapher]

Ok for anyone interested here are 2 examples of the changes they made, to ril and itelephony. I got this by decompiling the framework.jat file using apktool then using winmerge (with a filter to ignore ".line" in order to reduce the changes). Once winmerge identified the files that were different by comparing the smali code I used dex2jar to decompile the frameworks to java, then I used jd-gui to open the output from that which shows "proper" java. Since jd-gui crashes when saving all files I manually copied the code from the aosp and zte files to text files and then finally used winmerge to compare the java. There are quite a few changes and I'm not sure what the best way to progress is. Note that this is 2 out of 420 files which have changed, but most of those wont be what prevents ril from working for us.

Note I only used apktool because jd-gui errors when saving all files, if that worked ok it would be a lot easier.

I think that realistically the best way of moving forward would be to debug the framework from aosp and zte in order to compare where the different behaviour occurs that causes the problems we have, then identify what may be causing that but it's a lot of work.

How would it be to transfer the relevant .dex and bake them into the Cyanogenmod framework-jar?

[Guest Arr Too]

I used dex2jar to decompile the frameworks to java

dex2jar can make a pig's ear of the control flow, and really doesn't cope with jump tables (used by switch, for example).

I notice that ZTE's propensity for typos extends to the public methods:

public void stopGetNewtworks(...)

[Guest rjm2k]

Interesting that the ZTE one uses non blocking IO in processUnsolicited(Parcel paramParcel)

I can read most of this stuff - what are you trying to achieve?

What do you need us to do ? Get the Method sigs to match?

Dunno really, just trying to get the ball rolling for things like cyanogen. In order for it to work we need to make the blade ril work with stock android, identifying the differences that zte made is one way but it's difficult to produce patches etc because the code doesn't dissassemble accuratly and we don't know the baseline that zte used. Like I mentioned, another approach is to debug the stock framework on a running phone and identify where it fails then debug the zte framework and identify what the difference is so that we can make stock work. Identifying changes plus debugging is probably the way to go, but not an easy task.

I doubt we could simply copy the dex to a newer framework since it's likely that the framework depends on changes that the zte version wont contain.

[Guest rjm2k]

dex2jar can make a pig's ear of the control flow, and really doesn't cope with jump tables (used by switch, for example).

I notice that ZTE's propensity for typos extends to the public methods:

public void stopGetNewtworks(...)

yeah I noticed that too, any changes identified would need to be manually checked to ensure it hasn't messed something up

[Guest cobhc]

Dunno really, just trying to get the ball rolling for things like cyanogen. In order for it to work we need to make the blade ril work with stock android, identifying the differences that zte made is one way but it's difficult to produce patches etc because the code doesn't dissassemble accuratly and we don't know the baseline that zte used. Like I mentioned, another approach is to debug the stock framework on a running phone and identify where it fails then debug the zte framework and identify what the difference is so that we can make stock work. Identifying changes plus debugging is probably the way to go, but not an easy task.

I doubt we could simply copy the dex to a newer framework since it's likely that the framework depends on changes that the zte version wont contain.

Would debugging the stock framework require someone who knows what they're looking for, or is it something I could help with? :D

[Guest rjm2k]

Would debugging the stock framework require someone who knows what they're looking for, or is it something I could help with? :D

A developer who can debug and setup android for debugging might be able to do this, I've not done it myself. What you would need is to setup your debug environment DDMS etc, then hook up your phone add a breakpoint somewhere like the option to connect to a selected mobile network and follow what happens, see where it fails, then do the same on the zte framework. Before you can do this you would also need to build the stock android and get to a point where you have a running image albeit minus working ril. Not a simple or quick task. The devs on here have done a great job so far and hopefully they will crack it one way or another but I also think some more of the CM team are showing an interest which may speed things up (especially when the blade goes to america)

[Guest fonix232]

If I get you the names of the functions, can you recreate them to be used in an AOSP build?

[Guest jonuwz]

If you use apktool dj etc etc etc

it should decompile to .java files (that contain smali)

You can try to re-write the suspect functions one at a time in real java before recompiling. Then port it to AOSP if it works

Take a look at this :

(Apologies if this is old news)

Do we have an AOSP build somewhere where the ril doesn't work ?

John

[Guest sebbo90]

If you use apktool dj etc etc etc

it should decompile to .java files (that contain smali)

You can try to re-write the suspect functions one at a time in real java before recompiling. Then port it to AOSP if it works

Take a look at this :

(Apologies if this is old news)

Do we have an AOSP build somewhere where the ril doesn't work ?

John

I think the latest gingerbread build the ril doesn't work

Edited January 13, 2011 by sebbo90

[Guest 0x90]

If you use apktool dj etc etc etc

it should decompile to .java files (that contain smali)

You can try to re-write the suspect functions one at a time in real java before recompiling. Then port it to AOSP if it works

Take a look at this :

(Apologies if this is old news)

Do we have an AOSP build somewhere where the ril doesn't work ?

John

Brut.all never got that funktion to work i apktool, so its not implemented. But the changes to the framework files doesnt seem that big.

[Guest sebbo90]

We got any update on this? Not ebing impatient here was just curoius to know if it was still going along smoothish ;)

[Guest Cirno]

I just hope there will be a release sooner or later ;)

[Guest olionair]

here is a non working version of cm 7 on my friends git hub https://github.com/HCDRJacob/device_zte_blade

(download the source and fix it !)