Jump to content


Photo

Cyanogen Mod 7 For Blade

* * * * * 1 votes

  • Please log in to reply
234 replies to this topic

#41
pellen

pellen

    Regular

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

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.

  • 0

#42
sebbo90

sebbo90

    Regular

  • Members
  • PipPip
  • 63 posts

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

  • 0

#43
pellen

pellen

    Regular

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

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 :D

  • 0

#44
Frankish

Frankish

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 3,535 posts
  • Gender:Male
  • Devices:iPhone 4S Xiaocai X9 THL W200
APKTool or just Baksmali which is what i use. It's easy on windows.

  • 0

#45
sebbo90

sebbo90

    Regular

  • Members
  • PipPip
  • 63 posts

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 :D



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)

  • 0

#46
oh!dougal

oh!dougal

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,022 posts
  • Location:England
  • Devices:DX2 FroYo San Francisco

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

  • 0

#47
sebbo90

sebbo90

    Regular

  • Members
  • PipPip
  • 63 posts
Anyone just asked zte for the RIL library source code? lol

  • 0

#48
rjm2k

rjm2k

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,096 posts

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.

  • 0

#49
rjm2k

rjm2k

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,096 posts

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.

  • 0

#50
Hopelessness

Hopelessness

    Newbie

  • Members
  • Pip
  • 31 posts
  • Location:Southampton / Cardiff, UK
  • Devices:Hero, Blade, Vega
What about the HTC Legend RIL? Would that not be compatible?

  • 0

#51
sebbo90

sebbo90

    Regular

  • Members
  • PipPip
  • 63 posts
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

#52
Afrodude

Afrodude

    Enthusiast

  • Members
  • PipPipPip
  • 194 posts

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

Not a chance.

  • 0

#53
MrHicks

MrHicks

    Newbie

  • MoDaCo Silver
  • Pip
  • 49 posts
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

#54
fonix232

fonix232

    Addict

  • Members
  • PipPipPipPipPip
  • 942 posts
  • Location:Hungary, Debrecen
  • Devices:ZTE Blade [TFT 512RAM]
  • Twitter:@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.

  • 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

#55
MrHicks

MrHicks

    Newbie

  • MoDaCo Silver
  • Pip
  • 49 posts
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.

  • 0

#56
fonix232

fonix232

    Addict

  • Members
  • PipPipPipPipPip
  • 942 posts
  • Location:Hungary, Debrecen
  • Devices:ZTE Blade [TFT 512RAM]
  • Twitter:@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.

  • 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

#57
rjm2k

rjm2k

    Hardcore

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

#58
cobhc

cobhc

    Diehard

  • MoDaCo Gold
  • PipPipPipPip
  • 395 posts
  • Devices:Jet, San Fran, HD2
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

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


#59
fonix232

fonix232

    Addict

  • Members
  • PipPipPipPipPip
  • 942 posts
  • Location:Hungary, Debrecen
  • Devices:ZTE Blade [TFT 512RAM]
  • Twitter:@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

  • 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

#60
rjm2k

rjm2k

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,096 posts

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




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users