Strange assignment, TextView to Bundle, after decompiling, why?

The cause is that the type of local variables has changed, but some decompilers fail to handle it correctly.

Here's your onCreate code decompiled with 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

Here aload_0 is local variable for MainActivity object, and aload_1 is local variable for Bundle object. The source of the problem occured at code #20, when it stores the reference of just-retrieved TextView object into local variable 1 (astore_1), which was previously storing the Bundle object!

This is done since the Bundle object is not used for the rest of the method, therefore it's more efficient to reuse its local variable instead of a new variable. However it also means that decompilers need to work extra hard to produce correct Java code.

The smali-code you provided looks correct. Running the app also works with the original source code. However, the code provided by jd-gui doesn't even compile.

I got curious and decompiled your app with dex2jar. I uploaded the resulting MainActivity.class to this website.

The interesting part: Some decompilers (Procyon and Fernflower) generated the correct code and made separate variables for both the Bundle and the TextView. JAD and CFR however made the same mistake as jd-gui. They both used the Bundle-variable for the TextView.