Jump to content


Photo

Cyanogen Mod 7 For Blade

* * * * * 1 votes

  • Please log in to reply
234 replies to this topic

#21
Rotmann

Rotmann

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,019 posts
  • Devices:Nexus One, ZTE Blade

The RIL problems have nothing to do with kernel source (I don't know why I bother repeating this, no one listens).

:D sorry. Could you explain then why we are not able to get special ROMs? Like CM or MIUI.

  • 0

#22
mrflibbles

mrflibbles

    Newbie

  • Members
  • Pip
  • 49 posts
  • Gender:Male
  • Location:Oxford, UK
  • Devices:San Francisco
We were listening. (Or at least I was). From what I gleamed from your posts : Android's Radio Interface Layer (RIL) provides an abstraction layer between Android telephony services (android.telephony) and radio hardware. You can see from the diagram that the Kernel and the RIL are quite separate.

Posted Image

While the Kernel is open-source large parts of Android can be modified without releasing source or information. I think from reading normally the hardware customisation is done only in the vendor RIL (system/libs/libril_vendor.so) but on the Blade for some reason ZTE have modified the telephony framework (java/android/telephony). This makes telephony and RIL interfaces for the Blade different to AOSP used by CM.

If we could work out why and how they changed the telephony framework then we could modify AOSP but that is a difficult task unless ZTE developers give us the information.

Is that right?

I'd be curious to know more details about how you know the telephony framework has changed? (i.e. things just don't compile?)

Edited by mrflibbles, 11 January 2011 - 10:23 AM.

  • 0

#23
cobhc

cobhc

    Diehard

  • MoDaCo Gold
  • PipPipPipPip
  • 395 posts
  • Devices:Jet, San Fran, HD2
That sounds about right from what I've gleamed from Tom as well. I'm sure he tried another branch also rather than AOSP and still had problems.

  • 0

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


#24
rjm2k

rjm2k

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,096 posts
Had anyone investigated qcrilhook.jar and qcnvitems.jar, maybe the changes to the framework are minimal and simply call through to those jars?

  • 0

#25
mrflibbles

mrflibbles

    Newbie

  • Members
  • Pip
  • 49 posts
  • Gender:Male
  • Location:Oxford, UK
  • Devices:San Francisco
There is an interesting (albeit high level) presentation from Qualcomm which includes RIL here : (Starts at page 23)

http://docs.google.c...a...ppEaA&pli=1

Edited by mrflibbles, 11 January 2011 - 12:47 PM.

  • 0

#26
bagge

bagge

    Regular

  • Members
  • PipPip
  • 55 posts
Has ZTE officially refused to disclose that code or are we just assuming they wouldnt?

  • 0

#27
rjm2k

rjm2k

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,096 posts

I'd be curious to know more details about how you know the telephony framework has changed? (i.e. things just don't compile?)


You can de-compile the framework, I guess someone has done this and spotted changes. Someone posted that they were working on differencing the zte framework against AOSP but nothing since.

  • 0

#28
cobhc

cobhc

    Diehard

  • MoDaCo Gold
  • PipPipPipPip
  • 395 posts
  • Devices:Jet, San Fran, HD2
If anyone can tell me how to go about diff'ing the two frameworks then I could put some time into doing it.

  • 0

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


#29
IronDoc

IronDoc

    Addict

  • MoDaCo Silver
  • PipPipPipPipPip
  • 522 posts
  • Devices:Blade

You can de-compile the framework, I guess someone has done this and spotted changes. Someone posted that they were working on differencing the zte framework against AOSP but nothing since.

Apparently there are too many changes and so this doesn't work (just repeating what I've read). Or it's very difficult...
There was some reason anyway :/

  • 0

#30
rjm2k

rjm2k

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,096 posts

If anyone can tell me how to go about diff'ing the two frameworks then I could put some time into doing it.


You can use dex2jar to convert the .dex files inside the apk files to .class files, then use jd-gui to view the source. Jd-gui has a feature to save the source files but this crashes making it difficult to get hold of all of the source in a form suitable to differencing. NB also that due to optimisations performed when compiling the source, the sequence of statements in the decompiled version may be incorrect, however the same incorrect sequence is likely to be found in the decompiled stock version and zte version so differencing will ignore that unless there are actual differences in which case you would have to use judgement to work out the correct flow.

