[Soot-list] Inner Class Detection Problem

[Steven Arzt]

Hi Jason,

 

Please try to avoid using methods such as forceResolve(). As I said, these methods are internals of Soot. Without a very profound understanding of the Soot class loading process, you can run into all sorts of funny behaviors. Internal methods make assumptions about internal stuff. I will only look into this issue any further if it also occurs when using Soot properly – see my last e-mail about Transformers.

 

Best regards,

  Steven

 

Von: soot-list-bounces at CS.McGill.CA [mailto:soot-list-bounces at CS.McGill.CA] Im Auftrag von Jason Ott
Gesendet: Samstag, 25. Juli 2015 01:56
An: soot-list at cs.mcgill.ca
Betreff: [Soot-list] Inner Class Detection Problem

 

I have a class: com.android.server.power.PowerManagerService$BinderService <http://androidxref.com/5.1.1_r6/xref/frameworks/base/services/core/java/com/android/server/power/PowerManagerService.java#2797>  which is an inner class.  However, Soot does not see it that way when I try to forceResolve it using: BODIES|HIERARCHY|SIGNATURES (or any combination of them).

 

When I use SootClass.hasOuterClass() on the above resolved class it returns false.

 

This is how I resolve the class:

protected synchronized SootClass bringClassToScene(String className) {
    SootClass sootClass;
    sootClass = Scene.v().forceResolve(className, SootClass.BODIES | SootClass.HIERARCHY | SootClass.SIGNATURES);
    sootClass.setApplicationClass();
    return sootClass;
}

So I then invoke:
SootClass sootClass = bringClassToScene("");
sootClass.hasOuterClass() //return false

I would expect it to return true in this case.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20150727/41b7a354/attachment.html