search

loganchien / smali

Automatically exported from code.google.com/p/smali
0 stars 0 forks source link

Problem de-odexing framework.jar on 4.2 #155

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
When I de-odex a 4.2 framework.jar and push it to the device, everything seems 
to work, except the device is crashing adding widgets:

"java.lang.IllegalAccessError: tried to access class android.app.ContextImpl 
from class android.appwidget.AppWidgetHost"

Weird I know!

I am de-odexing using 'baksmali -a 17 -x framework.odex'

This is using the 1.4.1 release, framework.jar / .odex files attached.

Original issue reported on code.google.com by p...@modaco.com on 21 Nov 2012 at 1:26

Attachments:

GoogleCodeExporter commented 9 years ago 
Further update.

I found what is causing the crash... what should have been de-odexed as:

    invoke-virtual {v2}, Landroid/content/Context;->getPackageName()Ljava/lang/String;

was actually de-odexed as:

    invoke-virtual {v2}, Landroid/app/ContextImpl;->getPackageName()Ljava/lang/String;

Any ideas how that could possibly happen? :-/

P

Original comment by p...@modaco.com on 21 Nov 2012 at 2:04

GoogleCodeExporter commented 9 years ago 
Can you be a bit more specific as to the location of that incorrect 
instruction? :)

Original comment by jesusfreke@jesusfreke.com on 21 Nov 2012 at 6:48

GoogleCodeExporter commented 9 years ago 
It was in /android/appwidget/AppWidgetHost.smali in framework.jar...

P

Original comment by p...@modaco.com on 21 Nov 2012 at 7:12

GoogleCodeExporter commented 9 years ago 
Derrr. sorry. I guess that was a silly question, given the exception message 
from above.

It is deodexing to the ContextImpl class, because v2 contains a ContextImpl 
object from the invoke-virtual just above it. The problem is that ContextImpl 
is a package-private class, and can't be accessed.

I'm fairly sure that this sort of thing was allowed in previous versions, due 
to the fact that this sort of thing has always worked. I suspect that dalvik is 
now more strict about checking access.

Original comment by jesusfreke@jesusfreke.com on 21 Nov 2012 at 7:27

GoogleCodeExporter commented 9 years ago 
After looking into this some more, I don't think there was any related 
functionality change in dalvik. I think it just happens to be a corner case 
that hadn't previously been encountered.

Original comment by jesusfreke@jesusfreke.com on 21 Nov 2012 at 8:15

GoogleCodeExporter commented 9 years ago 
Strange. Is there anything that can be done to prevent this happening?

P

Original comment by p...@modaco.com on 22 Nov 2012 at 3:14

GoogleCodeExporter commented 9 years ago 
Yes, of course. I believe the term is "fixing the code". :)

It's not a trivial fix, but it shouldn't be too bad I don't think. I'll try and 
get it fixed over this 4 day weekend.

Original comment by jesusfreke@jesusfreke.com on 22 Nov 2012 at 6:47

GoogleCodeExporter commented 9 years ago 
I've hit this issue again, causing another framework crash! I've not tracked 
down exactly where it is yet tho! :(

P

Original comment by p...@modaco.com on 4 Dec 2012 at 2:33

GoogleCodeExporter commented 9 years ago 
Just to follow this up a bit more... it seems to only occur when working with 
odex files (the -x switch) and not with regular dex files...

P

Original comment by p...@modaco.com on 5 Dec 2012 at 9:50

GoogleCodeExporter commented 9 years ago 
I've committed a fix for this. Please build baksmali from the latest code and 
verify it fixes this issue.

Original comment by jesusfreke@jesusfreke.com on 10 Dec 2012 at 12:20

GoogleCodeExporter commented 9 years ago 
So far so good! :)

P

Original comment by p...@modaco.com on 11 Dec 2012 at 3:51

GoogleCodeExporter commented 9 years ago

Original comment by jesusfreke@jesusfreke.com on 26 Dec 2012 at 2:08