Another option is to use APKTool to decompile to smali (I think that's the name), it the "assembly" language used by the "java"/Dalvik virtual machine (I think), I haven't worked out how to get that output yet though.

In order to compare you obviously have to get the stock framework, I did this by getting from the appropriate AOSP branch for FRF91 (the version of android on the blade) "android2.2-rel1" or something similar ( I can't remember off hand).

We don't really need ALL changes that ZTE made, just the ones that make RIL work, these are thought to be in Phone.apk and the framework jar file.

Edited by rjm2k, 11 January 2011 - 02:20 PM.

  • 0

#31
MDCFan

MDCFan

    Regular

  • Members
  • PipPip
  • 127 posts
  • Gender:Male
  • Devices:N/A

Another option is to use APKTool to decompile to smali (I think that's the name), it the "assembly" language used by the "java"/Dalvik virtual machine (I think), I haven't worked out how to get that output yet though.


apktool.bat d Phone.apk

After that a folder named "Phone" will be created in the current directory and you will find smali code in "smali" folder.

  • 0
I am selling my perfect condition OLED San Francisco here

#32
cobhc

cobhc

    Diehard

  • MoDaCo Gold
  • PipPipPipPip
  • 395 posts
  • Devices:Jet, San Fran, HD2
Is it a very time consuming process? Has noone just had enough time to do it?

  • 0

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


#33
rjm2k

rjm2k

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,096 posts

apktool.bat d Phone.apk

After that a folder named "Phone" will be created in the current directory and you will find smali code in "smali" folder.

Thanks, I assume it works for Jar files too?

  • 0

#34
isambard

isambard

    Diehard

  • Members
  • PipPipPipPip
  • 391 posts
  • Devices:ZTE Blade

We were listening. (Or at least I was). From what I gleamed from your posts : Android's Radio Interface Layer (RIL) provides an abstraction layer between Android telephony services (android.telephony) and radio hardware. You can see from the diagram that the Kernel and the RIL are quite separate.

Posted Image

While the Kernel is open-source large parts of Android can be modified without releasing source or information. I think from reading normally the hardware customisation is done only in the vendor RIL (system/libs/libril_vendor.so) but on the Blade for some reason ZTE have modified the telephony framework (java/android/telephony). This makes telephony and RIL interfaces for the Blade different to AOSP used by CM.

If we could work out why and how they changed the telephony framework then we could modify AOSP but that is a difficult task unless ZTE developers give us the information.

Is that right?

I'd be curious to know more details about how you know the telephony framework has changed? (i.e. things just don't compile?)


actually, i would also be interested to know what exactly the problem is.

i assume that the vendor RIL library is not compiled into the kernel (for GPL reasons) but rather in a separate library and that we can use the pre-compiled library with our own modified kernels. ditto for the ril daemon.

the last link is then the application framework and how this interfaces the ril daemon. i guess it's not as simple as compiling the rest of android and substituting the telephony and gsm from the ZTE versions otherwise someone would have done this already. am i right?

then is it a case of having to write a layer to translate either the telephony part or gsm part?

  • 0
The best Android Timer application. See also website here: DroidGram Timer Pro.
Download Blade Buddy, the essential companion for your Blade.
Un-lock your Blade with Blade Un-locker.
Free and ad-free basic settings editor: Spare Parts Plus!

#35
Cirno

Cirno

    Diehard

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

Yeah CM7 is based on 2.3... We won't get ports of any other roms until we get RIL working properly.

On a side note where is your username from?


Me?
Well my username is a name from an ice fairy called Cirno, why :D?

  • 0

#36
gusthy

gusthy

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,102 posts
  • Location:Budapest
  • Devices:Pulse

The RIL problems have nothing to do with kernel source (I don't know why I bother repeating this, no one listens).


  • 0

#37
joyfun

joyfun

    Newbie

  • Members
  • Pip
  • 21 posts
  • Devices:V880
I don't know much about how RIL work
Some people mentioned Phone.apk , AFAIK in flibblesan latest rom he used the AOSP dailer. I don't know if he complied himself . I think he is used RIL with aosp code.

  • 0

#38
sebbo90

sebbo90

    Regular

  • Members
  • PipPip
  • 63 posts
Would it be too difficult then to compile our own version of ril so that it would work with aosp? Or could we not use the ril version from the HTC legend roms as they both use the same chipset?

  • 0

#39
pellen

pellen

    Regular

  • MoDaCo Silver
  • PipPip
  • 60 posts
  • Location:Linköping
  • Devices:Samsung Galaxy S II

Thanks, I assume it works for Jar files too?


That's correct :D

  • 0

#40
rjm2k

rjm2k

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,096 posts
[quote name='MDCFan' post='1555812' date='Jan 11 2011, 14:38']apktool.bat d Phone.apk

I just get this error on ubuntu, probably wrong version of java, maybe I'll try windows instead - nope that gives the same error.

Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)

Edited by rjm2k, 11 January 2011 - 07:03 PM.

  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users