GoogleCodeExporter
commented
9 years ago Add all framework files via -c is *never* the correct solution. It can cause
incorrect results in some cases.
It is doubly wrong to add all the framework files via the -c option using an
initial ':' character. Using an initial ':' tells baksmali to append all those
jars to the existing default bootclasspath that it uses (which matches the
BOOTCLASSPATH on most "clean" google android devices). So you will actually end
up with duplicate entries because the default bootclasspath has, for example,
framework.jar, and you are adding an extra framework.jar.
And thirdly, the order of the bootclasspath list does matter. You should have
the files in the same order as in your BOOTCLASSPATH environment variable, with
any extra dependencies at the end.
Now, to address your particular problem, you first need to specify the correct
BOOTCLASSPATH to use via the -c option. Next, assuming that it still can't find
the class, you need to find which jar or apk contains the class that it is
complaining about, and then add it to the end of the classpath that baksmali
searches.
To find which jar/apk the class is in, simply run baksmali without the -x
option on every jar/apk in both /system/framework and /system/app (or on the
associated odex files, as applicable - but still without the -x option). And
then grep through the results for that class.
And finally, if that still doesn't resolve the issue, and you are 100% certain
that the class doesn't exist at all on the device (which does happen on
occasion), then you can use the -I option to ignore these "class not found"
type errors. But if you use the -I option when the class does in fact exist
somewhere on the device, it will likely cause a crash in the application - so
be sure that the class really doesn't exist :)Original comment by JesusFr...@gmail.com on 30 Mar 2011 at 6:12
- Changed state: Done
- Added labels: ****
- Removed labels: ****
Original issue reported on code.google.com by
MMWAg...@gmail.comon 30 Mar 2011 at 5:42