Jump to content


Photo

Cyanogen Mod 7 For Blade

* * * * * 1 votes

  • Please log in to reply
234 replies to this topic

#61
rjm2k

rjm2k

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,096 posts
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.

Attached Files


Edited by rjm2k, 12 January 2011 - 09:54 PM.

  • 0

#62
StevenHarperUK

StevenHarperUK

    Hardcore

  • Moderator Team
  • PipPipPipPipPipPip
  • 1,431 posts
  • Gender:Male
  • Location:United Kingdom
  • Devices:Orange San Francisco
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

#63
csholmq

csholmq

    Regular

  • Members
  • PipPip
  • 58 posts
  • Gender:Male
  • Devices:Sony Xperia P
  • Twitter:@csholmq

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

#64
Arr Too

Arr Too

    Addict

  • Members
  • PipPipPipPipPip
  • 622 posts

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

#65
rjm2k

rjm2k

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,096 posts

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

#66
rjm2k

rjm2k

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,096 posts

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

#67
cobhc

cobhc

    Diehard

  • MoDaCo Gold
  • PipPipPipPip
  • 395 posts
  • Devices:Jet, San Fran, HD2

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

This place is in dire need of separated sections. It's kinda like we're shitting where we dine.


#68
rjm2k

rjm2k

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,096 posts

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

#69
fonix232

fonix232

    Addict

  • Members
  • PipPipPipPipPip
  • 942 posts
  • Location:Hungary, Debrecen
  • Devices:ZTE Blade [TFT 512RAM]
  • Twitter:@fonix232
If I get you the names of the functions, can you recreate them to be used in an AOSP build?

  • 0
If you like my work, invite me for a drink or two!

Also, take a look at my Blade-dedicated site too! fonix232.co.cc

#70
jonuwz

jonuwz

    Newbie

  • Members
  • Pip
  • 29 posts
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

#71
sebbo90

sebbo90

    Regular

  • Members
  • PipPip
  • 63 posts

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, 13 January 2011 - 07:57 PM.

  • 0

#72
0x90

0x90

    Regular

  • Members
  • PipPip
  • 75 posts
  • Location:Sweden - Skövde
  • Devices:zte blade

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
Open source system developer

0x90 mod

#73
sebbo90

sebbo90

    Regular

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

  • 0

#74
Cirno

Cirno

    Diehard

  • Members
  • PipPipPipPip
  • 329 posts
  • Location:@home
  • Devices:Huawei U8800 Ideos X5
I just hope there will be a release sooner or later ;)

  • 0

#75
olionair

olionair

    Enthusiast

  • MoDaCo Silver
  • PipPipPip
  • 181 posts
  • Gender:Male
  • Location:UK
  • Devices:Transformer and SGS2
  • Twitter:@OliverHaywood
here is a non working version of cm 7 on my friends git hub https://github.com/H...evice_zte_blade

(download the source and fix it !)

  • 0

#76
HCDR.Jacob

HCDR.Jacob

    Hardcore

  • Developer Team
  • PipPip
  • 122 posts
  • Gender:Male
  • Devices:HTC One, N4, N7
  • Twitter:@HCDRJacob
Going to continue working on this throughout the week. I expect to be able to get it booting soon.

At the moment, the issue is that /data isn't mounting.

Development may be slow, sorry. I don't have a Blade myself so the testing process takes a lot longer ;)

  • 0
Maintainer of CyanogenMod 7 for ZTE Blade and HTC Wildfire.

Donate to me if you appreciate my work.

Posted Image

#77
shadowninty

shadowninty

    Diehard

  • Members
  • PipPipPipPip
  • 418 posts
  • Gender:Male
  • Location:Cork City, EU
  • Devices:Xperia Play, ZTE Blade

Going to continue working on this throughout the week. I expect to be able to get it booting soon.

At the moment, the issue is that /data isn't mounting.

Development may be slow, sorry. I don't have a Blade myself so the testing process takes a lot longer ;)

your work is greatly appreciated! :)

  • 0
Device: ZTE Blade [TFT, White] ROM: CyanogenMod 7 [Latest Nightly] Android 2.3.4
Sign up for Dropbox, and earn us both 250MB EXTRA Free Online Storage on top of 2GB you get already - The Cloud, its the future
Dropbox lets you easily sync files between your OS's (including Windows, Ubuntu and Android!)

#78
HCDR.Jacob

HCDR.Jacob

    Hardcore

  • Developer Team
  • PipPip
  • 122 posts
  • Gender:Male
  • Devices:HTC One, N4, N7
  • Twitter:@HCDRJacob
For any devs interested, this is the kernel log I retrieved from the device:

http://pastebin.com/p4DxNWt5

  • 0
Maintainer of CyanogenMod 7 for ZTE Blade and HTC Wildfire.

Donate to me if you appreciate my work.

Posted Image

#79
Cirno

Cirno

    Diehard

  • Members
  • PipPipPipPip
  • 329 posts
  • Location:@home
  • Devices:Huawei U8800 Ideos X5

Going to continue working on this throughout the week. I expect to be able to get it booting soon.

At the moment, the issue is that /data isn't mounting.

Development may be slow, sorry. I don't have a Blade myself so the testing process takes a lot longer ;)


Woah, no problem its just great to see some progress. Small steps are the best until you can make leaps?

  • 0

#80
leromarinvit

leromarinvit

    Regular

  • Members
  • PipPip
  • 77 posts

For any devs interested, this is the kernel log I retrieved from the device:

http://pastebin.com/p4DxNWt5

Any specific reason you're using 2.6.29? 2.6.32 source has been availbable for some time now.

Anyway, I greatly appreciate your effort. Unfortunately, I don't have enough time to help out myself.

  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users