Transformacja Dalvik przy użyciu niewłaściwego kodu wywołania

Question

Występuje problem z konwerterem dalvik dex i kodem operacyjnym używanym do wywoływania metod. Zasadniczo mam metoda private final zdefiniowana w mojej klasie, a podczas wywoływania, zamiast generowania kodu operacji invoke-direct, dx generuje invoke-super. Ponieważ jest to metoda prywatna, ta metoda nie istnieje w super klasie, więc dostaję naruszenie VFY na urządzeniu. Udało mi się wyśledzić dokładny scenariusz, który wyzwala to, i to wydaje się zdarzyć, gdy:

1. instrumentacji klas z JaCoCo i
2. klas skompilowane z --target 1.6

Jeśli te dwa warunki są spełnione, wynikowa klasa dex ma invoke-super zamiast invoke-direct. Jeśli wyłączysz JaCoCo LUB jeśli skompiluję z --target 1.5, użyje poprawnego kodu operacyjnego invoke-direct.

W patrząc na javap zdemontowanego kod klasy, widzę, co powoduje dx zakładać Super zamiast bezpośredniego:

Nie oprzyrządowanie, skompilowany do 1,6:

$ javap -d com.example.ClassName | grep waitForConnectivity 
159: invokespecial #115; //Method waitForConnectivity:()V 
$ dexdump -d classes.dex | grep waitForConnectivity 
147ad8: 7010 6042 0200   |001e: invoke-direct {v2}, Lcom/example/ClassName;.waitForConnectivity:()V // method@4260 

oprzyrządowanego, opracowywane dla 1,5 (--target 1.5):

$ javap -d com.example.ClassName | grep waitForConnectivity 
235: invokespecial #115; //Method waitForConnectivity:()V 
$ dexdump -d classes.dex | grep waitForConnectivity 
149d4c: 7010 9242 0400   |0018: invoke-direct {v4}, Lcom/example/ClassName;.waitForConnectivity:()V // method@4292 

Instrumented, skompilowany do 1,6:

$ javap -d com.example.ClassName | grep waitForConnectivity 
235: invokespecial #115; //Method com/example/ClassName.waitForConnectivity:()V 
$ dexdump -d classes.dex | grep waitForConnectivity 
149d4c: 6f10 9242 0400   |0018: invoke-super {v4}, Lcom/example/ClassName;.waitForConnectivity:()V // method@4292 

Więc różnica jest taka, że ​​skompilowany plik .class skompilowany kod bajtowy Java jest, że odwołuje się do pełną nazwę z this klasy (uprzedzenia "//Method waitForConnectivity:()V" class vs "//Method com/example/ClassName.waitForConnectivity:()V"). Wygląda na to, że dx automatycznie zakłada, że ​​jeśli nazwa metody jest w pełni kwalifikowana, musi używać invoke-super, ale jeśli nie jest kwalifikowana, używa invoke-direct.

Moje pytania są następujące:

1. Jest to błąd w Android dx lub błąd w JaCoCo?
2. Jak mogę tego uniknąć, aby przyrządy z instrumentem JaCoCo działały poprawnie w moich automatycznych testach?

Moje bieżące obejście jest mieć Maven „jacoco” profil, a tam zastąpić właściwość ${java.version} go zmienić z domyślnego „1.6” do „1.5”. Czy istnieje jakieś lepsze rozwiązanie?

Answer 1

Jedną z zasad używanych przez do określenia, czy należy emitować invoke-super czy invoke-direct, jest to, czy wywołanie metody jest wykonywane na tej samej klasie, co wywołanie.Zobacz RopperMachine.java w źródle wokół linii 912, dołączonego tutaj dla odniesienia:

 case ByteOps.INVOKESPECIAL: { 
      /* 
      * Determine whether the opcode should be 
      * INVOKE_DIRECT or INVOKE_SUPER. See vmspec-2 section 6 
      * on "invokespecial" as well as section 4.8.2 (7th 
      * bullet point) for the gory details. 
      */ 
      CstMethodRef ref = (CstMethodRef) cst; 
      if (ref.isInstanceInit() || 
       (ref.getDefiningClass() == method.getDefiningClass()) || 
       !method.getAccSuper()) { 
       return RegOps.INVOKE_DIRECT; 
      } 
      return RegOps.INVOKE_SUPER; 

Byłoby interesujące zobaczyć pełniejszy zrzut klasy, która jest coraz misconverted. Myślę, że prawdopodobnie to, co widzisz z javap, nie jest kompletnym obrazem rzeczywistości. Zauważ, że sama dx ma wbudowaną wtyczkę .class, która zapewnia o wiele więcej szczegółów niż javap. Wywołaj go jako dx --dump --bytes path/to/Name.class.