java - online - jadx

Asignación extraña, TextView to Bundle, después de descompilar, ¿por qué?

Question

Creé una aplicación simple, una aplicación de contador, que al presionar un botón incrementa un número entero por uno y actualiza una vista de texto. El código se puede ver a continuación:

public class MainActivity extends Activity {
    public static int count = 0;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        final TextView textView = (TextView) findViewById(R.id.count);
        textView.setText(Integer.toString(count));
        final Button button = (Button) findViewById(R.id.button);
        button.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                count++;
                textView.setText(Integer.toString(count));
            }
        });
    }
    ...
}

Después de descompilar la misma aplicación con dex2jar y jd-gui, recibí el siguiente código:

public class MainActivity extends Activity {
    public static int count = 0;

    protected void onCreate(final Bundle paramBundle) {
        super.onCreate(paramBundle);
        setContentView(2130903040);
        paramBundle = (TextView)findViewById(2131296257);
        paramBundle.setText(Integer.toString(count));
        ((Button)findViewById(2131296256)).setOnClickListener(new View.OnClickListener() {
            public void onClick(View paramAnonymousView) {
                MainActivity.count += 1;
                paramBundle.setText(Integer.toString(MainActivity.count));
            }
        });
    }
    ...
}

En la siguiente línea:

        paramBundle = (TextView)findViewById(2131296257);
        paramBundle.setText(Integer.toString(count));

¿Cómo es posible que el sistema configure la vista de texto en paramBundle? ¿Y por qué sucede esto? paramBundle es de tipo Bundle y TextView no es una subclase de Bundle, aún más Bundle es definitivo según la versión descompilada. ¿Algo fue mal al descompilar? ¿Es incorrecta la información del descompilador o por qué obtenemos este resultado?

Editar:

# virtual methods
.method protected onCreate(Landroid/os/Bundle;)V
    .locals 3
    .param p1, "savedInstanceState"    # Landroid/os/Bundle;

    .prologue
    .line 17
    invoke-super {p0, p1}, Landroid/app/Activity;->onCreate(Landroid/os/Bundle;)V

    .line 18
    const/high16 v2, 0x7f030000

    invoke-virtual {p0, v2}, Lcom/example/rawa/helloworld/MainActivity;->setContentView(I)V

    .line 20
    const v2, 0x7f090001

    invoke-virtual {p0, v2}, Lcom/example/rawa/helloworld/MainActivity;->findViewById(I)Landroid/view/View;

    move-result-object v1

    check-cast v1, Landroid/widget/TextView;

    .line 21
    .local v1, "textView":Landroid/widget/TextView;
    sget v2, Lcom/example/rawa/helloworld/MainActivity;->count:I

    invoke-static {v2}, Ljava/lang/Integer;->toString(I)Ljava/lang/String;

    move-result-object v2

    invoke-virtual {v1, v2}, Landroid/widget/TextView;->setText(Ljava/lang/CharSequence;)V

    .line 22
    const/high16 v2, 0x7f090000

    invoke-virtual {p0, v2}, Lcom/example/rawa/helloworld/MainActivity;->findViewById(I)Landroid/view/View;

    move-result-object v0

    check-cast v0, Landroid/widget/Button;

    .line 23
    .local v0, "button":Landroid/widget/Button;
    new-instance v2, Lcom/example/rawa/helloworld/MainActivity$1;

    invoke-direct {v2, p0, v1}, Lcom/example/rawa/helloworld/MainActivity$1;-><init>(Lcom/example/rawa/helloworld/MainActivity;Landroid/widget/TextView;)V

    invoke-virtual {v0, v2}, Landroid/widget/Button;->setOnClickListener(Landroid/view/View$OnClickListener;)V

    .line 30
    return-void
.end method

Definitivamente no soy un experto en smali, solo un novato. Pero descodifiqué la aplicación usando apktool y recibí el código smali anterior. A mi entender, la instancia guardada (paramBundle) se carga en p1 (= v3) y se usa en onCreate, y no se usa de ninguna manera en la línea 20 o 21. Para mí, ¿esto apunta a un error de desconexión? Tenga en cuenta que apktool permite volver a crear la aplicación y, por lo tanto, no se pueden perder datos al descompilar.

Answer 1

El código smali que proporcionaste parece correcto. Ejecutar la aplicación también funciona con el código fuente original. Sin embargo, el código proporcionado por jd-gui ni siquiera compila .

Tengo curiosidad y descompuse su aplicación con dex2jar. Subí el MainActivity.class resultante a este sitio web .

La parte interesante: algunos descompiladores ( Procyon y Fernflower ) generaron el código correcto y Fernflower variables separadas tanto para el paquete como para el TextView. Sin embargo, JAD y CFR cometieron el mismo error que jd-gui. Ambos usaron la variable Bundle para el TextView.

Parece que puedes culpar a jd-gui por el error. Lamentablemente, no puedo decir por qué ocurre.

Answer 2

La causa es que el tipo de variables locales ha cambiado, pero algunos decompiladores no lo manejan correctamente.

Aquí está su código onCreate descompilado con dex2jar + javap :

  protected void onCreate(android.os.Bundle);
    Code:
       0: aload_0
       1: aload_1
       2: invokespecial #20                 // Method android/app/Activity.onCreate:(Landroid/os/Bundle;)V
       5: aload_0
       6: ldc           #21                 // int 2130903040
       8: invokevirtual #25                 // Method setContentView:(I)V
      11: aload_0
      12: ldc           #26                 // int 2131230720
      14: invokevirtual #30                 // Method findViewById:(I)Landroid/view/View;
      17: checkcast     #32                 // class android/widget/TextView
      20: astore_1
      21: aload_1
      22: getstatic     #12                 // Field count:I
      25: invokestatic  #38                 // Method java/lang/Integer.toString:(I)Ljava/lang/String;
      28: invokevirtual #42                 // Method android/widget/TextView.setText:(Ljava/lang/CharSequence;)V
      31: aload_0
      32: ldc           #43                 // int 2131230721
      34: invokevirtual #30                 // Method findViewById:(I)Landroid/view/View;
      37: checkcast     #45                 // class android/widget/Button
      40: new           #6                  // class com/example/test/MainActivity$1
      43: dup
      44: aload_0
      45: aload_1
      46: invokespecial #48                 // Method com/example/test/MainActivity$1."<init>":(Lcom/example/test/MainActivity;Landroid/widget/TextView;)V
      49: invokevirtual #52                 // Method android/widget/Button.setOnClickListener:(Landroid/view/View$OnClickListener;)V
      52: return

Aquí aload_0 es una variable local para el objeto MainActivity, y aload_1 es una variable local para el objeto Bundle. La fuente del problema se produjo en el código # 20, cuando almacena la referencia del objeto TextView recién recuperado en la variable local 1 ( astore_1 ), que estaba almacenando previamente el objeto del paquete.

Esto se hace ya que el objeto Bundle no se usa para el resto del método, por lo tanto, es más eficiente reutilizar su variable local en lugar de una nueva variable. Sin embargo, también significa que los descompiladores deben trabajar más para producir el código Java correcto.