[Soot-list] Help with FastHierarchy.isSubclass(SootClass child, SootClass parent)

[Henddher Pedroza]

Hello again Eric,

I came across this posting:
https://groups.google.com/forum/#!msg/ded-install/1u3IJZi_Hos/MUn2owP7afUJ 
<https://groups.google.com/forum/#%21msg/ded-install/1u3IJZi_Hos/MUn2owP7afUJ>
It mentions that "android.jar" should be listed in soot-class-path.

I also found this:
https://github.com/Sable/soot/pull/4
Which shows a patch to specify android.jar but it's not in Soot 2.5.0.

Using v2.5.0, what would be the correct way to configure Soot to use 
android.jar?

I am still trying to determine if the FastHierarchy issue I am 
experiencing is due to incorrect Soot configuration on my end.

Thanks in advance.

- Henddher

On 10/10/2012 09:57 AM, Henddher Pedroza wrote:
> Hello Eric,
>
> I read the documentation and your blog ( 
> http://www.bodden.de/2008/08/21/soot-command-line/).
> android.jar (part of Android SDK) is not in the classpath. In my 
> example, I use "./android.jar" to simplify matter. The android.jar is 
> located in Android SDK: "<android_sdk_path>/.../android.jar"
>
> In my env, CLASSPATH is empty and JAVA_HOME points to JDK1.7.
>
> When I remove soot-class-path, Soot resolves classes against JDK1.7, 
> so all android classes are nowhere to be found and the whole thing fails.
>
> I cannot use CLASSPATH because the tool I am building uses Maven which 
> has its own classpath. Thus, the -pp option wouldn't work.
>
> Where can I find more documentation (and examples) of alternate 
> classpaths?
>
> Thanks
>
> - Henddher
>
> PS/ J2ME had to experience a similar issue because CLDC.jar/MIDP.jar 
> are very different from JDK classes. For J2ME, I remember using 
> bootclasspath in the compiler.
>
> On 10/10/2012 03:04 AM, Eric Bodden wrote:
>> Hello.
>>
>> I think the problem is that you are explicitly setting Soot's
>> classpath. This overrides the default classpath, which contains the
>> correct android.jar. You can add the -pp option to have your classpath
>> prepended to that default classpath instead. (see online doc)
>>
>> Eric
>>
>> On 9 October 2012 15:56, Henddher Pedroza<hpedro2 at uic.edu>  wrote:
>>> Thanks again Eric, but I am confused:
>>>
>>> I have a jar file containing all classes I want to analyze. This jar
>>> contains an Android app so all classes not present in the jar are assumed to
>>> be part of the target platform; therefore, all these other classes should be
>>> available in "android.jar" part of Android SDK.
>>>
>>> My code looks like this:
>>>
>>> Options.v().set_process_dir(Arrays.asList(new String[] { "myAndroidApp.jar"
>>> })); // (1)
>>> Options.v().set_soot_classpath("./android.jar:./myAndroidApp.jar"); // (2)
>>> Options.v().set_exclude(Arrays.asList(new String[] { "android." })); // (3)
>>>
>>> The intention is to perform analysis in all classes found in
>>> myAndroidApp.jar, such classes will have references to classes in
>>> "android.jar" but none of the classes in "android.jar" will be analyzed -
>>> And I expect all classes in "android.jar" to be fully loaded by Soot but not
>>> analyzed.
>>>
>>> Am I using the settings incorrectly?
>>>
>>> I tried removing (3) and it made no difference; Soot still threw NPE at 151.
>>>
>>> - Henddher
>>>
>>>
>>> On 10/06/2012 02:50 PM, Eric Bodden wrote:
>>>>> I thought excluding classes would just instruct Soot to skip analysis of
>>>>> them.
>>>> No, soot won't load that class.
>>>>
>>>>> In my case, anything that starts with "android." would not be analyzed
>>>>> but any included class (all in my jar because of "set_process_dir") that
>>>>> uses excluded classes would still be analyzed. Right?
>>>> That sounds right.
>>>>
>>>>> I can see that only the classes in my jar are being analyzed (I loop
>>>>> through
>>>>> Scene.v().getApplicationClasses())
>>>>> Am I not using exclude/include correctly?
>>>> Well it really depends on your use case, what "correct" really means.
>>>>
>>>>> On the other hand, if exclusion was indeed the issue, why would some
>>>>> classes
>>>>> in my jar trigger the NPE and not all of them
>>>> Because for some classes the super class is excluded (and thus null)
>>>>
>>>> but not for others.
>>>>
>>>> Eric
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20121011/7bad5a4d/attachment.html