1

I am trying to generate a call graph based on .smali file. However, I encountered a confusing case as follow:

.super Landroid/graphics/drawable/Drawable;
.source "SBarExp.java"

.method public final setBounds(Landroid/graphics/Rect;)V
  .line 514
  iget-object v2, p0, Lcom/sds/android/ttpod/app/modules/skin/view/SeekBarExpansion$a;->b:Landroid/graphics/drawable/Drawable;
  invoke-virtual {v2, p1, v0, p3, v1}, Landroid/graphics/drawable/Drawable;->setBounds(IIII)V
  .line 515
  invoke-super {p0, p1, v0, p3, v1}, Landroid/graphics/drawable/Drawable;->setBounds(IIII)V
.end method

Based on my understanding, invoke-super simply means it is going to call a parent method, so

invoke-super {p0, p1, v0, p3, v1}, Landroid/graphics/drawable/Drawable;->setBounds(IIII)V can be interpreted as Landroid/graphics/drawable/Drawable;->setBounds(IIII)V ?

If yes, I would like to know if invoke-virtual {v2, p1, v0, p3, v1}, Landroid/graphics/drawable/Drawable;->setBounds(IIII)V is the same as invoke-super {p0, p1, v0, p3, v1}, Landroid/graphics/drawable/Drawable;->setBounds(IIII)V?

If not, what is the difference? If yes, why is it invoking the same method twice (using different ways)?

Please help, many thanks!

cyberbrain
  • 3,433
  • 1
  • 12
  • 22
yi2ng2
  • 141
  • 2
  • 5
  • 14
  • You are looking at the under-the-hood implementation of an object-oriented design pattern where the first argument often specifies the subject object, so among other things, I believe the difference in the first argument means the first call is acting on a different object (probably held in an instance field) while the second is acting on itself. – Chris Stratton May 07 '14 at 15:17
  • Hi Chris, thank you for your promptly reply. So, can I understand this way: both "invokes" are invoking the same method (same class), provided they are passing different objects as arguements? – yi2ng2 May 07 '14 at 15:32

1 Answers1

2

invoke-virtual performs a virtual table lookup using the vtable associated with the target object's class (i.e. the actual runtime type of the first argument).

However, invoke-super is slightly different. It performs a vtable lookup using the superclass of the class containing the method being executed. In particular, note that the vtable lookup does not use or depend on the runtime type of the target object.

In your example, the invoke-virtual instruction is being called on the result of

iget-object v2, p0, Lcom/sds/android/ttpod/app/modules/skin/view/SeekBarExpansion$a;->b:Landroid/graphics/drawable/Drawable;

At this point, the actual method that is called depends on the actual type of v2, which could be any subclass of Drawable.

The invoke-super instruction is being called on the p0 register, which likely contains the "this" reference for the current object. However, the runtime type of p0 doesn't actually matter. The invoke-super instruction will always call Drawable's implementation of setBounds, regardless of the runtime type of p0.

JesusFreke
  • 19,784
  • 5
  • 65
  • 68
  • Hi there, thank you for your reply. So, for the case invoke-super will be always invoking "Landroid/graphics/drawable/Drawable;->setBounds(IIII)V" because it will not take the runtime type of p0 into considetaion. But invoke-virtual will be invoking a different method (depends on the type of v2). For my case, my main consideration is to draw a call graph. So, I have another doubt that how can I know which is the exact method is finally called by by the invoke-virtual? Thank you for your help! – yi2ng2 May 09 '14 at 05:09
  • You would have to use static analysis to try to determine the possible concrete types of v2 at that point, and add an edge to that method in each possible type. – JesusFreke May 09 '14 at 17:52