Jump to content

Cyanogen Mod 7 For Blade


Guest olionair

Recommended Posts

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by MrHicks
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by rjm2k
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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(...)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by sebbo90
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.