234 replies to this topic

[pellen]

rjm2k, on Jan 11 2011, 19:56, said:

MDCFan, on Jan 11 2011, 14:38, said:

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)

I had no problems baksmaling Phone.apk.

EDIT: Have you installed the framework files for apktool to use?

Edited by pellen, 11 January 2011 - 07:11 PM.

[sebbo90]

pellen, on Jan 11 2011, 19:08, said:

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)
I had no problems baksmaling Phone.apk.

EDIT: Have you installed the framework files for apktool to use?

How's the decompiling going? Is this anyone can do? Just after tonight I have 5 days off and nought to do

[pellen]

sebbo90, on Jan 11 2011, 21:11, said:

How's the decompiling going? Is this anyone can do? Just after tonight I have 5 days off and nought to do

With APKtool it's easy to decompile, but then fiddling about with the decompiled files isn't my cup of tea, I suck at programming

[Frankish]

APKTool or just Baksmali which is what i use. It's easy on windows.

[sebbo90]

pellen, on Jan 11 2011, 20:49, said:

With APKtool it's easy to decompile, but then fiddling about with the decompiled files isn't my cup of tea, I suck at programming

I am ok at it, I have time on my hands so would be glad to help and try and hopefully port an AOSP android to the blade. When the files are decompiled what needs to be done with them? What language are they in? Which files whould I be looking at?

(sorry for all the questions)

[oh!dougal]

sebbo90, on Jan 11 2011, 20:59, said:

... What language are they in? ...

I gather that the idea is to disassembe (baksmali) the ZTE ril layer to smali which is the assembler for Android's Java Virtual Machine "Dalvik".
So that's what that territory entails.


But I'm not sure exactly what the problem definition is.
Seems to be -
There's a complete AOSP source. But that doesn't talk to our radio hardware.
Our kernel source does talk to our radio hardware, but the radio part of the open source build doesn't talk to our kernel, and thus cannot talk to our hardware.
{Please feel free to correct or amplify this, I'm just trying to set it out plainly}

Precisely how that is best tackled, I don't think people have agreed upon.
Is it modifying the ZTE layer that talks to the kernel?
Or trying to translate the AOSP calls into things our kernel knows about?
Or looking at the working kernel source together with the AOSP kernel source to accept the calls that AOSP makes ...

Edited by oh!dougal, 11 January 2011 - 09:39 PM.

[sebbo90]

Anyone just asked zte for the RIL library source code? lol

[rjm2k]

oh!dougal, on Jan 11 2011, 21:36, said:

I gather that the idea is to disassembe (baksmali) the ZTE ril layer to smali which is the assembler for Android's Java Virtual Machine "Dalvik".
So that's what that territory entails.
But I'm not sure exactly what the problem definition is.
Seems to be -
There's a complete AOSP source. But that doesn't talk to our radio hardware.
Our kernel source does talk to our radio hardware, but the radio part of the open source build doesn't talk to our kernel, and thus cannot talk to our hardware.
{Please feel free to correct or amplify this, I'm just trying to set it out plainly}

Precisely how that is best tackled, I don't think people have agreed upon.
Is it modifying the ZTE layer that talks to the kernel?
Or trying to translate the AOSP calls into things our kernel knows about?
Or looking at the working kernel source together with the AOSP kernel source to accept the calls that AOSP makes ...

the framework.jar seems to have been modified kn some way to setup ril. without that modification aosp framework.jar wont setup ril so its a matter of spoting those changes and copying thrm to an aosp build.

[rjm2k]

sebbo90, on Jan 11 2011, 22:01, said:

Anyone just asked zte for the RIL library source code? lol

zte struggle to release code they are obliged to, ril belongs to qualcomm and is closed source so no way it will be released.

[Hopelessness]

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

[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 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

[Afrodude]

Hopelessness, on Jan 11 2011, 22:12, said:

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

Not a chance.

[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?

[fonix232]

MrHicks, on Jan 12 2011, 11:44, said:

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.

[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, 12 January 2011 - 10:18 AM.

[fonix232]

MrHicks, on Jan 12 2011, 13:15, said:

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.

[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.

[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!

[fonix232]

rjm2k, on Jan 12 2011, 14:35, said:

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

[rjm2k]

fonix232, on Jan 12 2011, 12:37, said:

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

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.