• Announcements

    • Reminder - MoDaCo position on illegal content   07/30/15

      ILLEGAL CONTENT I'd like to just reaffirm MoDaCo's position regarding piracy and illegal content in the light of some recent questions / postings. Posts will be censored by myself or my moderation team if the contain or link to: Illegal / pirated / cracked software or sites that host such softwareNintendo emulators / ROMs or sites hosting them (in light of Nintendo's legal stance)CUSTOM ROMS You may discuss and post links to custom device ROMs on MoDaCo, provided the following rules are adhered to: ROMs must not contain any illegal 3rd party software (this includes trial versions included without permission)ROMs must give full credit to the original authorISSUES If you have any issues with this policy, please contact PaulOBrien directly via PM.
    • Reminder: Selling items on the forum directly is not allowed   07/30/15

      Please note that selling items on the forum directly is not allowed by the forum rules. There is a forum for eBay auctions whereby you can list the items on eBay and link to them there. This is the ONLY forum for this type of activity. You may also advertise links to the eBay forum in your signature. Please note that selling directly in contravention of these rules will result in a warning / suspension / ban.

Cyanogen Mod 7 For Blade

235 posts in this topic

Posted · Report post

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

0

Share this post


Link to post
Share on other sites

Posted · Report post

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

Not a chance.

0

Share this post


Link to post
Share on other sites

Posted · Report post

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?

0

Share this post


Link to post
Share on other sites

Posted · Report post

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.

0

Share this post


Link to post
Share on other sites

Posted (edited) · Report post

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
0

Share this post


Link to post
Share on other sites

Posted · Report post

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.

0

Share this post


Link to post
Share on other sites

Posted · Report post

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.

0

Share this post


Link to post
Share on other sites

Posted · Report post

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

0

Share this post


Link to post
Share on other sites

Posted · Report post

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

0

Share this post


Link to post
Share on other sites

Posted · Report post

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.

0

Share this post


Link to post
Share on other sites

Posted (edited) · Report post

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
0

Share this post


Link to post
Share on other sites

Posted · Report post

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?

0

Share this post


Link to post
Share on other sites

Posted · Report post

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?

0

Share this post


Link to post
Share on other sites

Posted · Report post

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

0

Share this post


Link to post
Share on other sites

Posted · Report post

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.

0

Share this post


Link to post
Share on other sites

Posted · Report post

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

0

Share this post


Link to post
Share on other sites

Posted · Report post

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

0

Share this post


Link to post
Share on other sites

Posted · Report post

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)

0

Share this post


Link to post
Share on other sites

Posted · Report post

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

0

Share this post


Link to post
Share on other sites

Posted · Report post

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

0

Share this post


Link to post
Share on other sites

Posted (edited) · Report post

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
0

Share this post


Link to post
Share on other sites

Posted · Report post

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.

0

Share this post


Link to post
Share on other sites

Posted · Report post

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

0

Share this post


Link to post
Share on other sites

Posted · Report post

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

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

MoDaCo is part of the MoDaCo.network, © Paul O'Brien 2002-2015. MoDaCo uses IntelliTxt technology.